4. 缓存路由实现：基于Redis Cluster的slot路由机制与客户端分片策略

在分布式缓存体系中，路由决定了数据请求如何被分发到正确的存储节点。Redis Cluster 采用基于 CRC16 哈希槽（slot） 的自动分片机制，而客户端分片策略则提供了更灵活的数据分布控制。本章深入剖析这两种路由模式的核心原理、实现差异与一致性保障。

4.1 Redis Cluster Slot 路由机制

Redis Cluster 将整个键空间划分为 16384 个哈希槽（slot 0 ~ 16383），每个主节点负责管理一段连续的 slot 区间。键与 slot 的映射关系由以下公式决定：

slot = CRC16(key) % 16384

当客户端发送请求时，集群节点根据目标 slot 判断是否由自己处理；若不是，则返回 MOVED 重定向错误，指引客户端连接正确的节点。

4.1.1 槽位分配与重定向流程

1. 客户端计算 slot：对 key 执行 CRC16 取模，得到目标 slot 编号。
2. 本地路由表查询：客户端缓存集群的 slot → node 映射表，直接定位目标节点。
3. 请求发送：若本地路由命中，直接发送命令；若未命中或节点迁移，收到 MOVED 或 ASK 错误。
4. 路由表更新：客户端解析重定向响应，更新本地缓存，后续请求直接发往新节点。

4.1.2 Slot 路由的哈希标签（Hash Tag）

当需要将多个 key 强制路由到同一 slot 时，可使用 哈希标签：key 中 {...} 包裹的部分参与 CRC16 计算，其余部分忽略。

user:{1001}:profile   → 仅 "1001" 参与哈希
user:{1001}:orders    → 与上例落入同一 slot

哈希标签适用于事务、Lua 脚本等需要多 key 原子操作的场景，但需谨慎使用，避免造成 slot 数据倾斜。

4.2 客户端分片策略

客户端分片（Client-Side Sharding）将数据分布逻辑完全放在应用层或客户端库中，不依赖 Redis Cluster 的自动路由。常见策略包括：

4.2.1 一致性哈希与虚拟节点

一致性哈希将节点和 key 映射到同一个哈希环上，key 沿环顺时针找到最近的节点。为解决数据倾斜，引入 虚拟节点：每个物理节点对应多个虚拟节点，均匀分布在环上。

// 虚拟节点映射示例（伪代码）
for (int i = 0; i < virtualNodeCount; i++) {
    String virtualKey = nodeId + ":" + i;
    int hash = hash(virtualKey);
    ring.put(hash, nodeId);
}

4.3 Slot 路由 vs 客户端分片：对比与选型

4.4 路由一致性保障

无论采用哪种路由方式，一致性 是缓存系统的生命线。以下措施确保路由决策不导致数据错乱：

• 原子路由表更新：客户端在收到 MOVED 后，使用 CAS（Compare-And-Swap）或锁机制更新本地路由缓存，避免并发写覆盖。
• 版本号校验：集群元数据携带 epoch 版本号，客户端仅接受版本号递增的路由更新，防止旧数据污染。
• 重试与幂等：路由重定向后，客户端应自动重试请求，且操作本身需具备幂等性（如 SET 覆盖写）。
• 读写分离路由：读请求可路由到从节点，但需确保从节点数据延迟在可接受范围内，避免读到过期数据。

4.5 路由调优实战要点

• 预计算 slot 分布：在客户端启动时，主动向集群发送 CLUSTER SLOTS 命令获取完整路由表，避免首次请求触发大量重定向。
• 连接池与路由绑定：每个 slot 对应一个连接池，避免不同 slot 的请求共享连接导致头部阻塞。
• 监控路由重定向率：通过 INFO 命令或客户端指标监控 MOVED 和 ASK 比例，异常升高可能预示集群分裂或网络分区。
• 客户端分片的热点应对：对高频 key 添加随机后缀或使用虚拟节点打散，防止单节点过载。