秒杀圣经(2): 16大绝招，完成10Wqps秒杀架构（3万字架构长文）

高并发下，如何设计秒杀系统？这是一个高频面试题。

每秒上万次下单请求，秒杀如何处理？

高并发下，如何设计秒杀系统？

如何解决秒杀超卖？

最新《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请关注本公众号【技术自由圈】获取，后台回复：领电子书

本文目录

- 1 秒杀系统的业务架构

 - 1.1 秒杀系统的业务特点

 - 1.2 秒杀暴露与秒杀按钮

 - 1.3 秒杀的验证码设计

- 2 秒杀系统的流量架构

 - 2.1 秒杀系统的流量特点

 - 2.2 高并发 吞吐量 规划和评估

 - 2.3 QPS 预估（漏斗型）

 - 2.4 通过二八定律进行流量预估

 - 2.5 性能压测评估

- 3 秒杀的异步架构

 - 3.1 同步模式的下单流程

 - 3.2 两阶段异步下单流程

 - 3.3 三阶段异步下单流程

- 4 电商系统的分层架构

 - 4.1 经典电商系统的分层架构

 - 4.2 秒杀系统的分层架构

 - 4.3 秒杀架构的一些特殊方案

- 5 秒杀的动静分离架构

- 6 秒杀的缓存架构

 - 6.1 读多写少大杀器：缓存架构

 - 6.2 缓存的三大经典问题

 - 6.3 缓存击穿

    -解决方案

    -本地锁的问题

 - 6.4 缓存穿透

    -缓存穿透 带来的风险

    -缓存穿透为什么会产生缓存穿透

    -缓存穿透解决方案

    -缓存穿透的一大利器：布隆过滤器 

 - 6.5 缓存雪崩 

    -缓存雪崩 带来的风险

    -缓存雪崩 解决方案

- 7 库存扣减场景下的数据一致性架构

 - 7.1 第一阶段  redis预扣减库存

 - 7.2 第二阶段  数据库扣减库存

 - 7.3 redis分布式锁 实现库存扣减一致

    -基础的 setNx命令加锁

    -基于纯Lua脚本的分布式锁的执行流程

    -加锁的Lua脚本： lock.lua

    -解锁的Lua脚本： unlock.lua：

 - 7.4 redisson 分布式锁 实现库存扣减一致

    -锁的续期问题

 - 7.5 redisson 分段锁 实现库存扣减一致

 - 7.6 第三阶段： 支付超时，库存回退

- 8 秒杀的mq异步架构

 - 8.1 MQ的消息0丢失架构

 - 8.2 MQ消息的幂等性架构

 - 8.3 垃圾消息问题

 - 8.4 消息积压问题

- 9 秒杀高可用架构 

 - 9.1 可用性和高可用概念

 - 9.2 高可用系统设计思想

 - 9.3 产品层面的高可用设计

 - 9.4 研发规范层面

 - 9.5 应用服务层面的高可用设计

 - 9.5.1 应用层的无状态和负载均衡设计

 - 9.5.2 应用层的弹性伸缩设计

 - 9.5.3 应用层的异步解耦和削峰设计（消息队列）

 - 9.5.4 应用层的故障和容错设计

 - 9.5.5 应用层的资源隔离设计

 - 9.6 过载保护设计（限流、熔断、降级）

- 10 秒杀的限流架构

 - 10.1 对同一用户限流

 - 10.2 对同一商品id 限流

 - 10.3 对接口限流

- 11 秒杀的熔断架构

    -熔断策略的落地

- 12 秒杀的降级架构

    -缓存降级与DB降级

 - 降级和熔断的异同

    -相同点

    -不同点

- 13 秒杀的存储架构

- 14 运维部署层面的架构

- 15 秒杀的多IDC机房双活高可用架构

- 16 秒杀的应急预案架构

- 说在最后：有问题找老架构取经

1 秒杀系统的业务架构

1.1 秒杀系统的业务特点

1. 时间紧迫：
   秒杀活动通常设置在特定的时间段内进行，时间限制通常非常短，从几分钟到几小时不等。用户必须在规定时间内完成购买，增加了活动的紧迫感和参与热情。
