高并发秒杀系统的核心挑战
秒杀场景最头疼的就是那几秒钟的流量洪峰。去年双十一某电商平台开场1秒内涌进1200万请求，服务器差点崩掉。这种瞬时高并发带来的问题很典型：
分布式缓存的三层防御体系
Redis集群是扛流量的第一道防线。我们采用分层缓存策略：
| 缓存层级 | 响应时间 | 命中率 | 适用场景 |
|---|---|---|---|
| 本地缓存 | 0.5ms | 30-40% | 热点商品基础信息 |
| Redis集群 | 2ms | 55-65% | 库存/秒杀状态 |
| 数据库 | 15ms | 5-15% | 最终一致性数据 |
异步削峰的关键实现
用Kafka做消息队列时发现了坑：默认配置下200万消息积压会导致消费者延迟飙升。后来调整了这些参数：
订单处理改成异步流程后，高峰期系统负载从800%降到150%。用户点击”立即购买”后，前端先返回”排队中”状态，后端通过WebSocket推送处理结果。
热点数据的动态隔离方案
监测到某款手机秒杀时，其SKU的访问QPS突然冲到50万次/秒。我们立即启动了三重隔离：
这套方案把热点商品的处理延迟从3秒压到200毫秒内。特别要注意的是库存扣减必须用Redis+Lua脚本保证原子性，否则会出现超卖。脚本里要包含这些判断逻辑：
if redis.call('exists', KEYS[1]) == 1 then
local stock = tonumber(redis.call('get', KEYS[1]))
if stock >= tonumber(ARGV[1]) then
return redis.call('decrby', KEYS[1], ARGV[1])
end
end
return -1
限流熔断的精细化控制
在网关层部署了动态限流策略，根据实时监控数据自动调整：
通过Prometheus+Granfa搭建的监控看板，能实时观测到：
当库存剩余量低于总库存5%时，会触发特殊保护机制：将剩余库存随机分成10个批次释放，避免最后100件商品引发服务器崩溃。这个策略让秒杀结束阶段的服务器负载曲线变得平缓。
秒杀系统的资源准备可不是简单堆机器就行，得讲究策略。我们做过一个实战案例，目标扛住80万QPS，最终用了320台4核16G的ECS，但关键是在压测阶段发现个有趣现象：前30秒的流量往往是平均值的2-3倍，所以实际部署时把30%的机器专门做成”热备池”，通过K8s的HPA策略实现秒级扩容。数据库那边更讲究，主库用了16核64G的RDS配了600连接池，但特别设置了连接等待队列，避免突发流量把数据库直接打挂。
资源规划还得考虑成本优化。比如把静态资源全部扔到CDN，能省下40%的前端服务器；用Spot实例跑异步订单处理服务，成本直降70%。但要注意核心服务必须用按量付费的常规实例，我们吃过亏——某次大促Spot实例被回收，导致订单延迟了5-8分钟。监控系统也得跟上，Prometheus配了5个告警等级，当CPU超过60%就自动触发扩容，这样既不会浪费资源，又能确保突发流量有缓冲余地。
如何防止秒杀系统中的库存超卖问题？
最有效的方案是采用Redis+Lua脚本实现原子化库存扣减，配合数据库事务确保最终一致性。具体操作时，先在Redis中预扣库存，成功后异步同步到数据库，同时设置库存预警阈值，当剩余库存低于5%时触发限流保护。
秒杀系统应该选择哪种消息队列？
Kafka和RocketMQ都是优选，但要注意分区数配置。 根据预估QPS设置分区数，比如目标吞吐量100万QPS时，分区数 设置在50-100之间。同时要调整消费者并发数和max.poll.records参数，避免消息积压导致延迟。
如何处理秒杀场景下的热点数据？
需要建立动态监测和隔离机制：通过实时监控发现QPS突增的商品SKU，立即启用专用Redis分片；在Nginx层做基于商品ID的流量调度；对于极端热点商品（如50万QPS以上），还要在代码层使用ThreadLocal做请求级缓存。
秒杀系统需要准备多少服务器资源？
按峰值流量的3-5倍配置弹性资源。例如预估100万QPS时，需要准备300-500台4核8G的实例，并配置自动扩缩容策略。其中30%资源要预留给突发流量，数据库连接池 设置在200-500之间。
如何有效识别和拦截黄牛请求？
需要多维度风控策略：在网关层部署人机验证（滑块/短信验证码），对相同IP/设备ID的请求限流，分析用户行为特征（如页面停留时间0-1秒的请求），结合机器学习模型实时拦截异常流量。
