秒杀系统是常见的一种系统设计类型，在电商业务中的应用非常普遍。同时也是面试中问得比较多的。

如果说程序 = 算法 +数据结构的话，那么系统 = 服务 + 数据存储。所以系统设计中，我们更多的是围绕服务和数据存储来讨论。

举个简单例子：某年双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的常见问题：

什么时候把库存写入到Redis？
秒杀活动创建/维护时写入Redis。

如何保证活动数据库和库存数据一致？
可以使用分布式事务或消息队列。

分布式事务：保证多个数据库的操作同时成功或者同时失败。对强一致性有要求的业务场景可以考虑使用分布式事务，比如银行转账

消息队列：基于生产者/消费者模型的组件，一般实现异步任务（非实时处理）时会引入消息队列。消息队列的好处是任务可以慢慢处理，不必同步处理等着响应结果。目前主流的消息队列有RocketMQ、Kafka等。使用场景除了异步任务之外，一般还用于失败的情况下重试处理，重复消费直到消费成功。

下单减库存/支付减库存？
下单锁定库存，支付减库存。

如何防止商品被超卖？
把库存数据放入到缓存中，利用缓存的原子特性保证同时只有一个线程操作库存。

库存写回数据库的时机？
采用定时任务同步Redis的数据写回数据库。

4S分析法的第四步 - Scale扩展

对于秒杀系统来说，就是高并发场景下如何优化系统。推荐大家通过完整视频了解如何进行系统优化和升级。

前面说过，秒杀系统是电商业务中最常见的，在实际面试当中，系统架构设计的考察标准是：面试者独立设计一个大型的系统，它在现实中是可work的，同时在高并发的情况下仍具有高可用性。

对许多缺少工作经验的应届生，以及大量没机会参与大型系统设计、日常都在“拧螺丝”的初级程序员来说，明明不具备架构的能力但面试的时候又经常遇到，拿到设计类题目就懵了！

九章的《系统架构设计》覆盖了18大系统架构设计知识点和面试题。通过大量调研，囊括了最热门、高频的18大设计类题型包括了：

• 秒杀/订票系统
• IM系统
• 协同文档编辑系统
• 谷歌搜索系统
• 用户登陆/注册系统
• 网站系统（API设计/短URL）
• 数据库
• 容器技术（K8S/Docker）
• MLE机器学习系统
  ……

想要尝试自己设计一个秒杀系统，或者对国内热门的系统设计感兴趣的同学们，不妨来试听一下，好的学习方式永远是自己动手实现。