2. 数量有限：
   秒杀商品的数量通常非常有限，远少于潜在购买者的数量。这种稀缺性促使用户迅速采取行动，生怕错过机会。
3. 价格极低：
   秒杀商品的价格通常比市场价低得多，甚至可能低于成本价。超低的价格吸引了大量用户参与，形成抢购热潮。
4. 竞争激烈：
   由于时间紧迫和数量有限，用户之间的竞争非常激烈。很多人会提前准备，甚至使用抢购软件，尽一切可能在最短时间内完成购买。
5. 营销效果强：
   秒杀活动具有很强的营销效果。超低价格和紧迫感吸引了大量用户访问和参与，提升了品牌知名度和用户活跃度。即使用户没有成功购买，也可能被吸引到平台上的其他商品和活动中。
6. 社交传播：
   秒杀活动容易引发用户之间的讨论和分享。用户可能会通过社交媒体分享秒杀信息，进一步扩大活动的影响力和参与度。

1.2 秒杀暴露与秒杀按钮

（2）用户维度的业务流程。

1.3 秒杀的验证码设计

2 秒杀系统的流量架构

2.1秒杀系统的流量特点

• 限时：秒杀活动如同“昙花一现”，在规定的时间内进行。举例来说，活动仅限于某天上午10点到10点半，过时不候。
• 限量：商品数量如“凤毛麟角”，秒杀活动中商品的数量有限，譬如只有10万件，售完为止。
• 限价：价格低廉，犹如“白菜价”。商品价格远远低于原来的价格，例如1元购等业务场景，吸引众多用户争先恐后。
• 这些限制条件可以“单打独斗”，也可以“联袂登场”，相辅相成，增加活动的吸引力和紧迫感。

• 提前配置：活动需要未雨绸缪，提前配置好各项内容，做到“未雨绸缪”。
• 信息展示：活动尚未开始时，用户可以查看相关信息，做到“心中有数”。
• 大力宣传：在秒杀活动开始前，广而告之，宣传造势，做到“声势浩大”。

• 大量用户：购买人数如“过江之鲫”，商品会迅速售罄。
• 高并发访问：系统流量如“井喷”般激增，并发访问量极高。大多数秒杀场景下，商品在“转瞬之间”即被抢购一空，宛如“争分夺秒”的竞技场。

• 瞬时凸峰 (流量突刺)
• 漏斗模型

1. 秒杀前访问量平稳：在秒杀活动开始前，小米秒杀系统的访问量相对平稳，没有显著变化。
2. 秒杀时刻的并发量激增：秒杀活动通常在上午10点开始，活动开始时，系统的并发访问量会瞬时激增，导致流量出现突刺现象。

1. 平时访问量平缓：在平常日子里，12306网站的访问量相对稳定，没有显著的波动。
2. 春运期间访问量激增：每年春运时节，12306网站的访问量会出现瞬时突增的现象。大量用户在短时间内涌入网站，导致访问量急剧上升。

2.2 高并发 吞吐量 规划和评估

2.3 QPS 预估（漏斗型）

2.4 通过二八定律进行流量预估

2.5 性能压测评估

3 秒杀的异步架构

3.1 同步模式的下单流程

1. 识别验证码是否正确
   商城服务需“火眼金睛”，判断用户提交的验证码是否正确，确保只有“名副其实”的用户才能继续操作。
2. 判断活动是否已经结束
   验证当前秒杀活动是否已经“曲终人散”，防止用户在活动结束后依然发起请求。
3. 验证访问请求是否处于黑名单
   在电商领域中，恶意竞争犹如“鬼蜮伎俩”。其他商家可能会通过不正当手段占用系统资源。
   此时，商城服务需要使用风控系统等实现黑名单机制，如“庖丁解牛”般识别并拦截恶意请求。为了简单，也可以使用拦截器统计访问频次，形成“黑名单”。
4. 验证真实库存是否足够
   系统需“运筹帷幄”，验证商品的真实库存是否充足，确保能够支持本次秒杀活动的需求。
5. 扣减缓存中的库存
   在秒杀业务中，商品库存等信息通常存放在缓存中。此时，需要“未雨绸缪”，验证并扣减秒杀活动商品的库存，确保“货真价实”。
