电商热点数据哈希槽分片案例：双11秒杀场景设计
一、场景与挑战
某电商平台在双11大促期间面临以下问题：
单商品热点压力：爆款商品（如iPhone 15）瞬时并发量达30万QPS，单一Redis节点无法承载；
数据倾斜：90%请求集中在10%的热门商品键（如product:10086:stock）；
动态扩容需求：需在1小时内完成集群从10节点扩展到20节点的平滑扩容。
二、解决方案：哈希槽分片设计
集群架构
采用Redis Cluster部署，初始配置10主节点，每个节点管理1638个槽位（16384/10）；
每个主节点挂载1个从节点，保障高可用
热点数据分片策略
复合键设计：将商品ID与用户ID组合分片，例如：
# 原热点键：product:10086:stock → 新键格式：product:10086:user_{id}:stock
slot = CRC16(f"product:10086:user_{user_id % 1000}:stock") % 16384
单个商品库存数据分散到1000个槽位，避免集中到同一节点；
槽位预分配：提前将热门商品相关槽位均匀分配到所有主节点。
三、实施流程
数据写入
// Java客户端示例：写入分散后的库存键
String key = "product:10086:user_" + (userId % 1000) + ":stock";
redisCluster.set(key, stockCount);
通过哈希计算自动路由到目标槽位对应节点。
读取优化
客户端本地缓存热点商品的部分库存数据（如最近5秒库存），降低Redis访问压力；
使用CLUSTER GETKEYSINSLOT命令监控槽位负载，动态调整槽分布。
扩容操作
新增10节点后，通过CLUSTER ADDSLOTS将原节点20%的槽位迁移到新节点；
迁移期间使用ASK重定向机制保障服务连续性。
四、效果验证
指标 分片前 分片后 优化效果
峰值QPS 5万（单节点） 30万（集群） 提升6倍
请求延迟 120ms（P99） 15ms（P99） 降低87.5%
扩容耗时 无法在线扩容 45分钟完成 支持动态扩展
五、关键优化点
虚拟槽位映射：通过user_id取模实现逻辑分片，突破物理节点限制；
读写分离：从节点承载库存查询流量，主节点专注库存扣减；
槽位监控：实时检测槽位负载，自动触发槽位再平衡。
该方案通过哈希槽分片与业务键设计结合，解决了热点数据导致的性能瓶颈，已在多个电商大促场景验证有效性。