阿里P8面试官：聊聊双11百亿流量「高并发秒杀系统」的设计思路

双11百亿流量高并发秒杀系统的设计需围绕瞬时流量承载、库存防超卖、系统高可用、限购与防刷等核心问题展开，以下是具体设计思路：

秒杀场景下，用户请求量远超系统处理能力，需通过分层过滤减少无效请求对核心链路的冲击，核心方法包括：

• 页面静态化：将秒杀页面（如商品详情、规则说明）转化为静态HTML，通过CDN分发至全球节点，用户直接访问静态资源，避免动态渲染消耗服务器资源。
• 缓存预热：提前将商品信息、库存数据加载至Redis等缓存中，减少活动开始时数据库查询压力。例如，活动前1小时将库存同步至Redis，并设置合理的过期时间。
• 异步化处理：将下单、扣减库存等操作拆分为异步任务，通过消息队列（如Kafka、RocketMQ）削峰填谷。例如，用户请求先写入队列，后端服务按处理能力消费消息，避免瞬时请求压垮系统。
• 分层限流：在接入层（Nginx）、业务层（微服务）、数据层（Redis/MySQL）分别设置限流规则。例如，Nginx限制单IP每秒请求数，业务层通过Sentinel控制接口QPS，数据层对Redis操作进行速率限制。

库存超卖是秒杀核心问题，需通过技术手段确保库存扣减的原子性与一致性：

• Redis缓存库存：将库存数据存入Redis，利用其单线程特性与高并发能力（单节点10万+ QPS）承载库存查询与扣减请求。例如，使用Redis的DECR命令原子性减少库存，若返回值≥0则扣减成功。
• Lua脚本保证原子性：将“检查库存”与“扣减库存”两步操作合并为Lua脚本，避免分步执行导致的并发问题。示例脚本：local stock = tonumber(redis.call('GET', KEYS[1]))if stock >= tonumber(ARGV[1]) then return redis.call('DECRBY', KEYS[1], ARGV[1])else return 0end
• MySQL最终校验：即使Redis扣减成功，下单时仍需校验MySQL库存，防止Redis与数据库数据不一致（如Redis缓存穿透或数据未及时同步）。

秒杀系统需具备容错能力，避免局部故障引发全局崩溃：

• 流量控制（限流）：通过监控QPS、并发线程数等指标，当请求超过阈值时触发限流策略（如拒绝请求、排队等待）。例如，使用Sentinel的“匀速排队”模式，将突发流量平滑至后续时间窗口。
• 服务熔断：当下游服务（如支付、物流）响应超时或错误率升高时，上游服务主动熔断，返回默认值或降级页面，避免雪崩效应。例如，使用Hystrix配置熔断阈值（如10秒内20%请求失败则熔断5秒）。
• 多活架构：部署多地域、多可用区服务，通过DNS调度或智能路由将用户请求导向健康节点。例如，阿里云SLB支持跨地域容灾，确保单地域故障时业务自动切换。

为防止黄牛刷单，需限制用户购买次数并识别恶意请求：

• Redis计数器：使用Redis的INCR命令记录用户购买次数，例如：INCR user:123:purchase_count # 用户123购买次数+1EXPIRE user:123:purchase_count 86400 # 设置24小时过期下单前检查计数器值，若超过限购数量则拒绝请求。
• 验证码与答题机制：在关键操作（如下单页面）加入验证码或答题环节，增加自动化脚本识别难度。例如，使用滑动验证码、短信验证码或简单算术题（如“1+3=？”）。
• 行为分析：通过用户行为日志（如点击频率、访问路径）构建风控模型，识别异常请求。例如，若用户短时间内频繁访问秒杀页面，则触发二次验证或直接拦截。

秒杀涉及多系统协作（如库存、订单、支付），需确保数据最终一致：

• 分布式ID生成：使用雪花算法（Snowflake）或数据库序列生成全局唯一订单号，避免ID冲突。例如，阿里开源的UidGenerator支持高并发下的ID生成。
• 事务消息：通过消息队列实现分布式事务，例如：下单成功后发送消息至支付系统，若支付超时则触发补偿任务（如取消订单、回滚库存）。
• 定时任务校验：通过定时任务扫描异常订单（如未支付订单），自动回滚库存并释放资源。例如，使用Quartz框架配置每小时执行一次库存校验任务。

双11秒杀系统需通过分层过滤、Redis原子操作、流量控制、Redis计数器、分布式事务等技术手段，解决高并发、超卖、系统可用性、限购与数据一致性问题。实际设计中还需结合业务特点（如商品数量、用户规模）进行参数调优，并通过全链路压测（如使用JMeter模拟百万级并发）验证系统性能。