6. 计算秒杀的价格
   由于秒杀活动中的商品价格与真实价格存在差异，需要“精打细算”，计算商品的秒杀价格，确保用户享受到“物超所值”的优惠。
7. 下订单
   将用户提交的订单信息“名正言顺”地保存到数据库中，确保每一笔交易都有据可查，如同“案牍劳形”般细致入微。
8. 扣减真实库存

3.2 两阶段异步下单流程

1. 识别验证码是否正确
   商城服务需“火眼金睛”，判断用户提交的验证码是否正确，确保只有“名副其实”的用户才能继续操作。
2. 判断活动是否已经结束
   验证当前秒杀活动是否已经“曲终人散”，防止用户在活动结束后依然发起请求。
3. 验证访问请求是否处于黑名单
   在电商领域中，恶意竞争犹如“鬼蜮伎俩”。其他商家可能会通过不正当手段占用系统资源。
   此时，商城服务需要使用风控系统等实现黑名单机制，如“庖丁解牛”般识别并拦截恶意请求。为了简单，也可以使用拦截器统计访问频次，形成“黑名单”。
4. 验证真实库存是否足够
   系统需“运筹帷幄”，验证商品的真实库存是否充足，确保能够支持本次秒杀活动的需求。
5. 扣减缓存中的库存
   在秒杀业务中，商品库存等信息通常存放在缓存中。此时，需要“未雨绸缪”，验证并扣减秒杀活动商品的库存，确保“货真价实”。

1. 计算秒杀的价格
   由于秒杀活动中的商品价格与真实价格存在差异，需要“精打细算”，计算商品的秒杀价格，确保用户享受到“物超所值”的优惠。
2. 下订单
   将用户提交的订单信息“名正言顺”地保存到数据库中，确保每一笔交易都有据可查，如同“案牍劳形”般细致入微。
3. 扣减真实库存

3.3 三阶段异步下单流程

4 电商系统的分层架构

4.1 经典电商系统的分层架构

• 假如流量接入层使用的是高性能的Nginx，则我们可以预估Nginx最大的并发度为：10W+，这里是以万为单位。
• 假设服务层我们使用的是Tomcat，而Tomcat的最大并发度可以预估为800左右，这里是以百为单位。
• 假设持久层的缓存使用的是Redis，数据库使用的是MySQL，MySQL的最大并发度可以预估为1000左右，以千为单位。Redis的最大并发度可以预估为5W左右，以万为单位。

4.2 秒杀系统的分层架构

4.3 秒杀架构的一些特殊方案

1. 动静分离架构
2. CDN加速
3. 缓存
4. mq异步处理
5. 限流
6. 分布式锁
7. 系统扩容：系统扩容包括垂直扩容和水平扩容，增加设备和机器配置，绝大多数的场景有效。

5 秒杀的动静分离架构

• 静态 秒杀页面资源：一个html文件，包括 css、js和图片等，内容包括秒杀产品的介绍，详情，参数等等。静态秒杀静态资源文件提前缓存到CDN上，让用户能够就近访问秒杀页面。
• 动态秒杀的exposed-key，通过JS异步获取。秒杀暴露就是将符合条件的秒杀 暴露给用户，以便互联网用户能参与商品的秒杀。这个操作可以是商户手动完成，生产场景下的更合理的方式是系统定时任务去完成。秒杀暴露主要是生成一个 具备实效性的 exposed-key。

6 秒杀的缓存架构

6.1 读多写少大杀器：缓存架构

6.2 缓存的三大经典问题

6.3 缓存击穿

解决方案

本地锁的问题

• 1.当前总库存为 100，被缓存在 Redis 中。
• 2.库存微服务 A 用本地锁扣减库存 1 之后，总库存为 99。
• 3.库存微服务 B 用本地锁扣减库存 1 之后，总库存为 99。
• 4.那库存扣减了 2 次后，还是 99，就超卖了 1 个。

6.4 缓存穿透

缓存穿透 带来的风险

缓存穿透为什么会产生缓存穿透

• 业务层误操作：缓存中的数据和数据库中的数据被误删除了，所以缓存和数据库中都没有数据；
• 恶意攻击：专门访问数据库中没有的数据。

缓存穿透解决方案

