1. 分片策略
在 Redis 集群的分片架构中，分片策略决定了数据如何在多节点之间分布，直接影响性能与容量的线性扩展。核心思想是把键空间拆分成若干个等分的小单元，称为哈希槽，然后把这些哈希槽映射到不同的节点上。哈希槽总数为 16384，每个槽独立承载一定范围的键，槽的分配与迁移由集群内的主节点共同维护。理解这一点，是后续实现高可用与动态扩容的基础。
在实际部署中，分片策略需要兼顾冗余与吞吐。若只使用单节点填充，单点故障风险很高；引入副本后，不同哈希槽可以在多台机器上拥有副本，从而提高可用性与读取并发。分片策略还要考虑数据迁移的成本：当扩容或降维时，需要将部分哈希槽从一个节点迁移到另一个节点，这一过程需要保持对外可用性并尽量减少阻塞。下面的要点帮助理解分片策略的实现要素。
# 集群创建时，示例分配 3 台 Master 节点，1 台 Replica
# 假设有三台机器：node1:7000, node2:7001, node3:7002
# 创建集群的常用命令（简化示例）
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 --cluster-replicas 1
在分片策略实现中，基于哈希槽的分组映射机制是核心。集群通过一个全局的哈希槽分布表，记录每个槽属于哪一个主节点，并通过心跳与 Gossip 机制维持槽的分配状态。当需要迁移槽时，集群会触发重新分配，确保目标节点具备足够的处理能力与副本冗余。
分片策略的基本原理
分片的核心原理是将键映射到哈希槽，然后把哈希槽分配给 Master 节点。每个槽的拥有者是一个 Master，若该 Master 出现故障，集群会将该槽的控制权转移到其副本上，从而实现窗体化的容错能力。该过程对客户端透明，客户端通过原有的键请求即可获得响应，只要集群内的槽还存活且可达。
为了避免跨槽查询带来的跨网络成本，有时会使用标签（hash tag）机制让相关的键落在同一个槽内，从而提升某些工作负载（如多键事务、跨键操作）的局部性。但需要注意，跨槽操作在 Redis 集群场景下往往需要通过 Lua 脚本或后端应用层自行实现，以确保原子性与一致性。
常见分片策略对比
常见策略包括基于静态哈希槽分配、以及动态重平衡（reshard）机制。静态分配简单但扩容代价高，动态重平衡则可以在集群在线时重新分配哈希槽，确保各节点负载均衡。动态重平衡需要代价评估，包括迁移过程中的阻塞、网络开销和副本同步情况。下面的示例展示了对哈希槽进行重新分配的场景，帮助理解实际操作中的逻辑。
# 重新分配哈希槽的简化示例（交互式命令，实际执行请参考集群工具）
redis-cli --cluster reshard 127.0.0.1:7000
在实现层面，分片策略还要考虑故障率、带宽和节点容量差异，以确保在高并发场景下稳定响应。通过对槽位的迁移策略进行细粒度控制，可以实现热数据优先落在性能更好的节点，冷数据迁移到容量更大的位置，从而提升整体吞吐能力。
2. 数据路由
数据路由是指客户端如何定位到特定键所在的哈希槽以及对应该槽的主节点。路由决策是高性能数据库集群的核心，直接关系到单次查询的命中率与跨节点请求的成本。 Redis 集群采用分布式哈希槽的方式实现路由：每个节点维护自己的槽映射表，客户端通过 CLUSTER NODES、CLUSTER SLOTS 等命令获取集群拓扑信息，进而把请求路由到目标 Master。
在路由计算中，哈希槽的计算规则是核心算法，理解它可以帮助应用端设计更高效的键命名策略。若键包含标签（例如{user:1001}），则哈希槽的计算仅对标签部分进行聚合，有助于将相关数据放在同一槽内，减少跨节点通信。
路由决策流程
路由流程通常包括：客户端获取集群拓扑信息、根据键名计算哈希槽、定位该槽所属的 Master 节点、向该 Master 发送请求并等待响应。拓扑信息保持动态更新，以应对节点故障、重新分区或新节点加入的情况。若某个槽没有对应 Master，集群会引导客户端通过 MOVED/ASK 重试机制定位到正确的节点。
为了实现更高的吞吐，在设计客户端时可以选择本地缓存集群拓扑信息，并对热点键使用标签来减小跨节点的通信成本。以下代码片段演示了在客户端端实现一个简化的哈希槽定位函数，帮助理解路由的本质。
# 简化的哈希槽定位伪代码（演示用途）
def hash_slot(key):# 如值包含标签{...}，优先对标签计算哈希以提升局部性if '{' in key and '}' in key:start = key.find('{') + 1end = key.find('}', start)key = key[start:end]# 伪代码：计算 CRC16，然后对 16384 取模return crc16(key) % 16384
在实际部署中，CLI 工具与客户端库提供了便捷的路由能力，例如通过 redis-cli 的集群命令获取槽信息、再用 CLUSTER KEYSLOT 命令精确定位某个键所属的槽和节点。下面给出常用查询示例，帮助运维快速定位路由路径。
# 查看集群中某个槽的主节点
redis-cli -p 7000 cluster slots# 获取某个键的哈希槽
redis-cli -p 7000 cluster keyslot mykey{user:1001}
3. 高可用实现
高可用是 Redis 集群设计的核心目标之一。通过主从复制、故障检测以及自动故障转移，集群可以在部分节点不可用时继续提供服务。高可用实现的关键点在于复制配置、故障检测与快速故障转移，以及对写入场景的正确性保障。集群中每个哈希槽至少有一个 Master 与若干 Replica，Replica 负责快速接管，从而避免单点故障导致的中断。
在实际应用中，故障转移通常在以下条件下触发：主节点不可达、心跳超时、以及副本节点具备可用性和最新数据。集群会在确保副本健康的前提下自动提升副本为新主，同时搬移该槽的控制权，使读写可以继续在新的主节点上进行。需要注意的是，故障转移可能带来短暂的数据不一致风险，尤其在副本与主之间存在延迟时，因此需要通过写策略对称性进行约束。
故障转移机制
故障转移在 Redis 集群中并非外部组件介入，而是集群自带的容错逻辑的一部分。当一个主节点长期不可用并被集群视为故障节点，集群会选举其一个健康的副本晋升为新主，其他副本会同步新主的哈希槽映射。此过程对客户端透明，集群通过重定向与槽迁移完成状态自洽。
为了降低故障转移风险，运维通常会设置合理的超时与最小副本数量约束，例如通过 cluster-node-timeout、min-slaves-to-write 等参数，确保在副本数量不足时不会对写操作开放。通过这样的策略，可以在节点失败时维持数据的安全性与可用性之间的平衡。
数据一致性与恢复
高可用并不等同于强一致性。在故障发生时，可能出现短时写入丢失或不同步的情形，这在分布式系统里是常态。为减少风险，集群通过副本冗余和同步机制来提升数据可用性：主节点写入后，复制到副本，随后在故障转移后仍能维持较高的可用性。若主节点在故障后重新回到集群，重新加入时会与当前主节点进行数据同步，确保新旧数据的一致性与完整性。
另外，跨区域或跨机房部署时，推荐设置合理的副本数量和网络延迟监控，以确保复制延迟不过大，从而降低数据不一致的概率。通过对参数的调优和监控，可以实现更稳定的高可用方案。
{"cluster": {"slots": 16384,"replicas_per_master": 1,"min_slaves_to_write": 1,"cluster_node_timeout": 15000}
}