Redis分片主要有以下三种典型实现方式，各具特点且适用于不同场景：
一、哈希取模分片
实现原理
对键进行哈希运算（如MD5、CRC16），再将结果对节点数N取模：hash(key) % N，计算结果决定数据存储节点。
操作流程
写入数据时，客户端根据取模结果选择目标节点
读取数据时重复相同计算逻辑定位节点
优点
实现简单，数据分布相对均匀
缺点
扩容成本高：节点数N变化时，需重新计算所有键的映射关系，导致约75%的数据迁移（如3节点扩容至4节点）
热点风险：特定哈希段数据集中可能导致节点负载不均
适用场景
节点数量固定且对数据迁移成本不敏感的小规模场景
二、一致性哈希分片
实现原理
构建2^32大小的虚拟哈希环，将节点哈希值映射到环上
数据存储时，沿环顺时针查找第一个节点作为存储位置
优化措施
虚拟节点：每个物理节点对应多个虚拟节点，缓解数据倾斜问题
优点
动态扩容友好：新增节点仅影响相邻数据段，迁移量降低至约1/N（N为节点数）
缺点
数据倾斜风险：节点分布不均仍可能导致负载不平衡
缓存击穿：扩容后部分数据需重新访问数据库重建缓存
适用场景
客户端分片场景，需平衡扩容效率与数据分布
三、哈希槽分片（Redis Cluster采用）
实现原理
预分配16384个固定槽位，每个节点管理部分槽
数据通过CRC16(key) % 16384计算槽位，由槽位映射表确定存储节点
核心机制
槽位迁移：节点增减时仅需迁移受影响槽位的数据，迁移粒度精细
自动重定向：客户端访问错误节点时，返回MOVED指令引导至正确节点
优点
高效扩容：槽位迁移仅影响局部数据，迁移量远低于哈希取模
负载均衡：支持手动调整槽位分布以解决节点负载不均
客户端透明：集群自动维护槽位映射，客户端无需感知节点变化
缺点
跨槽操作限制：需使用{}哈希标签强制多键同槽（如MSET user:{1000}name “Alice” user:{1000}age 30）
适用场景
大规模分布式集群，需高扩展性与运维便利性
四、方案对比总结
| 维度 | 哈希取模 | 一致性哈希 | 哈希槽 |
|---|---|---|---|
| 扩容成本 | 高（全量迁移） | 中（局部迁移） | 低（槽位迁移） |
| 数据均衡性 | 较好 | 依赖虚拟节点优化 | 最优（可动态调整） |
| 实现复杂度 | 简单 | 中等 | 高（需集群协议支持） |
| 典型应用 | 静态小集群 | 客户端分片 | Redis Cluster |
Redis官方选择哈希槽方案，因其在数据分布、迁移效率与运维复杂度之间实现了最佳平衡。