• 对结果 null 进行缓存，并加入短暂的过期时间。
• 使用布隆过滤器快速判断数据是否存在，避免从数据库中查询数据是否存在，减轻数据库压力。
• 前端进行请求检测。把恶意的请求（例如请求参数不合理、请求参数是非法值、请求字段不存在）直接过滤掉，不让它们访问后端缓存和数据库。

缓存穿透的一大利器：布隆过滤器

6.5 缓存雪崩

• 缓存全盘宕机，缓存挂了，
• 大量key在同一时间过期

缓存雪崩 带来的风险

缓存雪崩 解决方案

• 提高缓存可用性

1. 集群部署：通过集群来提升缓存的可用性，可以利用Redis本身的Redis Cluster或者第三方集群方案如Codis等。
2. 多级缓存：设置多级缓存，设置一级缓存本地 guava 缓存，第一级缓存失效的基础上再访问二级缓存 redis，每一级缓存的失效时间都不同。

• 过期时间

1. 均匀过期：为了避免大量的缓存在同一时间过期，可以把不同的 key 过期时间随机生成，避免过期时间太过集中。在原有的实效时间基础上增加一个碎挤汁，比如 1-5 分钟随机，降低缓存的过期时间的重复率，避免发生缓存集体实效。
2. 热点数据永不过期。

• 熔断降级

1. 服务熔断：当缓存服务器宕机或超时响应时，为了防止整个系统出现雪崩，可以使用hystrix 类似的熔断，暂时停止业务服务访问db, 或者其他被依赖的服务，避免 MySQL 被打死。
2. 服务降级：当出现大量缓存失效，而且处在高并发高负荷的情况下，在业务系统内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的 fallback（退路）错误处理信息。

7 库存扣减场景下的数据一致性架构

1. 预扣减启动：当用户发起购买请求时，系统首先在Redis中检查并预扣减库存数量。
2. 并发处理：通过 Redis可以高效地处理高并发请求，确保多个用户同时请求同一商品时不会导致DB 锁定或延迟。

1. 最终扣减：下单服务收到 MQ的 下单消息后，下单服务会在数据库中进行最终的库存扣减。
2. 数据一致性：在数据库中更新库存确保数据的一致性和持久性。

1. 超时处理：如果用户在规定时间内未完成支付，系统将识别支付超时。
2. 库存回退：系统会将之前预扣减的库存数量从Redis中释放，并在数据库中恢复相应的库存数量，确保库存的准确性。

7.1 第一阶段 redis预扣减库存

1. 预扣减启动：当用户发起购买请求时，系统首先在Redis中检查并预扣减库存数量。
2. 并发处理：通过 Redis可以高效地处理高并发请求，确保多个用户同时请求同一商品时不会导致DB 锁定或延迟。

 boolean exist = redisClient.query(productId,userId);
  if(exist) {
    return -1;
  }
  int stock = redisClient.queryStock(productId);
  if(stock <=0) {
    return 0;
  }
  redisClient.incrby(productId, -1);
  redisClient.add(productId,userId);
return 1;

1. 先判断该用户有没有秒杀过该商品，如果已经秒杀过，则直接返回-1。
2. 查询库存，如果库存小于等于0，则直接返回0，表示库存不足。
3. 如果库存充足，则扣减库存，然后将本次秒杀记录保存起来。然后返回1，表示成功。

 StringBuilder lua = new StringBuilder();
  lua.append("if (redis.call('exists', KEYS[1]) == 1) then");
  lua.append("    local stock = tonumber(redis.call('get', KEYS[1]));");
  lua.append("    if (stock == -1) then");
  lua.append("        return 1;");
  lua.append("    end;");
  lua.append("    if (stock > 0) then");
  lua.append("        redis.call('incrby', KEYS[1], -1);");
  lua.append("        return stock;");
  lua.append("    end;");
  lua.append("    return 0;");
  lua.append("end;");
  lua.append("return -1;");

1. 先判断商品id是否存在，如果不存在则直接返回。
2. 获取该商品id的库存，判断库存如果是-1，则直接返回，表示不限制库存。
3. 如果库存大于0，则扣减库存。
4. 如果库存等于0，是直接返回，表示库存不足。

7.2 第二阶段 数据库扣减库存

