java应用通过redis集群哈希槽机制实现数据分片，核心是“键→槽→节点”三级映射，客户端自动计算crc16哈希并取模确定槽位，支持哈希标签确保关联键同槽，实时同步槽分配元数据，并自动处理moved/ask重定向以适配迁移。
Java 应用通过 Redis 集群的哈希槽机制实现数据分片，核心在于“键 → 槽 → 节点”的三级映射，客户端（如 Jedis 或 Lettuce）自动完成计算与路由，无需手动维护节点列表或分片逻辑。关键不是写算法，而是理解并正确使用这个机制。
哈希槽计算：每个键都必须落到 0–16383 中的某个槽
Redis 集群规定所有键必须通过 CRC16 算法计算哈希值，再对 16384 取模（等价于 crc16(key) & 16383），得到唯一槽位编号。Jedis 内置了该逻辑：
- JedisClusterCRC16 类负责执行
getCRC16(key)并按位与 16383，性能优于普通取模 - 若键含花括号包裹的哈希标签（如
user:{1001}:profile），只对{1001}部分计算，确保同一业务实体的所有键落在同一槽 - 空键或 null 键会直接抛出异常，不可忽略校验
集群元数据同步：客户端需实时掌握“槽→节点”映射关系
Java 客户端首次连接任意节点后，会拉取集群配置（包含 16384 个槽各自归属哪个主节点），并缓存在本地。后续操作直接查表路由：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- JedisCluster 构造时传入节点列表，内部自动执行
CLUSTER SLOTS命令获取槽分配快照 - 当节点故障或槽迁移发生时，客户端收到
MOVED或ASK重定向响应，会刷新本地槽映射表 - 建议启用
refreshPeriod（如 30 秒）定期主动更新，避免因网络抖动导致映射滞后
分片合理性保障：靠槽均匀分配 + 合理使用哈希标签
槽本身是固定编号、静态划分的，但数据是否均匀，取决于键的设计和槽在节点间的分配方式：
- 默认 16384 个槽可被任意拆分，三节点常见分配为 5461+5461+5462，偏差极小
- 避免全量 key 都落在少数几个槽（例如大量用
counter这类无变化前缀的键），否则热点槽拖垮单节点 - 对关联数据强制同槽：用
order:{123}:items和order:{123}:status，保证事务性操作（如 pipeline）能走同节点
扩容与再平衡：Java 侧只需配合运维触发槽迁移
Java 应用本身不参与槽迁移，但需适配迁移过程中的临时状态：
- 运维执行
redis-cli --cluster reshard时，客户端可能收到ASK响应，表示该槽正在迁移中，需先向目标节点发ASKING命令再执行原操作 - Jedis 自动处理
ASK重试，但要注意超时设置不宜过短（建议 ≥ 3s），防止迁移期间频繁失败 - 迁移完成后，客户端下次刷新元数据即自动切流，无需重启应用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
