如何设计一个秒杀系统？

原创已于 2025-04-15 22:00:33 修改 · 404 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#系统架构

于 2025-02-24 14:58:10 首次发布

面试同时被 3 个专栏收录

71 篇文章

订阅专栏

线上问题分析&场景设计

45 篇文章

订阅专栏

大型网站技术架构

21 篇文章

订阅专栏

转转高并发下秒杀系统的设计

携程门票秒杀系统的设计与实践

转转高并发下秒杀系统的设计

秒杀场景的技术难点，具体内容如下：

业界通用做法
- 压力分摊：利用分桶策略将单品库存拆分为多组以缓解抢购高峰压力，但存在库存分配、碎片处理、调度规则和动态扩容等问题。
- Redis+MySQL：Redis 高性能读写和原子操作防超卖，MQ 流量削峰减轻后端压力。不过存在数据一致性问题，且不能仅在 Redis 操作后再同步数据库，因为后续业务需要实时数据交互。
- Inventory Hint：部分公司使用阿里 RDS 云数据库，凭借其内置的 Inventory Hint 技术，在高并发下让数据库稳健运行。
- 压力分摊 + Redis+MQ：多种技术结合，SQL 合并执行、缓存协同、分桶策略分流，共同应对高并发，确保系统稳定。
Redis + MQ 解决高并发下的秒杀场景
- Redis 库存预扣减：通过 Lua 脚本保证库存扣减的原子性和高效性，实现防重提交、库存扣减和记录交易流水功能，涉及 Hash 和 String 数据结构。
- MySQL 库存扣减：借助 RocketMQ 的事务消息保证数据库库存扣减成功，包括发送半消息、检查本地事务、消息回查和消费消息等步骤，利用消息重试机制保证数据一致性。
- 记录操作流水的原因：为保证下单和库存的一致性，可采用定时对账机制，也可选择 Seata、TCC 等其他一致性保证方案。
Inventory Hint 数据库扣减
- 使用：在对应语句加上特殊 hint 语句即可，具体参考阿里云文档。
- 原理介绍：对数据库热更新优化，标记 SQL 后，MySQL 内核将更新操作按主键或唯一键分组，减少行级锁申请等待、B + 树索引遍历操作和事务提交次数，提升性能。
总结：电商秒杀技术方案应根据并发量和数据量选择，并发量低时单表加锁即可；并发量中等时 Redis 与 MQ 组合；并发量高时需加入压力分摊；数据量极大时还需 Inventory Hint 技术，要贴合场景选择合适技术组合。

参考：转转高并发下秒杀系统的设计

携程门票秒杀系统的设计与实践

后疫情时代旅游行业复苏，携程门票秒杀活动频繁，面临亿级流量冲击。其预订交易系统存在 Redis 超负载、数据库压力大、供应商系统不稳定等问题，导致页面卡顿、订单处理异常。为此，携程采取热点识别构建多级缓存、优化缓存更新策略、削峰填谷等措施应对。还通过扣减库存异步化保证数据一致性，借助架构健康度治理和大型活动保障体系实现高可用的可持续性，保障系统稳定高效运行。

详细总结

背景：后疫情时代旅游行业快速复苏，营销秒杀活动日益频繁，携程门票预订交易系统面临亿级流量冲击，需进行架构升级以保障大流量下系统稳定高效运行，为用户提供流畅预订体验。
秒杀活动案例分析：秒杀活动具有大流量、高并发、时间敏感性和履约保障等特点，携程门票交易系统还具备强一致性和多维度跨商品组合限购的特性。回顾携程门票大型秒杀活动，如 “惠游湖北” 活动峰值流量达日常 45 倍，北京环球影城开业、武汉动物园开园、IU 演唱会门票秒杀等活动也面临巨大流量挑战。若系统未优化，用户可能遇到页面卡顿、付款后订单状态无法确认等问题。

系统架构设计与演进

系统稳定性挑战与应对策略：

