Redis sentinel(哨兵)集群原理

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis-Sentinel在发现master宕机后会进行自动切换主从关系。

sentinel的作用

集群监控：sentinel节点会定期检查redis状态，判断是否故障

故障自动切换:在master发生故障时，实现slave晋升成master，并维护后续正确的主从关系

提供配置:sentinel会将故障转移的结果通知给客户端，提供最新的master地址

监控

定时监控 Redis 数据节点

每 10 秒每个 sentinel 向 master、slaves 节点发送 INFO 命令

每 2 秒每个 sentinel 通过 master 节点的 channel(名称为 __sentinel__:hello) 交换信息(pub/sub)，信息包括：

每 1 秒每个 sentinel 对其他 sentinel 和 redis master, slave 发送 PING 命令,用于心跳检测,作为节点存活的判断依据

主观下线和客观下线（发现故障）

主观下线（subjectively down，SDOWN）：当前 Sentinel 实例认为某个 redis 服务为”不可用”状态。Sentinel 向 redis master 数据节点发送消息后 30s（down-after-milliseconds） 内没有收到有效回复（+PONG、-LOADING 或者 -MASTERDOWN），Sentinel 会将 master 标记为下线（打开 master 结构中 flags 的 SRI_S_DOWN 标记）

客观下线（objectively down，ODOWN）：多个 Sentinel 实例都认为 master 处于 SDOWN 状态，那么此时 master 将处于 ODOWN， ODOWN可以简单理解为master已经被集群确定为”不可用”,将会开启故障转移机制。向其他 sentinel 节点发送 sentinel is-master-down-by-addr 消息询问数据节点情况，得知达到 quorum 数量的 sentinel 节点认为数据节点已经下线

故障切换过程

发现故障(客观下线) --> sentinel选举  --> 选择合适的slave成为master --> 故障转移

Sentinel leader选举

在确定客观下线后，开始进行leader选举

每个在线的 sentinel 节点都有资格成为 leader。 当确认主节点客观下线时候会向其他 sentinel 节点发送sentinel is-master-down-by-addr命令,要求将自己设置为leader。

每个 sentinel 节点都只能投出一票,当节点得票数超过max(quorum,sentinels/2 +1)，则被选举成leader.

正常情况下哪个 sentinel 节点最先确认 master 客观下线哪个 sentinel 节点就会成为执行故障转移的 leader

选择合适的slave成为master

健康的节点：在线的,最近成功通信过的（5s 内回复过 PING 命令）

数据比较新的（与 master 失联时间不超过 10*down-after-milliseconds）

slave-priority（slave节点优先级）最高的slave节点

复制偏移量最大的 slave 节点（复制的最完整）

选择 runId 最小的 slave 节点（启动最早的节点）

故障转移

1.在合适的slave节点上执行 SLAVEOF no one命令让其成为新的 master 节点。

2.向剩余的 slave 节点发送 SLAVEOF 新master 命令，让他们成为新 master 节点的 slave 节点

3.让剩余的 slave 复制新 master 的数据，通过配置 sentinel parallel-syncs 规定了每次向新的主节点发起复制操作的从节点个数。

4.更新原来master 节点配置为 slave 节点,并保持对其进行关注,一旦这个节点重新恢复正常后,会命令它去复制新的master节点信息

全部故障转移工作完成后，Leader Sentinel 就会推送 +switch-master 消息，同时重置 master，重置操作会释放掉原来 master 全部的 slave 对象和监听该 master 的其他 Sentinel 对象，然后创建出新的 slave 对象
 

主要配置说明

bind 192.168.56.111
port 26379
daemonize yes
dir /home/redis/redis_26379
logfile sentinel.log

#指定监听的集群名,主节点IP,Port,客观下线最低票数
sentinel monitor mymaster 10.10.11.146 6388 2

# 主节点的密码配置
sentinel auth-pass mymaster 123456

# 判定节点不可达的时间，单位是毫秒
sentinel down-after-milliseconds mymaster 5000

# 故障转移后，每次向新的主节点发起复制的从节点的个数,建议设置为1，不要并发
sentinel parallel-syncs mymaster 1

# 故障转移的超时时间
sentinel failover-timeout mymaster 50000  

常见问题

异步复制导致的数据丢失：可能有部分数据还没复制到slave,master就宕机了此时这部分数据就丢失了。

redis 服务脑裂导致的数据丢失:某个 master 所在机器突然网络故障跟其他 slave 机器不能连接但是实际上 master 还运行着。此时哨兵可能就会认为 master 宕机了然后开启选举将其他 slave 切换成了master.
这个时候集群里就会有两个master也就是所谓的脑裂。此时虽然某个 slave 被切换成了 master,但是 client 还没来得及切换到新的master,还继续写向旧 master 的数据就丢失了。因为旧 master 再次恢复的时候会被作为一个 slave 挂到新的 master 上去,自己的数据会清空重新从新的 master 复制数据。

这两个参数可以尽量保证数据不丢失：min-slaves-to-write 1        ； min-slaves-max-lag 10