redis集群和哨兵机制

1. redis cluster

集群分为主节点和从节点，集群中的每个节点都会向其他节点定期发送ping消息来检测其是否在线，当被检测节点在规定时间内没有做出 pong回应，则标记该节点PFAIL疑似下线。

当所有节点中有半数以上的节点都标记该节点为疑似下线，那么该标记节点被认为是下线FAIL。

当从节点检测到对应主节点下线后，进行故障转移流程。

当前负责处理槽的节点即具有投票权参与投票，如果一个节点收到半数以上的票，选举该节点为新的主节点，然后重新进行主从复制，故障转移完成。

2. redis sentinel

sentinel首先通信和初始化，sentinel系统包括多个sentinel，每个sentinel都会监视一个主服务器和主服务器对应的从服务器。

sentinel会在一定时间内发送info命令到其监视的实例，

如果其监视的主服务器没有进行正确响应且等待时间达到了设置的阈值，那么该sentinel认为该主服务器主观下线，并且通知其他sentinel，

如果认为该主服务器主观下线的sentinel数量超过了设置的阈值，那么认为该主服务器客观下线

先等待 failover-timeout 的控制

然后 sentinel 按照先到先得 会要求其他 Sentinel 投票给它（最先向目标sentinel发送设置要求的源sentinel将会成为 目标sentinel 的局部领头sentinel）

且半数以上的sentinel投票同意 那么选举成为领头sentinel。

且由于配置纪元的限制，最后只会出现一个领头sentinel。

补充说明：failover-timeout

failover-timeout 虽然字面意思是“故障转移超时时间”，但它的作用远不止一个简单的全局倒计时。它更像是* *整个故障转移流程的“操作时限”和“状态冷却器”**，控制着以下几个关键环节：

1. 故障转移执行的“宽限期” 当一个 Sentinel 成为 Leader 并开始执行故障转移时，它必须在这个时间内完成全部操作（如选举新主、切换从库、通知客户端）。如果超时，本次故障转移会被标记为 失败。

2. 故障转移失败的“冷却期” 如果对某个主库的故障转移失败了，Sentinel 不会马上重试。它会等待 2 * failover-timeout 的时间后，才允许再次尝试对该主库进行故障转移。

3. 关键操作步骤的“执行时限” 它也是故障转移中每个关键步骤的“看门狗”：

   • 晋升新主：向选中的从库发送 SLAVEOF NO ONE 命令，若执行耗时超过该值，则判定失败。
   • 信息更新：在新主库上执行 INFO 命令获取状态，若响应超过该值，则判定失败。
   • 从库同步：其他从库与新主库建立复制关系（SLAVEOF），若整个过程超过该值，则判定失败。

4. 投票后的“等待保护” 如果一个 Sentinel 在选举中把票投给了别人（同意让别的 Sentinel 执行故障转移），它会在 failover-timeout 时间内**暂时“闭嘴” **，不再主动发起新的一轮故障转移投票，防止集群脑裂或频繁选举。

另外还有一点需要留心：上面提到的“故障转移失败后的冷却时间”是 2 * failover-timeout，而不是 failover-timeout 。你在分析执行流程或排查问题时要注意到这点。

redis 服务器故障转移

进行服务器的故障转移，每个从服务器都有机会成为主服务器，按照一定条件筛选后按照优先级，复制偏移量和id大小 进行选举成为主服务器，然后重新进行主从复制的重组。

当故障服务器恢复之后成为新主服务器的从服务器，故障转移完成。