问题	表现	应对策略	优化效果
Redis 超负载与缓存热点	1. 缓存热点：特定热点数据使各实例 CPU 使用率不均衡，影响响应速度 2. 缓存大 Key 问题：阻塞请求、占用大量内存、阻塞网络，降低 Redis 性能并影响系统稳定性	1. 热点识别自动构建多级缓存：识别高频访问 Key，自动发现或指定 Key 加入本地缓存 2. 缓存大 Key 应对方案：精简缓存对象、压缩缓存对象、拆分大 Key、建立长期治理机制定期扫描 Redis 中的大 Key	1. 开启多级缓存后，同一缓存 key 访问性能明显提升，Redis 访问量明显降低 2. 大 Key 优化后，Redis 查询性能显著提升，缓存查询耗时从 300μs 优化至 100μs
数据库超负载	商品信息变更伴随缓存失效，高并发和秒杀场景下，大量请求穿透缓存，对数据库造成巨大压力，甚至引发性能故障	1. 缓存覆盖更新策略：商品信息变更时，直接更新缓存值，避免流量穿透数据库 2. 消息聚合：合并一段时间窗口内的商品变化消息，减少消息处理频率 3. 异步更新缓存：将缓存更新任务放入异步队列，由后台线程异步处理	避免流量穿透到底层数据库，降低数据库压力
供应商系统不稳定	1. 被供应商限流：高并发场景下，订单提交受阻，影响业务流转 2. 供应商系统不稳定：导致订单处理延迟或失败	1. 削峰填谷 / 缓冲池：利用消息队列作为订单提交缓冲池，异步处理订单信息，削平高峰流量 2. 禁售策略：建立健康度监控机制，自动禁售不稳定或限流的供应商；对失败订单定期重试，并根据供应商恢复情况调整重试频率和次数	有效确保供应商系统能力不影响下单吞吐量
流量控制	SOA 限流影响所有业务，无法满足秒杀活动对特定商品的限流需求	1. 自定义限流：针对单个秒杀商品设置独立限流阈值；自动识别热点商品并限流 2. 多层次限流防护：结合商品级限流能力，控制进入每一个页面的流量，根据秒杀库存预估售卖时长，控制进入各页面的流量比例	1. 可控制进入每一个页面的流量，超负载也不影响整体的可用性 2. 服务器资源的投入可控

写数据一致性挑战与应对策略：下单库存扣减存在性能瓶颈，采用扣减库存异步化策略，分初始化、扣库存、还库存三步，确保最终一致性，系统能支撑数十万单 / 分钟交易流量。
实现高可用的可持续性：通过架构健康度治理（涵盖系统运行、架构设计、工程化健康度）实现系统质量量化管理；建立大型活动和节假日保障体系，提前进行风险梳理、压测、制定预案等，形成日常开发与保障的闭环。

总结：携程门票预订交易系统通过解决读热点、写瓶颈、强事务、流量控制等问题，以及日常架构健康度治理和专项保障计划，实现了系统在高负载下的稳定运行和持续高可用。

关键问题
- 问题 1：缓存覆盖更新策略相比传统删除缓存 Key 的方式有何优势？
  - 答案：传统删除缓存 Key 的方式在高并发和大流量场景下，会出现缓存击穿，大量请求直接访问数据库，导致数据库压力骤增；还存在消息处理延迟，使缓存更新不及时，进一步加剧数据库压力。而缓存覆盖更新策略能避免流量穿透到底层数据库，直接更新缓存值，有效降低数据库压力。
- 问题 2：商品级限流策略中，10 个 100 毫秒滑动窗口的作用是什么？
  - 答案：每个窗口平分一部分流量，有效控制下游服务的并发量，降低下游服务压力，为用户提供更均衡的流量分配。结合商品级限流能力，根据秒杀库存预估售卖时长控制进入各页面流量比例，大幅减少服务器资源投入。
- 问题 3：架构健康度治理包含哪些方面，分别如何反映系统质量？
  - 答案：架构健康度治理包含系统运行、架构设计、工程化健康度三个方面。系统运行健康度从服务性能、运行状态、调用情况、数据库、缓存等多维度运行时的健康状态和问题反映系统质量；架构设计健康度通过服务数量、调用关系复杂度、循环依赖、调用层级等因素反映系统稳定性和性能；工程化健康度基于应用的工程质量和效率状态，如人均应用数、代码行数、工程包相关指标、编译时长等反映开发的工程化水平。