1. 最终扣减：下单服务收到 MQ的 下单消息后，下单服务会在数据库中进行最终的库存扣减。
2. 数据一致性：在数据库中更新库存确保数据的一致性和持久性。

update product set stock=stock-1 where id=123;

int stock = mapper.getStockById(123);
if(stock > 0) {
  int count = mapper.updateStock(123);
  if(count > 0) {
    addOrder(123);
  }
}

ZooKeeper分布式计数器、分布式锁、分布式ID生成器等基础知识，也是大家必须系统学习和掌握的知识，但是不在这里介绍，如果对这一块不了解，请翻阅本书姊妹篇书籍《Java高并发核心编程 卷1（加强版）：NIO、Netty、Redis、ZooKeeper》。

7.3 redis分布式锁 实现库存扣减一致

基础的 setNx命令加锁

if (jedis.setnx(lockKey, val) == 1) {
   jedis.expire(lockKey, timeout);
}

• key不存在时创建，并设置value和过期时间，返回值为1；成功获取到锁；
• 如key存在时直接返回0，抢锁失败；
• 持有锁的线程释放锁时，手动删除key； 或者过期时间到，key自动删除，锁释放。

所以,需要保障setnx和expire两个操作的原子性，要么全部执行，要么全部不执行，二者不能分开。

• 使用set的命令时，同时设置过期时间，不再单独使用 expire命令
• 使用lua脚本，将加锁的命令放在lua脚本中原子性的执行

基于纯Lua脚本的分布式锁的执行流程

加锁的Lua脚本： lock.lua

--- -1 failed
--- 1 success
---
local key = KEYS[1]
local requestId = KEYS[2]
local ttl = tonumber(KEYS[3])
local result = redis.call('setnx', key, requestId)
if result == 1 then
    --PEXPIRE:以毫秒的形式指定过期时间
    redis.call('pexpire', key, ttl)
else
    result = -1;
    -- 如果value相同，则认为是同一个线程的请求，则认为重入锁
    local value = redis.call('get', key)
    if (value == requestId) then
        result = 1;
        redis.call('pexpire', key, ttl)
    end
end
--  如果获取锁成功，则返回 1
return result

解锁的Lua脚本： unlock.lua：

--- -1 failed
--- 1 success

-- unlock key
local key = KEYS[1]
local requestId = KEYS[2]
local value = redis.call('get', key)
if value == requestId then
    redis.call('del', key);
    return 1;
end
return -1

7.4 redisson 分布式锁 实现库存扣减一致

1. 添加依赖： 在 Maven 或 Gradle 项目中添加 Redisson 的依赖。

    <!-- Maven 依赖 -->
   <dependency>
       <groupId>org.redisson</groupId>
       <artifactId>redisson</artifactId>
       <version>3.16.3</version>
   </dependency>
   

2. 配置 Redisson： 配置 Redisson 客户端以连接到 Redis 服务器。

     config = new Config();
   config.useSingleServer().setAddress("redis://127.0.0.1:6379");
   RedissonClient redissonClient = Redisson.create(config);
   

3. 获取分布式锁： 使用 RedissonClient 获取锁。

   java复制代码RLock lock = redissonClient.getLock("anyLock");
   lock.lock(); // 获取锁
   try {
       // 执行需要加锁的业务逻辑
   } finally {
       lock.unlock(); // 释放锁
   }
   

锁的续期问题

1. 获取锁时启动 Watch Dog： 当客户端获取锁时，Redisson 会启动一个看门狗线程。
2. 定期续期： Watch Dog 会每隔一段时间（默认10秒）检查锁的状态，并自动续期。续期时间为锁的默认租约时间的一半（默认30秒）。
3. 续期机制： 在租约时间快到期时，Watch Dog 会发送续期请求，将锁的租约时间延长。这样即使业务逻辑执行时间较长，也不会因为锁超时而被其他线程获取。

java复制代码// 配置 Redisson
Config config = new Config();
config.useSingleServer().setAddress("redis://127.0.0.1:6379");
RedissonClient redissonClient = Redisson.create(config);

// 获取分布式锁
RLock lock = redissonClient.getLock("anyLock");

