秒杀设计实现方式
双11临近，又到了剁手时节。每年双11电商的秒杀玩法层出不穷，秒杀系统几乎成了所有互联网公司的“标配”。
秒杀系统中涉及到的很多技术点也是一二线大厂面试重点考察的点。秒杀系统也是我在面试中问得比较多的，时间充裕的同学可以看下B站阿里面试官关于秒杀系统的干货分享：淘宝秒杀系统怎么设计？
举个简单例子：双11，商家以4499的价格上架了某iphone，比官网价格便宜了1000元，库存总数10台，运营设置11/11 00:00活动生效，一人只能购买1台，商品售完为止。
梳理下用户端的业务流程：
根据九章算法独家系统设计4S分析法，第一步Scenario场景。需要确定设计哪些功能，承受多大的访问量？
秒杀业务通常具有如下特点：
瞬间并发量大：大量用户会在同一时间抢购，网站流量瞬间激增。
库存少：访问数量远远大于库存数量，只有极少数人成功。
业务流程简单：流程短，立即购买-下单-减库存。
前期预热：对于还未开启活动的秒杀商品，以倒计时的方式显示，只能访问不能下单。
这里有个常见概念QPS（Query Per Second），即一秒内可以处理的请求数量。假如一个服务的RT是20ms，则QPS为50，这里计算的是单机单线程QPS，如果计算集群的话，需要考虑集群数量和线程数量。
这时候需要确认秒杀商品的请求QPS是多少。如果面试官说峰值大概量级在100万，那么按照服务单线程QPS是50，单台最大线程数按3来计算的话，单台机器最大支撑150的QPS，那么至少需要100W/150=6667台机器。
常见的组件最大QPS，mysql单机1000QPS，Redis单机10万QPS。
第二步，Service服务。秒杀系统服务设计大致如下
第三步，Storage存储，数据是如何存储和访问的。为每个服务选择合适的存储结构，然后细化数据表结构。这个例子中，秒杀系统数据库设计如下
于是我们可以得到秒杀活动中，数据库之间的关系如图所示
接下来就是mysql扣库存了。秒杀系统一定会遇到的就是并发问题，这里说下乐观锁和悲观锁。
悲观锁的流程如下：
乐观锁流程如下：
可以看到悲观锁的问题是会占用大量的线程资源，可能导致mysql的线程耗尽。在对于数据一致性要求非常高的场景中，一般用悲观锁；而乐观锁在version变动频繁的情况下则不适用，比如这里的秒杀系统就不太适合用乐观锁，因为库存变化太快了。
另外可以再看下Redis下的秒杀系统数据库设计。
几个关于秒杀系统中Redis的常见问题：
1.什么时候把库存写入到Redis？
秒杀活动创建/维护时写入Redis。
2.如何保证活动数据库和库存数据一致？
可以使用分布式事务或消息队列。
分布式事务：保证多个数据库的操作同时成功或者同时失败。对强一致性有要求的业务场景可以考虑使用分布式事务，比如银行转账
消息队列：基于生产者/消费者模型的组件，一般实现异步任务（非实时处理）时会引入消息队列。消息队列的好处是任务可以慢慢处理，不必同步处理等着响应结果。目前主流的消息队列有RocketMQ、Kafka等。使用场景除了异步任务之外，一般还用于失败的情况下重试处理，重复消费直到消费成功。
3.下单减库存/支付减库存？
下单锁定库存，支付减库存。
4.如何防止商品被超卖？
把库存数据放入到缓存中，利用缓存的原子特性保证同时只有一个线程操作库存。
5.库存写回数据库的时机？
采用定时任务同步Redis的数据写回数据库。
————————————————
版权声明：本文为CSDN博主「九章算法」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/JiuZhang_ninechapter/article/details/109329902