微信公众号：51码农网
网站:www.51manong.com
51码农网，让程序员的坚持学习变得可能
Redis哨兵（Sentinel）模式
Redis的主从复制,当主机出现了宕机时，需要人工手动去干预，把一台从服务器切换为主服务器，或者手动去重启主机，费时费力，而且还会导致该时间段内的服务不可用，这就要说说Redis的哨兵模式。
哨兵自然就是站岗放哨，负责监控。Redis的哨兵系统执行3个任务
1.监控,Redis的哨兵会不断检查主服务器和从服务器的运行状况
2.提醒,当哨兵检查到某个Redis服务器出现了问题，哨兵可以通过API向运维或者其他程序发送通知
3.自动故障迁移（Automatic failover）, 当一个主服务器不能正常工作时， 哨兵会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器
哨兵模式的配置文件sentinel.conf
运行一个 Sentinel 所需的最少配置如下所示：
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5
第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 1 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。
down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。
不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。
parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长
哨兵模式演示
1.将Redis源码下的sentinel文件复制到Redis的安装目录
[erayt@ERAYT-01 redis-3.0.0]$ cp sentinel.conf /usr/local/redis/bin/
顺便说一下,Redis Sentinel 兼容 Redis 2.4.16 或以上版本， 推荐使用 Redis 2.8.0 或以上的版本。
2.配置sentinel
sentinel monitor mymaster 127.0.0.1 6379 1
3.启动哨兵
[erayt@ERAYT-01 bin]$ ./redis-sentinel sentinel.conf
查看窗口日志
3146:X 20 Jul 05:41:40.158 # Sentinel runid is 2fd81c3ed629769930e5b4511470e95b0a429a4b
3146:X 20 Jul 05:41:40.158 # +monitor master mymaster 127.0.0.1 6379 quorum 2
3146:X 20 Jul 05:41:41.169 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
3146:X 20 Jul 05:41:41.169 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
4.关闭Redis的主节点6379
[erayt@ERAYT-01 bin]$ ./redis-cli shutdown
查看窗口日志
3260:X 20 Jul 05:55:33.661 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
3260:X 20 Jul 05:55:33.674 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
3260:X 20 Jul 05:55:33.696 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
3260:X 20 Jul 05:56:03.710 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
6380这个节点应该成为了新的主服务器
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=570,lag=0
master_repl_offset:570
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:569
故障转移的步骤
发现主服务器已经进入客观下线状态。
对我们的当前纪元进行自增， 并尝试在这个纪元中当选。
如果当选失败， 那么在设定的故障迁移超时时间的两倍之后， 重新尝试当选。
如果当选成功， 那么执行以下步骤。
1.选出一个从服务器，并将它升级为主服务器。
2.向被选中的从服务器发送 SLAVEOF NO ONE 命令，让它转变为主服务器。
3.通过发布与订阅功能， 将更新后的配置传播给所有其他 Sentinel ， 其他 Sentinel 对它们自己的配置进行更新。
4.向已下线主服务器的从服务器发送 SLAVEOF host port 命令， 让它们去复制新的主服务器。
5.当所有从服务器都已经开始复制新的主服务器时， 领头 Sentinel 终止这次故障迁移操作。
