高并发下单与库存的系统设计

思考

我的思考:
在并发十分大的情况下，我们需要考虑，因为某些原因(网络、人为、框架)造成的重复提交，重复下单问题。
解决：
(1). 上一步骤生成token，下单校验token是否合法
(2). 前端置灰
(3). 分布式锁重复下单校验 @see reids实现分布式锁AOP
(4). 令牌桶单用户、ip限流(当然也可以nginx等限制) @seeredis令牌桶AOP
库存扣减导致的数据库压力。
库存扣减的方式，订单下单后应该先预占库存，支付成功时扣减库存，过期或者失败回滚库存。
解决： 其实吧2、3可以看作是一个问题，就是库存的操作方式
(1). 在很大并发下，除了分库分表去分担压力，更应该使用redis做为库存的扣减，redis有天然的并发控制优势，再基于lua脚本，简直不要太好用。可以参考redis令牌桶AOP内的扣减令牌lua脚本。
(2). 如果采用redis做为库存的扣减的管理，那么redis与db的数据同步是一个问题，这里我觉得可以使用MQ的方式去做库存的同步操作，使用mq的好处就是，可以冗余数据，让数据不被丢失，而且顺序性，可以保证redis的数据同步顺序。mq的灵活性和峰值处理能力可以做到削峰。当然消费mq对redis操作的时候也是需要保证mq消息幂等性，而且对于redis无论是新增还是递增还是扣减都应该用incrBy 或者 decrBy。

结果

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

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