Redis Sentinel 哨兵模式

Redis Sentinel 哨兵模式

1.网络架构

网络结构以下，经过Sentinel监控Master和Slave服务器：

2.配置启动

配置文件以下：

vi /etc/redis-sentinel.conf

port 26379     
dir "/tmp"
logfile "/var/log/redis/sentinel_20086.log"

# 进程守护
daemonize yes

# 格式：sentinel <option_name> <master_name> <option_value>
# 最后的一个2表明在sentinel集群中，多少个节点认为master死了，才能真正认为该master不可用
sentinel monitor T1 127.0.0.1 6379 2  

# sentinel会向master发送心跳确认存活
# 若是master在“必定时间范围”内不回应PONG 或者是回复了一个错误消息
# 那么这个sentinel会主观地认为这个master已经不可用了
# (subjectively down, 也简称为SDOWN)。
# down-after-milliseconds 用来指定这个“必定时间范围”，单位是毫秒，默认30秒。
sentinel down-after-milliseconds T1 15000

# failover过时时间。
# 当failover开始后，在此时间内仍然没有触发任何failover操做，当前sentinel将会认为这次failoer失败。
# 默认180秒，即3分钟。
sentinel failover-timeout T1 120000

# 在发生failover时，这个选项指定了最多能够有多少个slave同时对新的master进行同步。
# 这个数字越小，完成failover所需的时间就越长；
# 这个数字越大，就意味着越多的slave由于replication而不可用。
# 能够经过将这个值设为 1 来保证每次只有一个slave处于不能处理命令请求的状态。
sentinel parallel-syncs T1 1

# sentinel 链接密码验证
# sentinel auth-pass <master_name> xxxxx

# 发生切换以后执行的一个自定义脚本
# sentinel notification-script <master-name> <script-path>
# sentinel client-reconfig-script <master-name> <script-path>

Sentinel 也须要集群化，以确保：

1. 某个/些 Sentinel节点挂了，仍然能够实现Redis主从切换；
2. Redis客户端能够经过任意一个Sentinel读取/写入信息。

启动Sentinel：

redis-sentinel /path/to/sentinel.conf

启动后，经过Sentinel的自动识别，配置文件中会自动加上已识别的Redis集群节点和Sentinel集群节点。

3.实现流程

1. Sentinel集群经过配置文件发现master，启动时会监控master；
2. 向master发送info命令，获取其全部slave节点；
3. Sentinel集群向Redis主从服务器发送hello信息（心跳），包括Sentinel自己的ip、端口、id等内容，以此来向其余Sentinel宣告本身的存在；
4. Sentinel集群经过订阅接收其余Sentinel发送的hello信息，以此来发现监视同一个主服务器的其余Sentinel；集群之间会互相建立命令链接用于通讯，由于已经有主从服务器做为发送和接收hello信息的中介，Sentinel之间不会建立订阅链接；
5. Sentinel集群使用ping命令来检测实例的状态，若是在指定的时间内（down-after-milliseconds）没有回复或则返回错误的回复，那么该实例被判为下线；
6. 当failover主备切换被触发后，并不会立刻进行，还须要Sentinel中的大多数sentinel受权后才能够进行failover，即进行failover的Sentinel会去得到指定quorum个的Sentinel的受权，成功后进入ODOWN状态。如在5个Sentinel中配置了2个quorum，等到2个Sentinel认为master死了就执行failover。
7. Sentinel向选为master的slave发送 SLAVEOF NO ONE 命令，选择slave的条件是Sentinel首先会根据slaves的优先级来进行排序，优先级越小排名越靠前。若是优先级相同，则查看复制的下标，哪一个从master接收的复制数据多，哪一个就靠前。若是优先级和下标都相同，就选择进程ID较小的。
8. Sentinel被受权后，它将会得到宕掉的master的一份最新配置版本号(config-epoch)，当failover执行结束之后，这个版本号将会被用于最新的配置，经过广播形式通知其它sentinel，其它的sentinel则更新对应master的配置。

注意：
由于redis采用的是异步复制，没有办法避免数据的丢失。
能够在redis.conf经过如下配置来使得数据不会丢失：

// master最少得有多少个健康的slave存活才能执行写命令 
min-slaves-to-write 1
// 延迟小于min-slaves-max-lag秒的slave才认为是健康的slave
min-slaves-max-lag 10

当全部Slave都不符合条件时，master将中止写入。

4.故障转移

发生故障转移时，须要进行领导者选举。

• sentinel首先会根据slaves的优先级来进行排序，优先级越小排名越靠前；
• 若是优先级相同，则查看复制的下标，哪一个从master接收的复制数据多，哪一个就靠前；
• 若是优先级和下标都相同，就选择RunID较小的那个；

若是一个redis的slave优先级配置为0，那么它将永远不会被选为master。

故障转移过程

领导者Sentinel须要将一个salve提高为master，此slave必须为状态良好，不能处于SDOWN/ODOWN状态。

1. “+failover-triggered”: Leader开始进行failover，此后紧跟着“+failover-state-wait-start”，wait数秒。
2. “+failover-state-select-slave”: Leader开始查找合适的slave
3. “+selected-slave”: 已经找到合适的slave
4. “+failover-state-sen-slaveof-noone”: Leader向slave发送“slaveof no one”指令，此时slave已经完成角色转换，此slave即为master
5. “+failover-state-wait-promotition”: 等待其余sentinel确认slave
6. “+promoted-slave”：确认成功
7. “+failover-state-reconf-slaves”: 开始对slaves进行reconfig操做
8. “+slave-reconf-sent”:向指定的slave发送“slaveof”指令，告知此slave跟随新的master
9. “+slave-reconf-inprog”: 此slave正在执行slaveof + SYNC过程，如过slave收到“+slave-reconf-sent”以后将会执行slaveof操做。
10. “+slave-reconf-done”: 此slave同步完成，此后leader能够继续下一个slave的reconfig操做。循环 step 7
11. “+failover-end”: 故障转移结束
12. “+switch-master”：故障转移成功后，各个sentinel实例开始监控新的master。

5.增长和删除节点

Sentinel会经过PUB/SUB自动识别新增节点。

删除流程：

1. 中止所要删除的sentinel
2. 发送一个SENTINEL RESET 命令给全部其它的sentinel实例，若是你想要重置指定master上面的sentinel，只须要把号改成特定的名字，注意，须要一个接一个发，每次发送的间隔不低于30秒（down-after-milliseconds）；
3. 检查一下全部的sentinels是否都有一致的当前sentinel数；

---

参考资料：
https://www.cnblogs.com/zhouj...
http://www.cnblogs.com/zhouji...
https://segmentfault.com/u/be...