// 获取锁（默认30秒租约时间）
lock.lock();
try {
    // 执行业务逻辑
    // Watch Dog 会每隔10秒自动续期，续期时间为30秒
} finally {
    lock.unlock(); // 释放锁
}

// 获取锁时指定持有时间
RLock lock = redissonClient.getLock("anyLock");
lock.lock(10, TimeUnit.SECONDS); // 锁会在10秒后自动释放 ,不会触发看门狗

7.5 redisson 分段锁 实现库存扣减一致

7.6 第三阶段： 支付超时，库存回退

8 秒杀的mq异步架构

• 消息0丢失架构

8.1 MQ的消息0丢失架构

8.2 MQ消息的幂等性架构

8.3 垃圾消息问题

8.4 消息积压问题

9 秒杀高可用架构

9.1 可用性和高可用概念

9.2 高可用系统设计思想

• 做好产品层面的高可用设计，主要是兜底策略。
• 做好研发规范，系统都是研发人员设计和编码写出来的，因此首先要对研发层面有一个规范和标准
• 做好容量规划和评估，主要是让开发人员对系统要抗住的量级有一个基本认知，方便进行合理的架构设计和演进。
• 做好服务层面的高可用，主要是负载均衡、弹性伸缩、异步解耦、故障容错、过载保护等。
• 做好存储层面的高可用，主要是冗余备份（热备、冷备）、失效转移（确认，转移，恢复）等。
• 做好运维层面的高可用，主要是发布测试、监控告警、容灾、故障演练等。
• 做好多IDC机房层面的高可用，比如秒杀的多IDC机房双活高可用架构
• 做好应急预案，主要是在出现问题后怎么快速恢复，不至于让我们的异常事态扩大。

9.3 产品层面的高可用设计

• 比如，当我们的页面获取不到数据的时候，或者无法访问的时候，要如何友好的告知用户，比如【稍后重试】之类的。
• 比如 当我们的真实的页面无法访问的时候，那么需要产品提供一个默认页面，如果后端无法获取真实数据，那么直接渲染默认页面。
• 比如服务器需要停机维护，那么产品层面给一个停机页面，所有用户只会弹出这个停机页面，不会请求后端服务
• 比如抽奖商品给一个默认兜底商品
• ...

9.4 研发规范层面

• 规范好相关方案设计文档的模板和提纲，让团队内部保持统一，
• 方案设计后一定要进行评审，新项目一定要评审，重构项目一定要评审，大的系统优化或者升级一定要评审，其他的一般研发工作量超过一周的建议要评审的。

• 工程的 layout 目录结构规范，团队内部保持统一，尽量简洁
• 日志规范，不要随便打日志，要接入远程日志
• 遵循团队内部的代码规范，一般公司都有对应语言的规范，如果没有则参考官方的规范，代码规范可以大大减少 bug 并且提高可用性。
• 执行代码规范
• 要能够分布式链路追踪
• 单测覆盖率，代码编写完需要有一定的单测来保证代码的健壮性，同时也能保障我们后续调整逻辑或者优化的时候可以保证代码的稳定。包括增量覆盖率、全量覆盖率，具体的覆盖率要达到多少可以根据团队内部的实际情况来定，在我们团队，定的规则是 50% 的覆盖率。

9.5 应用服务层面的高可用设计

• 应用层的无状态和负载均衡设计
• 应用层的弹性伸缩设计
• 应用层的异步解耦和削峰设计（消息队列）
• 应用层的故障和容错设计
• 应用层的资源隔离设计

9.5.1 应用层的无状态和负载均衡设计

9.5.2 应用层的弹性伸缩设计

• 一旦发现现有的微服务Provider能力不够，运维人员就会开启新的Java服务并且动态地加入集群；
• 一旦发现现有的微服务Provider能力有富余，运维人员就会关闭部分Java服务，这些Provider会动态地离开集群。

9.5.3 应用层的异步解耦和削峰设计（消息队列）

• 异步解耦：采用消息队列之后，可以把同步的流程转换为异步的流程，消息生成者和消费者都只需要和消息队列进行交互，这样不仅做了异步处理，还讲消息生成者和消费者进行了隔离。
  异步处理的优势在于，不管消息的后续处理的业务服务是否 ok，只要消息队列还没满，那么就可以执行对外提供服务，而消费方则可以根据自身处理能力来消费消息后进行处理。
  解耦的优势在于，如果消费方异常，那么并不影响生产方，依然可以对外提供服务，消息消费者恢复后可以继续从消息队列里面消费数据后执行业务逻辑
