秒杀问题总结

为啥要用Redis呢？

秒杀是典型的读多写少的场景，非常适合使用缓存来优化。百分之99的用户都在读Redis，只有1的用户在写数据库（可以利用队列）。

重试

重试，是异常处理很常见的手段。

站点框架有没有自动重试？
服务框架有没有自动重试？
服务连接池、数据库连接池有没有自动重试？
服务化分层的架构中，建议只入口层重试，服务层不要重试，防止雪崩。Dubbo底层，调用超时是默认重试的，这个设计不好。

重试，就要考虑幂等。

幂等性

读请求，是幂等的。写请求，视情况而定。

insert x，不是幂等
delete x，是幂等
set a=x，是幂等
set a=a-x,不是幂等的

如何定义抢购成功？
谁先支付成功，算谁抢到
最终发起支付
抢单数量 - 1
- 乐观锁，读数量之前检查表的版本号，更新的时候where这个版本号，并更新版本号和数量(-1)
- 悲观锁，在当前事务完成之前，其他任何事务不能修改当前事务读的数量
调用支付API
支付成功不变
支付失败抢单数量 + 1
- 乐观锁
- 悲观锁

谁先下单算谁抢到，预留支付时间(5分钟)

发起下单请求
查询抢单数量
更新抢单数量 - 1
- 乐观锁
- 悲观锁
订单创建
5分钟后执行定时任务
- 检查支付时间是否过期
- 并更新抢单数量

####

发现商品售卖完成后，在本地建立商品售卖完成的缓存，避免每次都将请求发送到Redis做判定。
事务的问题https://www.hicode.club/articles/2018/06/30/1550590729846.html

分布式事务的解决方案

http://objcoding.com/2019/07/11/seata/
https://juejin.im/post/5d7ed892e51d453c2577b831 Spring Cloud同步场景分布式事务怎样做？试试Seata

在秒杀场景中，是否有必要保持缓存与数据库的强一致性？(没必要)

对于秒杀场景，最重要的就是限流和异步处理，因为数据库往往是最脆弱的地方。主要设计是这样的，除去接口本身的限流以外，本地内存和redis都可以对商品库存进行预处理，也就是是否是重复秒杀以及商品库存是否为零。当然这两者存的数据很可能不是最新的，但这个问题不大，因为如果他们存的数据已经显示商品库存为零，则秒杀已经失败，都不用打到数据库层。如果过了本地跟redis这一关，之后就是异步处理，就是将操作数据库作为消息写入mq，由消费端进行消费。消费端执行具体的数据库事务，只有执行成功才意味着秒杀成功，否则都是失败。无论结果如何，都将最终数据写入redis即可。可以看到这里是不需要做到数据库跟缓存的强一致性的。当然写mq这里还有点讲究，就是要保证同一个用户请求只会被同一个消费端处理，这个以Kafka为例只要指定相同的消息key即可做到，且消费端需要做消息去重，以请求ID作为去重依据。

秒杀后未支付取消占位，如何对剩余库存做及时的控制更新？

数据库订单中有一个未支付状态。如果超过时间，例如10分钟，库存会重新会恢复（回仓）。如果是队列已达到商品数量的话，秒杀的提示是，10分钟之后再试试看，说不定又有商品哟！

一个开源的秒杀引擎

https://github.com/xjjdog/seckill-engine

一个秒杀商城

https://gitee.com/steadyjack/SpringBoot-SecondKill
https://github.com/qiurunze123/miaosha 一个秒杀项目

ServiceComb基于DDD的秒杀

http://servicecomb.apache.org/cn/docs/performance-test-on-seckill-with-jmeter/
http://servicecomb.apache.org/cn/docs/seckill-development-journey-part-I/

很好的博客

https://juejin.im/entry/56e0e158816dfa0051da43b8
https://www.infoq.cn/article/solution-to-the-architecture-of-spike-system
https://imfox.io/2016/11/04/seckill/
http://cmsblogs.com/?p=3344
https://juejin.im/post/5d7c7a14f265da03f47c4f93#heading-0

一条数据库更新语句，比如update t set m=m-10 from id=1，在并发情况下会出现异常吗？

超卖问题如何解决？

分布式锁优化

加锁分析