1 哨兵模式能做什么？

在上一篇文章中介绍的redis主从复制(http://blog.csdn.net/hylexus/article/details/69360701)虽然可以达到主从复制的目的。

但是并没有考虑高可用，也就是说：当主机宕机后，备机不能及时自动顶替主机，这当然不行的。

这里介绍的redis的哨兵模式能够在后台监控主机是否发生故障，如果发生故障了，可以及时根据投票数自动将从库转换为主库。从而在一定意义上达到高可用。

2 哨兵模式相关的知识点

2.1 哨兵提供的功能

监控(monitoring)
- 定期检查监控的master和slave的状态
通知(notification)
- 当检测到故障时可以发送通知
自动故障转移(auto-failover)
- 检测到master不能工作时,可以将master的下属slave中的一个升级为master
- 客户端连接已经不可用的master时,想客户端返回新的master地址
自动发现其他sentinel和从服务器
- Sentinel 可以通过发布与订阅功能来自动发现正在监视相同主服务器的其他 Sentinel
- Sentinel 可以通过询问主服务器来获得所有从服务器的信息
sentinel配置自动持久化
- 当 Sentinel 接收到一个新的配置，或者当领头 Sentinel 为主服务器创建一个新的配置时，这个配置会与配置纪元一起被保存到磁盘里面
- 停止和重启 Sentinel 进程都是安全的

2.2 主观下线和客观下线

sentinel会定时向其所监控的服务器发送ping命令以询问服务器是否还正常地活着.

如果服务器的回应是有效回复,则认为该服务器还正常地活着.有效回复有以下三类:

返回+PONG
返回-LOADING
返回-MASTERDOWN

换言之:如果服务器的回应不是以上三种之一，或者在指定的时间内没有回复，都将被认为是无效的回复.

另外需要注意的是：

如果 master-down-after-milliseconds 选项的值为 60000 ms（60 s），那么即使服务器在第59 s时返回至少一次有效回复，这个服务器就仍然会被认为是处于正常状态的。

主观下线和客观下线

主观下线(Subjectively Down==sdown)：单个 Sentinel 实例对服务器做出的下线判断
客观下线(Objectively Down==odown)：多个 Sentinel 实例都对某服务器得出sdown的判断

2.3 哨兵配置文件

配置文件中的选项

down-after-milliseconds : 多少毫秒内得不到服务器的回应时sentinel可以认为该服务器已经下线
parallel-syncs : 在完成故障转移时最多可以有几个slave从新的master同步数据
myid ：sentinel自身的ID,和zookeeper集群中的myid类似
port ：指定sentinel的端口(默认是redis示例端口前加个2比如26379)

一点说明

其实你可以指定一个最小化的配置,其他的配置项redis会帮你生成。

比如，你可以只指定sentinel monitor <name> <host> <port> <count>.其他项都会自动生成.

当然，你最好将保护模式关闭。

配置文件示例

# 哨兵自己的id,和zookeeper中的myid类似
sentinel myid 37a94ac96520c311ca2976d56e716e3bbb4e9111
# 关闭保护模式(和redis.conf中的配置类似)
protected-mode no
# 监控名为master-test的集群
sentinel monitor master-test 192.168.1.131 6379 2
# 多少毫秒内sentinel可以认为他监控的对象已经断线
sentinel down-after-milliseconds master-test 10000
# 故障转移的超时时间
sentinel failover-timeout master-test 10000

2.4 故障转移过程

检测到master已经进入sdown(客观下线)状态
对当前纪元进行自增，并尝试成为leader-sentinel
- 没能成为leader-sentinel
  - 在设定的failover-timeout的两倍之后，重新尝试
- 成功成为leader-sentinel
  - 选出一个slave，并升级为master
  - 通过发布与订阅功能，将更新后的配置传播给所有其他 Sentinel ，其他 Sentinel 对它们自己的配置进行更新
  - 向已下线主服务器的从服务器发送 SLAVEOF 命令，让它们去复制新的主服务器
  - 当所有从服务器都已经开始复制新的主服务器时, leader-sentinel 终止这次故障转移操作

3 配置示例

3.1 说明

sentinel-preview

为方便操作此处用主机名代替IP操作
整个结构还是上一篇文章中的一主二从
三个redis分别位于三台主机上

3.2 配置

哨兵配置文件(三台主机是一致的)

sentinel monitor master-test h1 6379 2
protected-mode no
# 以下两项不是必须的(此处只是为了较快的看到变化才缩短了时间配置)
sentinel down-after-milliseconds master-test 10000
sentinel failover-timeout master-test 10000

3.3 启动

启动redis实例

# 启动master
[root@h1 redis]$ redis-server redis.conf 
# 启动slave h1
[root@h2 redis]$ redis-server redis.conf --slaveof h1 6379
# 启动slave h2
[root@h3 redis]$ redis-server redis.conf --slaveof h1 6379

启动sentinel实例(三台机器一样的命令)

1	[root@h1 redis]$ redis-sentinel sentinel.conf

此时可以看看redis自动生成的哨兵配置文件内容:

[root@h1 redis]$ cat sentinel.conf
port 26379
sentinel myid 37a94ac96520c311ca2976d56e716e3bbb4e9111
protected-mode no
# Generated by CONFIG REWRITE
dir "/data/redis"
sentinel monitor master-test 192.168.1.131 6379 2
sentinel down-after-milliseconds master-test 10000
sentinel failover-timeout master-test 10000
sentinel config-epoch master-test 4
sentinel leader-epoch master-test 4
sentinel known-slave master-test 192.168.1.132 6379
sentinel known-slave master-test 192.168.1.133 6379
sentinel known-sentinel master-test 192.168.1.132 26379 ac72dd0def3cf1ee47bab9dba9d4454693a2c222
sentinel known-sentinel master-test 192.168.1.133 26379 3dcc2ef2b3aff48d61afb0ae041ce08e59e4b333
sentinel current-epoch 4

sentinel的日志输出

# 当前sentinel的ID
Sentinel ID is 37a94ac96520c311ca2976d56e716e3bbb4e9111
# 当前监控的master
+monitor master master-test 192.168.1.133 6379 quorum 2
# 检测到了其他的sentinel
+sentinel sentinel ac72dd0def3cf1ee47bab9dba9d4454693a2c222 192.168.1.132 26379 @ master-test 192.168.1.133 6379
# 检测到了其他的sentinel
+sentinel sentinel 3dcc2ef2b3aff48d61afb0ae041ce08e59e4b333 192.168.1.133 26379 @ master-test 192.168.1.133 6379
# 检测到的master的下属slave
+slave slave 192.168.1.132:6379 192.168.1.132 6379 @ master-test 192.168.1.131 6379
+slave slave 192.168.1.133:6379 192.168.1.133 6379 @ master-test 192.168.1.131 6379

3.4 测试

手动停止主机h1

1	[root@h1 redis]$ redis-cli shutdown

此时看看h1上哨兵的日志输出：

# h1主观下线
+sdown master master-test 192.168.1.131 6379
# h1客观下线
+odown master master-test 192.168.1.131 6379 #quorum 3/2
# 开始尝试故障转移
+try-failover master master-test 192.168.1.131 6379
………………
# 最终将h2选为新的master
+switch-master master-test 192.168.1.131 6379 192.168.1.132 6379

再次启动h1

1	[root@h1 redis]$ redis-server redis.conf

此时可以看到类似如下输出:

# h1的主观下线状态被取消
-sdown slave 192.168.1.131:6379 192.168.1.131 6379 @ master-test 192.168.1.132 6379
# 原来的master(h1)回来后被转成了当前master(h2)的slave
+convert-to-slave slave 192.168.1.131:6379 192.168.1.131 6379 @ master-test 192.168.1.132 6379

同时还有一点更牛逼的是：

# 此时查看h1上redis的配置文件中关于slave的配置已经被自动修改了
[root@h1 redis]$ cat redis.conf | grep slaveof
# Master-Slave replication. Use slaveof to make a Redis instance a copy of
# slaveof <masterip> <masterport>
# slaveof h1 6379
slaveof 192.168.1.132 6379 # *****这个是自动修改过的****
[root@h1 redis]$  
# h3的配置文件也被修改过了
[root@h3 redis]$ cat redis.conf | grep slaveof
# Master-Slave replication. Use slaveof to make a Redis instance a copy of
# slaveof <masterip> <masterport>
slaveof 192.168.1.132 6379
[root@h3 redis]$

3.5 sentinel日志输出

以下内容来自:http://www.redis.cn/topics/sentinel.html

+reset-master ：主服务器已被重置
+slave ：一个新的从服务器已经被 Sentinel 识别并关联。
+failover-state-reconf-slaves ：故障转移状态切换到了 reconf-slaves 状态。
+failover-state-select-slave ：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
failover-state-send-slaveof-noone ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
failover-end-for-timeout ：故障转移因为超时而中止
failover-end ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了
no-good-slave ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
+sentinel ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。
+sdown ：给定的实例现在处于主观下线状态。
-sdown ：给定的实例已经不再处于主观下线状态。
+odown ：给定的实例现在处于客观下线状态。
-odown ：给定的实例已经不再处于客观下线状态。

总结

主从复制+哨兵可以解决高可用和部分高性能。

之所以说是部分高性能是因为主从复制可以提供读的性能，但是写操作依然是单点master负责。

后续的有关redis集群的文章将介绍这方面的内容。

参考资料

http://www.redis.cn/topics/sentinel.html
https://redis.io/documentation
尚硅谷思维导图

redis-09-哨兵模式