集群原理
节点通信
通信流程
在分布式存储系统中，维护节点元数据（如节点负责的数据、节点的故障状态等）是关键任务。常见的元数据维护方式分为集中式和P2P方式。Redis集群采用P2P的Gossip协议，这种协议的工作原理是节点之间不断通信交换信息，类似流言传播，最终所有节点都会知道集群的完整信息。
通信流程如下：
- 集群中的每个节点都会单独开辟一个TCP通道用于节点之间通信，通信端口号在基础端口上加10000。
- 每个节点按照固定周期，通过特定规则选择几个节点发送ping消息。
- 接收到ping消息的节点用pong消息作为响应。
每个节点通过一定规则挑选通信的节点，节点可能知道全部或部分其他节点信息。通过ping/pong消息的不断交换，所有节点最终会同步集群的最新状态。这包括故障节点的检测、新节点的加入、主从角色的变化、槽信息的变更等。
Gossip 消息
Gossip协议的主要职责是信息交换，载体是节点彼此发送的Gossip消息。常用的Gossip消息有：ping消息、pong消息、meet消息、fail消息。
- meet消息：用于通知新节点加入。消息发送者通知接收者加入到当前集群，成功后接收节点会加入集群并进行周期性的ping/pong消息交换。
- ping消息：是集群内交换最频繁的消息。每个节点每秒向多个其他节点发送ping消息，用于检测节点是否在线和交换状态信息。ping消息封装了自身和部分其他节点的状态数据。
- pong消息：作为对ping和meet消息的响应。pong消息封装了自身的状态数据，也可以用于广播自身状态更新。
- fail消息：当节点判定另一个节点下线时，向集群内广播fail消息，其他节点接收到后将对应节点更新为下线状态。
所有消息包含消息头和消息体。消息头包含发送节点的状态数据，消息体则根据消息类型（如ping、meet、pong）封装具体数据。
节点选择
Gossip协议需要在信息交换的实时性和成本开销之间取得平衡。Redis集群内节点通信采用固定频率（定时任务每秒执行10次），每次随机选择5个节点发送ping消息，保证信息交换的随机性。节点会优先选择长时间未通信的节点发送ping消息，防止信息过时。
节点每秒发送的ping消息数量为：1 + 10 * num(node.pong_received > cluster_node_timeout / 2)。通过调整cluster_node_timeout参数，可以控制消息发送的频率和带宽占用。
故障转移
Redis集群实现了高可用，当部分节点出现故障时，通过自动故障转移机制保证集群正常服务。
故障发现
故障发现包括主观下线（pfail）和客观下线（fail）：
- 主观下线：某个节点认为另一个节点不可用。这一状态仅代表一个节点的意见，可能存在误判。
- 客观下线：集群内多个节点都认为某节点不可用，达成共识的结果。
主观下线
节点通过ping/pong消息通信。如果在cluster-node-timeout时间内通信失败，发送节点会认为接收节点故障，并标记为主观下线（pfail）。
客观下线
当某个节点判断另一个节点主观下线后，这一状态会通过消息在集群内传播。当超过半数以上持有槽的主节点认为该节点不可用时，触发客观下线流程：
- 统计有效的下线报告数量。如果小于主节点总数的一半则退出。
- 大于主节点数量一半时，标记为客观下线状态。
- 向集群广播fail消息，通知所有节点标记故障节点为客观下线，并触发故障转移。
故障恢复
当主节点变为客观下线后，需要在从节点中选出一个替代。下线主节点的所有从节点都要承担故障恢复的义务。
资格检查
从节点检查最后与主节点断线的时间。如果超过cluster-node-time * cluster-slave-validity-factor，从节点失去故障转移资格。
准备选举时间
符合资格的从节点会根据复制偏移量设置延迟选举时间，优先级高的从节点会提前发起选举。
发起选举
当选举时间到达，从节点发起选举流程：
- 更新配置纪元（配置纪元用于标示当前主节点的版本）。
- 发起选举请求。
选举投票
持有槽的主节点才会处理选举请求，每个配置纪元内只能投票给一个从节点。当从节点收集到超过半数的持有槽主节点投票时，可以执行主节点替换。
替换主节点
从节点收集足够选票后：
- 取消复制，变为主节点。
- 撤销故障主节点负责的槽，并接管这些槽。
- 向集群广播自己的pong消息，通知变为主节点并接管槽信息。
故障转移时间
故障转移时间估算如下：
- 主观下线识别时间=cluster-node-timeout。
- 主观下线状态消息传播时间<=cluster-node-timeout/2。
- 从节点转移时间<=1000毫秒。
总故障转移时间≤cluster-node-timeout + cluster-node-timeout/2 + 1000毫秒。
集群不可用判定
为了保证集群完整性，当16384个槽有任意一个没有指派到节点时，集群不可用。执行键命令时返回错误。这是保护措施，保证所有槽都指派给在线节点。但是在高可用需求下，可以将参数cluster-require-full-coverage配置为no，主节点故障时只影响负责槽的相关命令执行，不会影响其他主节点的可用性。
集群读写分离
- 只读连接：从节点在默认情况下不接受读写请求。需要使用readonly命令打开客户端连接的只读状态，使从节点可以接受读命令。
- 读写分离：实现读写分离需要维护每个主节点的可用从节点列表，客户端需维护请求节点路由，并开启从节点连接的只读状态。读写分离在集群模式下成本较高，一般建议通过扩展主节点数量提高集群性能。
