@TOC

背景介绍

某哥: “@所有人 敲黑板了哈，有作业来了，本群里所有人周五前给出自己能想到的优化方案，性能提升建议。 交易域、库存域全体人员都要给出，请@邬某 @江某某 通知各域成员。周五前完成：
昨天去做了交流，有个挑战：中台建设需能支撑 2020 年双 11 活动，一天 3000 万订单的并发量，70%订单集中在活动初始 2 小时内。3000W*70%/2/3600, 大约每秒要处理3000笔单，峰值的并发数按5000笔计算。 从某猫聚石塔拿单，到发送数据到某鸟发货全过程。需要做库存寻源及成本分摊。
建议：交易和库存的同学最好针对业务过程提出优化方案，@某某们 从整体技术体系提出优化方案，读写分离，分库分表这些就不要写了。”.
ps: 这里的某没有我哈，我是一个打杂的，我只是记录一下自己的对问题的思路。

我的思考

1. 在并发十分大的情况下，我们需要考虑，因为某些原因(网络、人为、框架)造成的重复提交，重复下单问题。
   解决：
   (1). 上一步骤生成token，下单校验token是否合法
   (2). 前端置灰
   (3). 分布式锁重复下单校验 @see reids实现分布式锁AOP
   (4). 令牌桶单用户、ip限流(当然也可以nginx等限制) @seeredis令牌桶AOP

2. 库存扣减导致的数据库压力。
3. 库存扣减的方式，订单下单后应该先预占库存，支付成功时扣减库存，过期或者失败回滚库存。
   解决： 其实吧2、3可以看作是一个问题，就是库存的操作方式
   (1). 在很大并发下，除了分库分表去分担压力，更应该使用redis做为库存的扣减，redis有天然的并发控制优势，再基于lua脚本，简直不要太好用。可以参考redis令牌桶AOP内的扣减令牌lua脚本。
   (2). 如果采用redis做为库存的扣减的管理，那么redis与db的数据同步是一个问题，这里我觉得可以使用MQ的方式去做库存的同步操作，使用mq的好处就是，可以冗余数据，让数据不被丢失，而且顺序性，可以保证redis的数据同步顺序。mq的灵活性和峰值处理能力可以做到削峰。当然消费mq对redis操作的时候也是需要保证mq消息幂等性，而且对于redis无论是新增还是递增还是扣减都应该用incrBy 或者 decrBy。

结果

1. 库存新增发送mq incrBy到redis中
2. 订单中心预占、扣减库存时，直接从redis中进行扣取(预占、实际扣减分开)，扣减成功进行decrBy的mq推送，db消费进行db落地。
3. 预占过期进行扣减回滚，发送mq消息，回滚redis与db落地。
4. 消费mq对redis进行同步。

暂时只想到这些，个人技术不到位，所以写的东西乱七八糟的，记录一下自己的思路。如果有不足还请多指点，十分感激。我会及时补充和修改。

标签：库存,扣减,redis,并发,mq,下单
来源： https://blog.csdn.net/qq_36800514/article/details/99413863