一、 业务背景当“冲动消费”遇上“瞬间流量”在电商SaaS系统开发中我们经常面对一个经典难题如何在高并发抢购场景下确保库存扣减的准确性与系统的高可用性最近在迭代一个面向B端客户的全渠道零售系统时我们遇到了一个典型痛点客户计划进行一场直播带货预计流量峰值将达到平时流量的50倍以上。对于底层架构而言这不仅是性能的考验更是对数据一致性的终极大考。本文将复盘我们是如何从常规锁逐步演进到Lua脚本 Redis 本地缓存的多级缓存架构并最终利用RocketMQ进行流量削峰的过程。希望能为正在处理类似业务场景的同行提供一些参考。二、 痛点分析为什么行锁不行在初始版本中V1.0我们采用了最直观的做法数据库行锁SELECT … FOR UPDATE。java// 伪代码示例Transactionalpublic boolean decreaseStock(Long skuId, Integer quantity) {// 1. 加锁查询库存Stock stock stockMapper.selectForUpdate(skuId);// 2. 校验并扣减if (stock.getCount() quantity) {return false;}// 3. Update操作return stockMapper.updateCount(skuId, quantity);}存在的致命缺陷连接池耗尽风险每一个请求都要占用一个数据库连接等待锁释放高并发下数据库连接数瞬间打满。TPS瓶颈经过压测单节点TPS峰值仅能维持在 120/s 左右完全无法支撑直播场景。三、 演进方案Redis原子操作 异步落库为了解决数据库IO瓶颈我们决定将库存预扣操作前置到Redis中。为什么选择Lua脚本为了确保扣减、查询、判断这三个操作的原子性我们放弃了incr/decr的简单操作选择了自定义Lua脚本。lua– 库存扣减Lua脚本local key KEYS[1]local num tonumber(ARGV[1])– 获取当前库存local current tonumber(redis.call(‘get’, key) or “0”)– 判断库存是否充足if current num then– 执行扣减redis.call(‘incrby’, key, -num)return 1elsereturn 0end技术要点整个操作在Redis单线程模型中执行天然具备原子性。网络IO开销小极大提升了响应速度。缓存与数据库的双写一致性痛点引入Redis后最棘手的问题是Redis扣减成功了但数据库Update失败了怎么办这会导致超卖。我们的解决方案最终一致性 流水日志WAL。扣减操作不仅修改库存同时写入一条“库存流水”到Redis List中。后台异步任务定时Job拉取流水逐条对数据库进行落库操作并比对版本号Version。若发现Redis与DB数据不一致立即触发告警并自动触发反向补偿脚本。四、 深度优化本地缓存Caffeine的“锦上添花”在压测过程中我们发现Redis的响应时间在超高并发万级QPS下仍然存在约 0.5ms - 1ms 的网络延迟。为了极致性能我们引入了 Caffeine本地缓存。设计思路冷热分离将库存数据分为“热库存”前10%的爆款SKU和“冷库存”。失效策略本地缓存设置极短的TTL如5秒并开启自动刷新功能。javaCacheable(value “stock_cache”, key “#skuId”,sync true, unless “#result null”)public StockInfo getStockWithLocalCache(Long skuId) {// 先查Caffeine再查Redis最后查DB// 利用Caffeine的异步加载机制防止缓存雪崩击穿}避坑指南本地缓存只适合只读或弱一致性场景。对于秒杀扣减必须穿透本地缓存强制读Redis主节点防止本地缓存滞后导致超卖。五、 流量洪峰如何利用MQ进行削峰填谷即便Redis扛住了压力下游的订单中心、支付回调、物流推送等系统无法承受瞬时的流量冲击。架构调整请求进入网关层经过限流Sentinel后只进行库存预扣和生成预订单。将正式的“创建订单”消息推入 RocketMQ。消费者按照数据库能承受的速率如 500 TPS拉取消息批量写入数据库。text[用户请求] -- [Sentinel限流] -- [Redis预扣库存]– [RocketMQ发送] -- [消费者批量落库]– [异步通知用户]六、 踩坑实录关于Redis集群的坑在灰度发布时我们遇到了一个诡异问题偶尔出现库存扣减负数。排查结果由于我们使用了Redis Cluster集群Lua脚本要求所有操作的Key必须在同一个Slot槽位。我们的库存Key设计为stock:sku_{主键}但在Lua脚本中我们额外使用了stock:log_{主键}。解决方案确保Lua脚本中的所有Key都使用Hash Tag即{skuId}强制它们落在同一节点。七、 总结与展望经过这一系列的架构调整我们最终在双十一期间的压测数据如下接口RT响应时间从 350ms 降低至 45ms。核心服务TPS从 120 提升至 3500取决于Redis集群规格。数据一致性保持了 0 库存负数记录。后续规划目前我们正在探索静态化 CDN边缘计算的方案将库存判断逻辑下沉至边缘节点进一步减少源站压力。同时我们也在关注多级缓存一致性的自动探测机制。文末思考技术架构没有银弹只有最适合业务场景的解决方案。在高并发场景下妥协与平衡是架构师最需要掌握的智慧。欢迎大家在评论区交流你们在库存扣减中遇到的那些坑。