• 削峰：采用消息队列之后，还可以做到削峰的作用，当并发较高的时候，甚至是流量突发的时候，只要消息生产者能够将消息写入到消息队列中，那么这个消息就不会丢，后续处理逻辑可以慢慢的去消息队列里面消费这些突发的流量数据。这样就不会因为有突发流量而把整个系统打垮。

9.5.4 应用层的故障和容错设计

• 遵循 fail fast 原则，Fail fast 原则是说，当我们的主流程的任何一步出现问题的时候，应该快速合理地结束整个流程，尽快返回错误，而不是等到出现负面影响才处理。
• 具备自我保护的能力。当我们依赖的其他服务出现问题的时候，要尽快的进行降级、兜底等各种异常保护措施，要避免出现连锁反应导致整个服务完全不可用。比如当我们依赖的数据存储出现问题，我们不能一直重试从而导致数据完全不可用。

9.5.5 应用层的资源隔离设计

9.6 过载保护设计（限流、熔断、降级）

• 限流。
  限流是指对进入系统的请求进行限流处理，如果请求量超过了我们系统最大处理能力或者超过了我们指定的处理能力，那么直接拒绝请求，通过这种丢弃部分请求的方式可以保证整个系统有一定的可用性，从而不至于让整个系统完全不可用。
  怎么判别超过最大处理能力呢？一般就是针对 QPS 来判别，如果 QPS 超过阈值，那么就直接拒绝请求。
  限流有很多细节的策略，比如针对接口限流、针对服务限流、针对用户限流。
• 熔断。
  熔断，断路（开路）的价值在于限制故障影响范围。
  我们希望控制、减少或中断和故障系统之间的通信，从而降低故障系统的负载，有利于系统的恢复。
  一般我们的服务都会有很多下游依赖，如果下游依赖的服务出现问题，比如开始超时甚至响应非常慢的情况下，如果我们不做任何处理，那么会导致我们的整个请求都被卡住从而超时，那么我们的业务服务对外就无法提供任何正常的功能了。
  为此，熔断策略就可以解决这个问题，熔断就是当我们依赖的下游服务出现问题的时候，可以快速对其进行熔断（不发起请求），这样我们的业务服务至少可以提供部分功能。
• 降级。
  降级是指我们划分好系统的核心功能和非核心功能，然后当我们的系统超过最大处理能力之后，直接关闭掉非核心的功能，从而保障核心功能的可用。
  关闭掉非核心的功能后可以使我们的系统释放部分资源，从而可以有资源来处理核心功能。

10 秒杀的限流架构

• 当高并发的流量涌入进来，比如突然间100万QPS，系统废了。
• 应该10万QPS进入系统，其他90万QPS被拒绝了。

1. 基于nginx限流
2. 基于redis限流

10.1 对同一用户限流

10.2 对同一商品id 限流

10.3 对接口限流

11 秒杀的熔断架构

熔断策略的落地

把依赖划分为强依赖（如审核）、弱依赖（如粉丝勋章）。

12 秒杀的降级架构

缓存降级与DB降级

降级和熔断的异同

相同点

• 为了保证集群大部分服务的可用性和可靠性，防止崩溃，牺牲小我
• 用户最终都是体验到某个功能不可用

不同点

• 熔断是被调用方故障，触发的系统主动规则
• 降级是基于全局考虑，停止一些正常服务，释放资源

13 秒杀的存储架构

• 1 高并发的在线ACID事务 （分库分表）
• 2 高并发的在线搜索 （倒排表副本）
• 3 海量数据的离线处理 （高可用+全量副本）
• 4 冗余表双写能力 （不同业务维度的副本）

• 把商品数据冗余存储在Elasticsearch中，实现高速搜索
• 把商品数据冗余存储在redis 中，实现高速缓存

• 用户维度的在线ACID 事务订单处理能力，需要进行用户维度的分库分表。
• 商家维度的在线ACID 事务订单处理能力，需要进行商家维度的分库分表。

