热点商品缓存分片，本质是把原本集中压在单个Redis节点上的读写请求，按商品维度或用户维度拆成多个小分片，让压力均匀散开，电商大促中，这是避免单点过载最直接、成本最低的落地手段。
热点商品缓存分片怎么做才不崩
大促秒杀时,一台Redis节点可能每秒要处理几万次读请求，普通商品缓存互不干扰，但像热门手机、限量球鞋这类商品，所有用户都在读同一个key，这个key落在哪个节点，哪个节点的CPU和网卡就会先被打满，不要指望单个Redis节点硬扛，单线程处理命令一旦排队，后面的请求全部变慢。
分片思路不复杂：给热点key加后缀，把一个key拆成多个逻辑key，例如原来读item:1001，现在读item:1001:0、item:1001:1……每个分片存的是同一份商品数据，客户端根据用户ID做哈希，决定读哪个分片，这样原来一个key的读压力，就被拆到了多个key上，分散到不同Redis节点或同一节点的不同槽位。
什么样的热点商品需要做缓存分片
判断标准可以落地到三个维度：
- 单key的QPS接近所在Redis节点的处理上限,导致同节点其他key响应变慢。
- 单key的value较大,比如包含长详情、富文本、推荐位数据，序列化和网络传输都重。
- 商品具备强时效性,库存少、抢购窗口短，用户会在几秒内集中刷新。
排查方法很直接,用redis-cli --hotkeys能粗看热点key分布，线上更常用的是在应用层统计每个key的请求量，超过阈值就触发拆分，阈值不要拍脑袋，要结合节点实际水位，业内专家指出，先把节点日常QPS峰值摸清，再给热点key预留出单独的分片池，比等故障再处理稳妥得多。
分片数量怎么定
分片数量不是越多越好,分片太多，客户端路由复杂，数据一致性维护成本也会上升。
- 先预估热点商品可能达到的并发读数。
- 再评估单个分片在现有硬件下能稳定扛住的请求量。
- 两者相除,向上取整，再留出一定冗余。
多数情况下,把单热点key拆成个位数到十几个分片，已经能覆盖大部分抢购场景，具体数量要结合压测结果调整，不能照搬固定值。
Redis缓存分片和一致性哈希对比：该用哪个
很多团队一提到分片,就想到一致性哈希，但热点商品场景下，普通一致性哈希解决不了热key集中问题。
| 对比项 | 普通一致性哈希 | 热点商品缓存分片 |
|---|---|---|
| 分片依据 | 对key做哈希后映射到节点 | 对热点key二次拆分，追加分片序号 |
| 热key表现 | 同一个key只会落在一个节点，压力集中 | 同一个商品被拆成多个key，分散读写 |
| 节点扩缩容 | 影响部分key重映射 | 分片数固定时，不受节点变化影响 |
| 一致性维护 | 数据只存一份，相对简单 | 多分片数据需同步更新或异步刷新 |
| 适用场景 | 海量普通key均匀分布 | 少数超级热key需要单独保护 |
一句话总结：一致性哈希解决的是“key多了怎么均匀分布”，热点分片解决的是“单个key太热怎么拆开”，两者不冲突，可以叠加使用，生产环境中，通常是Redis Cluster先做数据分片，再对识别出的热key做应用层二级分片。
分片写入与读取的具体命令
读取逻辑可以用伪代码描述：
- 客户端先判断商品ID是否在热点分片列表中。
- 如果是,计算
shard = hash(userId) % 分片数。 - 拼接key：
item:1001:+ shard。 - 读Redis：
GET item:1001:3。
写入逻辑要保证所有分片数据一致：
- 商品信息变更时,遍历分片数写入：
SET item:1001:0 value、SET item:1001:1 value…… - 如果分片数较多,可以只更新源缓存，再通过消息队列异步刷新各分片。
- 每个分片设置随机过期时间,防止同一时刻缓存同时失效打垮数据库。
电商大促热点缓存方案怎么落地
大促前热身阶段,经常出现某些商品被提前加购，流量一冲，Redis单节点CPU先到顶，落地热点缓存分片方案，建议按下面步骤走。
第一步：热key识别自动化
不要靠人肉盯监控,在缓存访问层加一段统计逻辑：
- 每次
GET请求，把key和当前时间戳写入本地计数。 - 每10秒汇总一次,找出请求量排名靠前的key。
- 对达到阈值的key,标记为热点，写入热点key集合。
阈值可以用“单key请求量占当前节点总请求量的较大比例”作为触发条件，不需要绝对精确。
第二步：热点key自动拆分
识别出热点后,触发拆分动作：
- 从热点key集合中取出商品ID。
- 生成本地热点分片配置：
item:1001->item:1001:0到item:1001:15。 - 把这组key分别写入缓存,数据可以先从源缓存复制。
- 配置下发到客户端,客户端读请求自动切换到分片key。
第三步：多级缓存兜底
单靠Redis分片还不够,对真正的顶流商品，可以在应用本地再加一层Caffeine或Guava缓存。
- 本地缓存只存热点商品的精简字段。
- 缓存时间控制在秒级,避免本地数据过期太久。
- 本地未命中时,再查Redis分片。
这样即使Redis分片被打满,本地缓存也能挡下一部分请求。
缓存分片服务器成本多少钱？先从内存账算起
热点分片是否要新增服务器？多数情况下不需要，分片只是把一个key拆成多个key，数据总量变化不大，多出来的主要是key数量和内存碎片，如果单个Redis实例内存还有余量，就可以在同一实例内做逻辑分片，成本几乎为零，只有当前实例内存已经吃紧，或者网卡带宽接近上限，才需要横向增加节点。
成本构成大致有三块：
- 内存：新增分片key会占一点空间，但商品数据不会等比放大。
- 网络：读请求总量不变，只是分散到不同key，整体带宽消耗基本持平。
- 运维：需要维护热点key识别和拆分脚本，属于一次性开发投入。
对比全量扩容Redis集群,热点分片省去大量新增节点的费用，对预算有限的团队，先在现有机器上做逻辑分片，是最经济的方案。
北京电商缓存架构优化中的分片实践
北京地区的电商团队常面临大促和本地仓配联动,由于用户集中在一二线城市，晚八点秒杀时段流量非常集中，北京机房内网延迟低，Redis Cluster多可用区部署比较普遍，在缓存架构优化时，热点分片可以配合以下动作：
- 把热点分片key的路由计算放在接入层完成,避免每个服务实例重复计算。
- 统一使用本地配置中心下发热点key列表,比如Apollo或Nacos。
- 对分片数据设置差异化的过期时间,比如
item:1001:0过期600秒，item:1001:1过期620秒，防止同一秒全部回源。
这种实践不是北京独有,只是北京地区电商交易密度高，对缓存架构的容错要求更严格，分片逻辑本身和地域关系不大，但部署时需要考虑多机房同步、专线延迟等现实问题。
分片后的一致性与防超卖
缓存分片后,一个商品有多个缓存副本，库存扣减如果直接读缓存，就可能出现不同用户读到不同分片，最后在数据库层产生超卖风险，行业共识认为，库存这类强一致数据不应以缓存分片为准，最终的扣减必须落到数据库事务中，缓存分片主要扛读，写操作回到数据库或单独库存服务，这样拆开后，缓存层压力下降，数据库也不会被读流量冲垮。
热点商品缓存分片不是复杂技术,但它要求先把热key识别、分片路由、数据一致性三件事想清楚，只要这三步闭环，单点过载就能从源头被分散，先从小流量活动练手，再放大到大促场景，比临时扩容更加从容。
热点商品缓存分片常见问题
热点商品缓存分片和Redis Cluster的区别是什么？
Redis Cluster解决的是数据总量太大，需要把不同key分布到多个节点，热点商品缓存分片解决的是单个key被访问太频繁，需要把同一个商品拆成多个key，两者层级不同，可以叠加使用。
缓存分片后商品库存显示会不一致吗？
会有短暂不一致,各分片缓存可能在不同时间更新，显示库存可能略有延迟，最终一致性由随机过期和异步刷新保证，强一致的库存扣减必须在数据库层完成。
缓存分片服务器成本一般多少钱？
没有固定数字,如果复用现有Redis实例，仅增加逻辑分片，成本接近于零，若需要新增物理节点，费用取决于内存规格和带宽，通常比整体扩容集群低一个量级。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/635769.html
