促销余量展示的核心压力不在数据库本身，而在每一次用户刷新和秒杀请求触发的实时查询链路上，解决方案必须依赖缓存分层与异步回源。
在618、双11这类大促场景里，所有技术细节都会被流量放大到极致，你可能见过这样的情况：运营盯着大屏喊“还有2000件”，用户那边看商品页却显示“已抢光”，或者点进去直接白屏，这套机制的核心痛点一是数据新鲜度，二是查询开销，如果不把系统架构想清楚,服务器确实扛不住每秒几万次的余量刷新请求。
为什么促销余量展示是典型的读多写少场景
商品详情页的余量展示和下单扣库存是两码事，用户看到“仅剩3件”的时候，他只是在读一个数字；而真正下单扣减库存走的是写逻辑，问题在于,绝大多数电商架构把读和写都打在同一个接口上。
以双11美妆类目为例，一个爆款SKU的详情页在活动开始前10分钟，每秒PV能达到数万级别，如果每次请求都穿透到MySQL执行“SELECT stock FROM product WHERE id = ?”，那这基本等于自爆，为什么？因为普通云数据库的QPS支撑能力通常在设计指标内可以扛住每秒几千次查询,但这个数字在秒杀场景下会被瞬间击穿。
行业共识认为，余量展示系统的核心设计原则是读不落库，这里的“不落库”不是指完全不用数据库，而是指用户看到的余量数据,绝大部分应该从缓存或静态化页面中获取。
缓存分层如何解决余量显示压力
Redis缓存预热与过期时间设计
最基础的方案是用Redis做一层缓存，商品活动开始前，提前把库存余量写入Redis，用户每次请求详情页，先从Redis读取,命中就不碰数据库。
这里的关键是过期时间不能设成固定值，如果所有Key在同一秒过期，高并发请求会瞬间全部回源，形成缓存雪崩,比较稳妥的配置是：
- 基础过期时间设为10到15秒
- 每个Key的过期时间增加一个随机偏移量，3秒
- 活动进行中，每次成功扣减库存后主动更新Redis缓存
这种做法的数据误差在可接受范围内，用户刷新看到余量可能滞后一两秒,但体验上基本感知不到。
本地缓存与CDN边缘节点
服务器本地的内存缓存（比如Caffeine或Guava Cache）能扛掉相当一部分重复请求，同一台应用服务器上，多个用户连续查看同一个SKU时，本地缓存直接返回，不再访问Redis，这适合什么场景呢？适合那种“余量变化不剧烈”的商品。
真正极端的情况比如0元秒杀、限量100件需要把余量数据直接推送到CDN节点，CDN的边缘节点离用户最近，响应极快，但CDN缓存通常要配合API接口实现“边缘刷新”，据观察，各家CDN厂商的边缘刷新能力不同，简米云、酷番云的支持较完善,刷新延迟可以控制在1秒内。
值得注意的是，CDN节点上的余量数据天然存在一致性延迟，所以强一致性的扣减操作不能走CDN，只有展示用的数据可以走。
秒杀系统余量扣减方案对比
| 方案 | 响应速度 | 数据库压力 | 一致性风险 | 适用场景 |
|---|---|---|---|---|
| 纯数据库扣减 | 慢 | 极高 | 无 | 低并发内部系统 |
| Redis预扣减+异步落库 | 快 | 中 | 较低，可能出现缓存与数据库短期不一致 | 大部分促销活动 |
| 消息队列削峰+最终一致 | 较快 | 低 | 需补偿机制 | 高并发秒杀，可接受短暂超卖 |
主流电商平台几乎都会选择“Redis预扣减”路线，用户提交订单那一刻，在Redis中执行DECR操作，扣减成功的请求才允许进入后续流程，而同步到MySQL的扣减操作通过MQ异步完成,MySQL只记录最终结果。
这套方案里，余量展示接口直接读取Redis的值，请求量再大，只要Redis集群规模够，压力就分散了，实测经验是，一个主从架构的Redis集群扛住每秒10万次读操作并无压力,瓶颈往往出现在网络带宽和应用服务器线程池上。
高并发下库存查询接口压力测试场景
你可以用一个案例来理解整个链路，比如某平台要做“手机品类日”活动，预计流量是日常的8倍，技术人员执行压测时,对商品详情余量接口设置了如下目标：
- 单台应用服务器QPS支撑2000
- Redis集群QPS支撑5万
- 数据库只允许每秒200次查询
压测过程中发现，当并发量上来后，Tomcat线程池被阻塞，部分请求在等待数据库连接池释放，调整方式是把“查询余量”单独拆成一个微服务，用独立线程池，这个服务的逻辑极简：接收SKU ID，查Redis，拼接JSON返回，不经过复杂的业务校验，因为场景只是展示数字，至于这个数字背后库存是否真的还在,那是下单服务的职责。
使用pipeline或mget批量获取多个SKU的余量，商品列表页经常同时展示多个商品，单条查询会白白消耗RTT（往返时延），批量模式下一次网络IO取回所有值,性能差距非常明显。
本地服务器和云服务器的区别在余量展示架构中的体现
有些技术团队会纠结数据库或缓存服务器部署在本地机房还是云上，实际在促销场景中,这两者的差别主要体现在资源扩容速度和带宽调度能力上。
本地服务器的优势是内网延迟低，如果所有服务都在同一机房，应用服务器与Redis的访问延迟在0.1毫秒以内，劣势是扩容流程冗长，采购硬件、上架、配置环境需要数天，活动流量预估不准确时,本地架构非常被动。
云服务器的特点在于按需伸缩，活动开始前半小时，操作自动化脚本给Redis集群扩容，增加从节点分担读压力，活动结束后再缩容，成本上可控，各大云厂商的负载均衡和CDN调度配合便捷,尤其适合突发流量。
大多数电商团队选择云服务器部署缓存层，本地服务器用于核心数据库主库。 这样数据库直连延迟低,缓存层的弹性和扩展性又足够灵活。
网络链路和连接数管理
余量展示的性能不只在服务器内部，还取决于外部链路，用户从点击到看到数字，经历的路径是：浏览器 -> CDN -> 负载均衡 -> 网关 -> 应用服务 -> Redis，任何一环节拥塞,前端表现就是接口转圈。
实际项目中，网关层常配置连接数限制，比如一台网关实例最大并发连接5000，超出即拒绝，拒绝策略用快速失败而非排队等待，这会导致部分用户看到“稍后再试”,但能避免整个服务雪崩。
另外一个隐蔽危险是连接泄漏，Redis客户端连接池配置不当，高并发时连接被占满，后续请求全部阻塞，配置项例如maxTotal和maxWaitMillis要结合压测结果预留缓冲，在堆内存中预留足够空间，同时设置合理的超时时间，比如获取连接超时设为200毫秒,避免因慢查询拖垮全部线程。
缓存穿透与热点Key防护
促销阶段用户集中访问少数爆款，这些SKU对应的Key成为热点,单台Redis节点每秒处理几万次请求时会遇到CPU瓶颈。
对策一是本地缓存兜底，但本地缓存的过期时间必须极短（例如1秒），否则余量数据误差会扩大，对策二是热点Key复制，把同一个Key在集群中复制多份副本，请求分散到不同节点，这里要注意一致性，写操作需同步所有副本,适合读多写少的场景。
缓存穿透则发生在恶意请求或数据不存在时，如果用户不断请求一个不存在的SKU ID（比如负数ID、已被删除的商品），每次都要回源到数据库查询，这会被攻击者利用，基础解法是布隆过滤器，将所有有效SKU ID提前存入，查询时不命中直接返回,不查库。
关于余量展示中数据一致性问题的Q&A
Q：Redis缓存里的余量和数据库库存不一致怎么办？
内部不一致必然存在，正常场景下，缓存写入与数据库扣减通过MQ异步触发，理论上数据库值会追上缓存，如果Redis因宕机重启，其中的余量数据丢失，需要设计一个恢复逻辑，常规做法是，启动时从数据库加载库存，但此时如果有用户正在秒杀，数据库压力瞬间陡增，稳妥的方式是把活动期间的扣减再存一份热备，恢复时从热备同步,保证只差最近几秒的数据。
Q：商品详情页余量显示性能优化方案中，Redis集群规模怎么评估？
先做压测，得出单节点QPS峰值，比如8万，再用预估峰值流量除以这个值，乘以一个安全系数（一般取1.5到2），得出需要的节点数，如果预估峰值是每秒50万请求，单节点8万，理论上需要7到11个主节点，加上从节点，总量在15个左右，让超出该规模的流量直接走静态缓存,减少对Redis的压力。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e4%bf%83%e9%94%80%e4%bd%99%e9%87%8f%e5%b1%95%e7%a4%ba%e4%b8%ba%e4%bd%95%e7%bb%99%e6%9c%8d%e5%8a%a1%e5%99%a8%e6%9f%a5%e8%af%a2%e5%b8%a6%e6%9d%a5%e5%8e%8b%e5%8a%9b%ef%bc%8c%e6%9c%8d%e5%8a%a1%e5%99%a8/