• 好处是满足各种各样的处理要求
• 坏处是我们要维护多个副本之间的数据一致。

• 要求 mysql 与 es 做到秒级别的数据同步。
• 要求 mysql 与 redis 做到秒级别的数据同步。
• 要求 mysql 与 hbase 做到秒级别的数据同步。

• 高并发搜索ES圣经：从0到1, 从入门到 ElasticSearch 工业级使用
• 100亿级任务调度篇：从0到1, 从入门到 XXLJOB 工业级使用（已经发布）
• 100亿级海量存储篇：从0到1, 从入门到 HABSE 工业级使用
• 100亿级离线计算篇：从0到1, 从入门到 Flink 工业级使用

14 运维部署层面的架构

尼恩提示： 文章太长，这个是一个架构大杀器，下一篇给大家发布，也可以找尼恩领取 《秒杀圣经》PDF

15 秒杀的多IDC机房双活高可用架构

尼恩提示： 文章太长，这个是一个架构大杀器，下一篇给大家发布，也可以找尼恩领取 《秒杀圣经》PDF

16 秒杀的应急预案架构

尼恩提示： 文章太长，这个是一个架构大杀器，下一篇给大家发布，也可以找尼恩领取 《秒杀圣经》PDF

说在最后：有问题找老架构取经

• 大龄男的最佳出路是 架构+ 管理
• 大龄女的最佳出路是 DPM，

部分历史案例

• 被裁太爽：每月大涨1W，10年CRUD小伙，靠转架构一个月上岸，年薪50W爽歪了！

• 小白转架构，逆涨30%：CRUD小伙7年，狠卷3个月升级为架构师，爽爆了

• 绝地逢生：9年经验自考小伙伴，跟着尼恩狠卷3月硬核技术，面试机会爆表，2周后收3个offer ，满血复活

• 硬转架构：35岁被裁6个月 职业绝望，转架构急救上岸，DDD和3高项目太重要了
  

• 逆天改命：3年经验2本，卷3个月涨薪60%，进准大厂(得物、乐信、58集团等)，年薪36W

• 女35岁CRUD程序媛，12月被裁后，拿30个机会2个offer上岸，年底大裁员太不容易了

• 38还有救吗？有。42岁被裁2年天快塌了，急救1个月上岸，成开发经理offer，起死回生

• 被裁不慌，9年小伙1个月喜提年薪60W offer，做中间件架构，爽歪了

• 12年小伙转架构，1小时蜕变收年薪55万offer，秘诀：GO+Java双栖架构

• 年薪百万：40岁小伙被裁6个月，跟着尼恩猛卷3月硬核技术，100W年薪逆袭 ，上岸秘诀：首席架构/总架构

• 不怕裁员，8年小伙去中年危机，秘诀：换架构师赛道，上得厅堂，下得厨房，越早越好

• 被裁员后因祸得福，拿N+1后，逆涨30%，如何实现？

• 逆天啦：4年crud小伙收shein+银行两优质offer，狠卷1月收年薪43万大涨30%

• 原来，拿大厂offer 有捷径......

• 太劲爆.... 被裁4个月，38岁Android转Java，2个月提架构offer

• 起死回生：8年小伙高中毕业+频繁跳槽，狠卷2月，提Java高级offer

• 爽翻了：指导3轮，5年小伙收5大offer，涨50%，领路模式太牛

• 降维攻击，37年大龄老伙喜提60W年薪offer，1个月顺利上岸

• 架构速成：从一面杀到一次过，记7年女架构的速成经历

• 极速拿offer：阿里P6被裁后极速上岸，1个月内喜提2优质offer(含滴滴)

• 大逆袭：做化工12年，35岁转Java，被裁4个月后，1个月收架构Offer，大龄跨行，超级牛

• 被裁后炸爽：10年小伙12天火速上岸，反涨20%，爽暴了

• 裁就裁，6年小伙60W极速上岸，白拿20W还游一圈拉萨，真香

• 极速拿offer：被毕业3个月，11年经验小伙0.5个月极速拿offer，领路模式的巨大威力

• 惊天大逆袭：8年小伙20天时间提75W年薪offer，逆涨50%，秘诀在这