为什么Redis Cluster需要“无主架构”？
容易忽略的细节
Redis Cluster看似简单，真正落地时却很容易踩坑。传统Redis主从复制模式中，所有写操作都落在主节点，一旦主节点宕机，需要人工或哨兵机制切换从节点。这种架构存在单点瓶颈和脑裂风险。Redis Cluster从诞生之初就采用无主架构（或称去中心化架构），集群中每个节点都平等，没有全局主节点。数据被切分成16384个Hash Slot（哈希槽），每个节点负责一部分槽；节点之间通过Gossip协议互相交换状态信息，一旦某个节点失效，其他节点能自动发现并调整槽的归属。这种设计让Redis Cluster具备了水平扩展、自动故障转移、数据高可用等特性。
进阶阅读：此处可内链到“Redis Cluster性能优化”指南。
Redis Cluster：Hash Slot切片：数据如何被均匀分配？
从CRC16到16384个槽位
当客户端向Redis Cluster写入一个键值对时，集群不会直接把键存到某个节点，而是先对键名做CRC16校验，然后对16384取模，得到一个[0,16383]之间的整数值，这个值就是该键所属的Hash Slot编号。每个节点启动时会声明自己负责哪些Slot范围，比如节点A负责0-5460，节点B负责5461-10922，节点C负责10923-16383。这样，每个键都能通过哈希计算找到归属的Slot，进而找到对应的存储节点。
为什么是16384，而不是65536或更多？因为Gossip协议在节点间传播Slot分配信息时，需要维护一个位图，16384个Slot恰好用2KB（16384/8=2048字节）表示，在集群节点数不多（通常不超过1000）的情况下，这个大小可以节省带宽，同时还能保持较高的粒度。
无主架构下的槽迁移
当集群需要扩容（新增节点）或缩容（移除节点）时，必须重新分配Slot。Redis Cluster提供了reshard命令，管理员可以指定将一定数量的Slot从源节点迁移到目标节点。迁移过程中，源节点和目标节点同时持有该Slot的数据，直到迁移完成。客户端在访问时会收到一个MOVED或ASK重定向错误，从而更新本地缓存的路由表。整个过程不需要停止服务，也无需全局协调，因为每个Slot的归属信息存储在节点本地，并通过Gossip协议公布给整个集群。
Gossip协议：节点间的“八卦”通信
为什么需要Gossip？
在无主架构里，没有中心节点来收集所有节点信息。如果每个节点都直接与所有其他节点建立长连接并定时心跳，节点数为N时就需要维护N*(N-1)/2个连接，当N达到几百时网络开销会非常大。Gossip协议（又称“流行病协议”）解决了这个问题：每个节点定期随机选择几个邻居（通常是被动选择的，由种子节点或集群列表提供），交换自己所知道的其他节点的状态。信息像病毒传播一样，经过几轮交换后，整个集群的所有节点都能获得一致的状态视图。
Gossip消息的类型
Redis Cluster中，节点之间通过CLUSTER MEET指令加入集群后，会保持TCP长连接。Gossip消息包含PING、PONG、MEET、FAIL等类型。PING包用于主动探测邻居是否存活，同时附带本节点所知道的全部或部分节点信息（一个gossip table）。接收方收到PING后，返回PONG，同样附上自己的信息。如果一个节点连续超过node-timeout时间（默认15秒）没有收到某个节点的PONG回复，就会将该节点标记为疑似下线（PFAIL）。如果集群中超过半数的持有相同Slot的节点（即该主节点对应的从节点或仲裁节点）都认为该节点PFAIL，则状态升级为FAIL，并向整个集群广播FAIL消息。
Gossip的收敛性与容量限制
单次PING/PONG消息中最多携带10%的节点信息（可通过cluster-node-timeout间接调整），这样可以控制单次消息大小。但这也意味着信息传播会有一定延迟：一个节点宕机后，其他节点可能需要几轮Gossip才能全部获知。实际测试中，在100个节点以内，通常几秒内就能完成收敛。这种设计优先保证了网络负载的可控性，即使集群规模扩大，Gossip消息也不会指数级增长。
想继续深入：此处可内链到“Redis Cluster优化清单”文章。
节点故障诊断：从PFAIL到FAIL
故障检测的触发条件
节点A每cluster-node-timeout内都会向随机选择的节点B发送PING消息，如果超过cluster-node-timeout（默认15秒）没有收到B的PONG回复，A就会把B标记为PFAIL（possible failure）。但注意，PFAIL只是本地视图，不会直接触发故障转移。接下来的关键步骤是收集“足够多”的其他节点的评价。
故障确认：仲裁机制
当一个主节点B被部分节点标记为PFAIL后，这些节点会通过Gossip协议将这个嫌疑散布出去。集群中所有持有相同Slot副本（即B的从节点）的节点会各自判断：如果它们中也检测到B无响应，并且超过一半的主节点（即拥有B所在Slot的副本的节点）也认为B是PFAIL，则B的状态会被提升为FAIL。对于每个Slot来说，谁是这个“仲裁者”？实际上，每个主节点都可以作为仲裁者，但只有那些与B的Slot有复制关系（即B的主从节点）的节点参与投票。投票成功意味着整个集群确认B已经下线。
自动故障转移：从节点提拔为主节点
一旦主节点B被标记为FAIL，B的所有从节点中就会触发选举。每个从节点会计算自己的“优先级”（主从复制延迟越小，优先级越高），然后向集群中其他主节点发起投票请求。当某个从节点获得超过半数主节点的投票时，它就会将自己升级为新的主节点，并接管B原来负责的所有Slot。这个过程通常在几秒内完成，客户端可以通过CLUSTER NODES查看最新的角色变化。
诊断中的常见误区
初学者容易混淆“PFAIL”和“FAIL”。PFAIL只表示某个节点自己认为对方可能挂了，但无法排除网络抖动的可能。FAIL则是集群的共识结论，才是触发故障转移的条件。另外，如果集群中有超过一半的主节点同时宕机，Gossip协议无法达成多数派共识，集群会进入只读状态或无法选举，这就是为什么要保证集群中有至少三个主节点（奇数个更佳）的原因。
延伸阅读：此处可内链到“Redis Cluster配置案例”相关文章。
关联教程：此处可内链到“Redis Cluster部署与验证”内容。
补充参考：此处可内链到“Redis Cluster故障排查实例”。
总结与最佳实践
配置前的检查
Redis Cluster的无主架构通过Hash Slot实现了数据的自动分片与迁移，利用Gossip协议以极低的网络开销完成了节点间状态同步和故障诊断。对于运维人员来说，理解这些原理有助于正确设置cluster-node-timeout、cluster-replica-validity-factor等参数，避免因网络波动导致误切片或慢收敛。生产环境中建议监控cluster_state、cluster_slots_assigned等指标，结合Gossip协议的超时日志，快速定位节点异常。
掌握这些底层机制后，你再遇到Redis Cluster的启动失败、分片不均、节点间通信超时等问题时，就能从根源上分析，而不再盲目重启。这正是从“会用Redis Cluster”到“懂Redis Cluster”的关键一步。
延伸阅读