本文由 简悦 SimpRead 转码， 原文地址 zhuanlan.zhihu.com
秒杀系统是我在面试中问得比较多的，如果说程序 = 算法 + 数据结构的话，那么系统 = 服务 + 数据存储。所以系统设计中，我们更多的是围绕服务和数据存储来讨论。
有时间的同学可以看下阿里面试官关于秒杀系统的干货分享：淘宝秒杀系统怎么设计？
举个简单例子：双 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 的数据写回数据库。
最后，4S 分析法的第四步，Scale 扩展。对于秒杀系统来说，就是高并发场景下如何保证系统稳定和高可用，以及后续的优化。限于篇幅，可以来看看《系统架构设计 System Design 2020 版》。
另外关于秒杀系统的实操和代码实现，我们新开了一门《秒杀系统项目课》，将通过 9 天时间详细剖析秒杀系统涉及的 8 大技术架构和 15 个核心技术点，手把手带你实现秒杀系统，可直接写入简历，为简历增色。首节直播免费开放，有兴趣的同学可以先来占个坑。