多层限流

引言：秒杀系统的终极挑战 2024年双11，某电商平台iPhone秒杀： 库存：100台 参与人数：10万人 秒杀时间：10:00:00开始 预期流量：瞬间10万QPS 不做限流的后果： 10:00:00.000 - 10万请求同时到达 ↓ 数据库：100个连接池瞬间耗尽 ↓ 应用服务器：200个线程全部阻塞 ↓ 响应时间：从50ms飙升到30秒 ↓ 系统崩溃：所有接口无法响应 ↓ 用户体验：网站打不开，投诉无数 今天，我们将设计一个完整的秒杀系统限流方案，综合运用前面学到的所有知识。 一、场景分析 1.1 业务需求 秒杀活动: 商品: iPhone 15 Pro Max 库存: 100台 价格: 6999元（原价9999元） 开始时间: 2024-11-11 10:00:00 预计参与人数: 10万人 技术指标: 系统容量: QPS 5000 数据库连接: 100个 应用线程池: 200个 Redis: 10000 QPS 1.2 系统架构 用户（10万） ↓ CDN（静态资源） ↓ ┌─────────────────────────────────┐ │ 第1层：网关限流 │ │ - 总入口QPS：5000 │ │ - 限制单用户频率 │ └────────────┬────────────────────┘ ↓ ┌─────────────────────────────────┐ │ 第2层：接口限流 │ │ - 秒杀接口：QPS 1000 │ │ - Warm Up预热 │ └────────────┬────────────────────┘ ↓ ┌─────────────────────────────────┐ │ 第3层：热点限流 │ │ - 商品维度：每个商品100 QPS │ └────────────┬────────────────────┘ ↓ ┌─────────────────────────────────┐ │ 第4层：库存扣减限流 │ │ - 线程数限流：10个 │ │ - 匀速排队 │ └────────────┬────────────────────┘ ↓ 数据库（100个连接） 二、第1层：网关限流 2.1 网关层的职责 目标： ...