| title | pay |
|---|---|
第19节：设计滑动库存分布式锁处理活动秒杀 |
作者：小傅哥
博客：https://bugstack.cn
沉淀、分享、成长，让自己和他人都能有所收获！
- 分支：211120_xfg_redis
- 描述：引入 Redis 到抽奖系统，设计颗粒度更细的滑动库存编号分布式锁，处理活动秒杀流程
- 设计滑动库存分布式锁处理活动秒杀 @一点江南
- 设计滑动库存分布式锁处理活动秒杀 @BerserkD
- 设计滑动库存分布式锁处理秒杀流程 @杨杨得亿🙉
- 设计滑动库存分布式锁处理活动秒杀 @Geroge Liu
- 弃用数据库行锁的方式删减活动库存，改用redis分布式锁，并用mq去删减库存。@Chin
- Redis中的setnx作为分布式锁的使用 @liuc
- 活动领域Redis分布式滑动库存锁优化 @微风
- 流程图比较清晰，以抽奖流程编排接口为主线，每个功能点为支线；贯穿多个领域层 @xbhog
- 把整个抽奖流程 debug 走一遍，记录一下这些章节的核心思想 @爱奋斗的小鲨鱼
- 1~19 章节总结 目前将组件装在服务器上 后续结合公众号再继续开发 @爱奋斗的小鲨鱼
- 考虑某个活动如果在同一时间有大量用户参与 @咖啡苦涩
- 首先非常感谢小傅哥，该项目确实让我感觉学习到很多优秀的内容，以下是我学习的一个阶段性总结 @神经蛙
- 抽奖系统四层架构设计梳理 @灵幻新隆
- 滑动库存分布式锁处理活动秒杀流程梳理 @错否
- 抽奖系统学习总结整理 @夜空的寂静
- 使用docker部署了lottery，更新docker-compose部署的方式 @小曹不会emo
- 这两天完成了第19节内容引入 Redis 到抽奖系统，设计颗粒度更细的滑动库存编号分布式锁，处理活动秒杀流程 @素质男孩
- 系统功能流程图汇总 @CCAT
- 回顾整个抽奖系统和这些天考虑的这些系统性的知识 @王磊
- 系统性整理一下这些天的知识积累，同时展望一下后续的知识补充 @王磊
- Lottery-api 抽奖网关集成白名单组件 @俗人
- Lottery-api 抽奖网关继承熔断降级组件 @俗人
- Lottery-api 抽奖网关集成限流组件 @俗人
- Lottery压测 @俗人
- Lottery-api 抽奖网关集成自定义方法拦截组件 @俗人
- 由于本章节需要用到 Redis 所以我们在云服务器搭建 Redis 服务，这样可以更加方便的使用。如果你暂时还没有云服务器，那么在本地搭建 Redis 也可以，只是少了一些云环境的配置练习 云服务器地址
- 在抽奖系统中引入 Redis 模块，优化用户参与抽奖活动。因为只要有大量的用户参与抽奖，那么这个就属于秒杀场景。所以需要使用 Redis 分布式锁的方式来处理集中化库存扣减的问题，否则在 TPS 达到1k-2k，就会把数据库拖垮。
- 在设计秒杀流程时，优化锁的颗粒度力度，不要把锁直接放到活动编号上，这样在极端临界情况下会出现秒杀解锁失败，导致库存有剩余但不能下单的情况。所以需要增加锁的颗粒度，以滑动库存剩余编号的方式进行加锁，例如 100001_1、100001_2、100001_3，以此类推，具体看代码实现。
- 增加缓存扣减库存后，发送 MQ 消息进行异步更新数据库中活动库存，做最终数据一致性处理。这一部分如果你的系统并发体量较大，还需要把 MQ 的数据不要直接对库更新，而是更新到缓存中，再由任务最阶段同步，以此减少对数据库表的操作
- 优化活动领域，活动参与流程中的库存扣减操作，这部分我们原来是使用数据库行级锁🔐 处理的库存扣减，但因为会存在并发问题所以这里优化为 Redis 分布式锁进行处理。
- 活动领取完成后，其实这个时候只是把缓存的库存扣掉了，但数据库中的库存并没有扣减，所以我们需要发送一个 MQ 消息，来对数据库中的库存进行处理。因为 MQ 可以消峰因此在降低 MQ 分片的情况下，消费效率有所下降，并不会对数据库造成压力，保证最终数据一致性即可。但也有例外，所以我们提到可以使用定时任务来更新数据库库存