揭秘千万级QPS秒杀系统的架构设计与避坑指南

揭秘千万级QPS秒杀系统的架构设计与避坑指南

• 参考引用：Java 八股/让你设计一个秒杀系统，你会考虑哪些问题？

回答

1. 高并发瞬时流量：秒杀时流量瞬间增大，要保证系统稳定可用。
2. 热点数据：如热门商品信息，更新频繁易引发性能问题。
3. 数据量大：包含商品、用户等多种数据，处理和存储有挑战。
4. 库存的正确扣减：防止超卖、少卖，保证库存数据准确。
5. 黄牛抢购：黄牛利用工具大量抢购，影响正常用户体验。
6. 重复下单：避免用户多次重复提交订单。
7. 对普通交易的影响：防止秒杀流量影响正常交易的稳定性。
8. 业务手段

1、高并发瞬时流量

• 从整体架构设计层面，做逐层流量的过滤。

  用户的秒杀请求依次经过客户端、CDN、Nginx、Web 应用、缓存、数据库等。

  尽量在离用户更近的地方做流量的过滤。

• CDN：

  提前将秒杀功能及前端资源放入，让用户更快访问静态资源。

  如：在手游项目实战中，游戏客户端更新包，会提前传入 CDN，并进行 CDN 预热。

• 客户端：

  进行请求随机丢弃，被丢弃请求返回失败或提示系统繁忙，让用户重试，减少发往服务端流量。

• Nginx：

  统一接入请求，做负载均衡、流量分发。

  还可配置黑白名单、IP 限流及业务校验进行流量过滤。

  如：在手游项目实战中，会做域名负载，进行分流；还会进行分区分服。

• 服务器：

  基于 sentinel 或自定义限流算法配置限流策略，实现动态限流。

  如：在手游项目实战中，单服会做登录人数限制，达到指定限制会加入排队系统。

  硬件方面：

  • 压力大区服，mongo和redis要独占一个
  • game server 每个平台的前几组要高配置，顶过前面压力，后面用不到可以降配置。

• 缓存：

  服务器的查询和部分写操作可由缓存处理。

  本地缓存性能高于分布式缓存，近端缓存优于远端缓存

  如：在手游项目实战中，由于业务原因，对接口延迟要求很高。大部分数据操作，都是基于本地内存+redis 缓存实现。然后，再异步去实现数据持久化。

• 秒杀业务特性：

  因秒杀业务允许一定失败率，可通过层层过滤，在前端拦截更多流量，减轻后端压力 。

• 秒杀业务架构流程图

• 参考引用：Java 八股/22-高性能、高可用、高并发/设计一个高并发系统.md
• 参考引用：Java 八股/22-高性能、高可用、高并发/服务端接口性能优化方案.md

2、 热点数据

• 热点数据特点

  在秒杀系统中，因大家抢购同一件商品，该商品数据成为热点数据。

  会面临高频的查询和写请求，如库存扣减等操作 。

• 解决方案

  1. 拆分：将热点数据拆分为多个热度较低的数据，

     再借助负载均衡，使不同请求分散到不同数据上，降低单个数据的访问压力。

  2. 缓存：利用秒杀提前可预知热点数据的特性，提前进行缓存预热。

     不仅要在 Redis 中预热，还要在本地缓存预热，避免 Redis 出现热 key 问题，

     提高数据读取速度，减轻后端压力 。

     参考引用：Java 八股/22-高性能、高可用、高并发/预热.md

     参考引用：Java 八股/08-Redis/热 Key 问题是什么？如何解决？.md

3、数据量大

• 数据量一大，就会带来查询效率低的问题。

• 解决思路

  1. 加 缓存

  2. 用 ES

  3. 做 分库分表

     参考引用：Java 八股/12-分库分表/分库？分表？分库分表？.md

  4. 做 冷数据归档

4、 库存的正确扣减

• 秒杀是一个高频的并发库存扣减的场景，
• 如何提升库存扣减的性能？
• 如何避免超卖、少卖问题？
• 参考引用：Java 八股/20-场景问题/如何避免超卖和少卖？.md

5. 黄牛抢购

1. 首先，防刷最重要的就是检测哪些用户可能是黄牛。

   一般需要借助算法模型，根据用户的IP、设备信息、网络信息、行为数据等进行分析。然后，加到黑名单。

   或者对 IP 进行限流。使用 nginx、sentinel、guava 实现限流。

   参考引用：Java 八股/22-高性能、高可用、高并发/限流？限流算法？.md

2. 其次，是防止用脚本的方式直接调我们的接口，我们可以借助 token 的方式实现防刷。

3. 项目实战，各种防刷

   • 高防-云解决方案

   • 刷号

     1. SDK 限制每个账号全服每天只能注册30个账号（限制iP,安卓mac,iOSidfa每天限制30个注册，超过封号24小时）

     2. 注册机制，必须手机号注册（影响注册转化率，不可取）

     3. 批量封号，等级低于多少，未充过值（可取）

     4. 后端也做设备+IP进行限制注册人数 （可取，可能会影响自己公司人注册）

   • 刷接口

     1. 后端防刷接口，做最大请求消息数（如一秒最大发多少个消息）

        1秒发10个消息，如果超了T玩家下线

   • 刷资源

     1. 资源增减逻辑必须遵循 ’先扣后加、检查负数、避免溢出‘，必须在代码层面避免’刷资源‘问题
     2. 出现刷资源bug要要及时关闭开关

6、 重复下单

• 问题描述：

  在秒杀业务里，用户频繁尝试下单支付，可能导致重复下单，额外占用库存，最终造成少卖情况。

• 如何避免？

  1. 基于 token 检测：

     用户在同一页面未刷新时，token 不变。

     利用这一点进行重复下单检测，可避免部分重复下单。

  2. 结合业务限购判断：

     秒杀通常有限购规则，

     通过判断用户是否已有在途订单，限制购买数量，防止重复下单。

  3. 引入锁机制：

     在 token 检测和订单重复性判断过程中，为应对并发导致的重复问题。

     需引入锁机制，确保下单操作的幂等性。

     即无论操作执行多少次，结果都一致 。

• 参考引用：Java 八股/15-分布式/接口幂等的问题.md

7. 对普通交易的影响

• 影响问题

  秒杀作为电商网站的功能，常与其他业务一同部署在服务器、缓存和数据库等资源上，可能对普通交易产生较大影响 。

• 应对措施

  1. 物理隔离：

     将前端和后端服务以及数据存储完全分开，

     能最彻底地避免秒杀业务对普通交易的干扰。

  2. 逻辑隔离与物理隔离结合：

     应用层面采用物理隔离，数据层面进行逻辑隔离。

     即在订单和商品上做标记，注明是秒杀订单，便于后续查询和数据分析，

     同时也能在一定程度上降低秒杀业务对普通交易的影响 。

8、业务手段

• 意义：

  在解决秒杀相关问题时，不能仅依赖技术手段。

  若业务层面的做法不影响用户体验，能简化技术实现方案，提升系统的成本效益和稳定性 。

• 业务手段

  1. 限购：限制用户购买商品的数量，减少单个用户的抢购量，从而降低整体请求量。

  2. 预约制：

     用户需先预约，通过审核后才能参与秒杀。

     提前筛选参与用户，有效降低秒杀时的瞬时请求量。

  3. 预售功能：提前开启商品预售，分流部分购买需求，缓解秒杀时的流量压力。

  4. 增加验证：

     在秒杀时设置验证码、问题等验证环节，

     不仅能降低高并发流量，还能防范脚本刷单风险 。