Redis 哨兵
作用
Redis Sentinel，即Redis哨兵，在Redis 2.8版本开始引入。
主要提供了配置提供者，通知，哨兵的监控和自动故障转移功能。哨兵的核心功能是主节点的自动故障转移。
下面是Redis官方文档对于哨兵功能的描述：
- 监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
- 自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
- 配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
- 通知（Notification）：哨兵可以将故障转移的结果发送给客户端。
其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。
架构
它由两部分组成，哨兵节点和数据节点：
- 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。
- 数据节点：主节点和从节点都是数据节点。
部署
部署主从节点
哨兵系统中的主从节点，与普通的主从节点配置是一样的，并不需要做任何额外配置。
#redis-6379.conf port 6379 daemonize yes logfile "6379.log" dbfilename "dump-6379.rdb" #redis-6380.conf port 6380 daemonize yes logfile "6380.log" dbfilename "dump-6380.rdb" slaveof 192.168.92.128 6379 #redis-6381.conf port 6381 daemonize yes logfile "6381.log" dbfilename "dump-6381.rdb" slaveof 192.168.92.128 6379
配置完成后，依次启动主节点和从节点：
redis-server redis-6379.conf redis-server redis-6380.conf redis-server redis-6381.conf
部署哨兵节点
哨兵节点本质上是特殊的Redis节点。
3个哨兵节点的配置几乎是完全一样的，主要区别在于端口号的不同（26379/26380/26381）。
#sentinel-26379.conf port 26379 daemonize yes logfile "26379.log" sentinel monitor mymaster 192.168.92.128 6379 2
sentinel monitor mymaster 192.168.92.128 6379 2 配置的含义是：该哨兵节点监控192.168.92.128:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。
哨兵节点的启动有两种方式，二者作用是完全相同的：
redis-sentinel sentinel-26379.conf redis-server sentinel-26379.conf --sentinel
此时如果查看哨兵节点的配置文件，会发现一些变化：
dir只是显式声明了数据和日志所在的目录（在哨兵语境下只有日志）；
known-slave和known-sentinel显示哨兵已经发现了从节点和其他哨兵；
带有epoch的参数与配置纪元有关（配置纪元是一个从0开始的计数器，每进行一次领导者哨兵选举，都会+1；领导者哨兵选举是故障转移阶段的一个操作）。
故障转移
- 使用kill命令杀掉主节点 6379
- 如果此时立即在哨兵节点中使用info sentinel命令查看，会发现主节点还没有切换过来，因为哨兵发现主节点故障并转移，需要一段时间。
- 一段时间以后，再次在哨兵节点中执行info Sentinel查看，发现主节点已经切换成6380节点。
- 同时可以发现，哨兵节点认为新的主节点仍然有2个从节点，这是因为哨兵在将6380切换成主节点的同时将6379节点置为其从节点；
- 重启6379节点：可以看到6379节点成为了6380节点的从节点。
- 在故障转移阶段，哨兵和主从节点的配置文件都会被改写。
PS:
4 > 虽然6379从节点已经挂掉，但是由于哨兵并不会对从节点进行客观下线（其含义将在原理部分介绍），因此认为该从节点一直存在。当6379节点重新启动后，会自动变成6380节点的从节点。
6 > 对于主从节点，主要是slaveof配置的变化：新的主节点没有了slaveof配置，其从节点则slaveof新的主节点。
6 > 对于哨兵节点，除了主从节点信息的变化，纪元(epoch)也会变化，可以看到纪元相关的参数都+1了。
总结
哨兵系统的搭建过程，有几点需要注意：
- 哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。
- 哨兵节点本质上是redis节点。
- 每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。
- 在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。
- 一个哨兵只监控了一个主节点；实际上，一个哨兵可以监控多个主节点，通过配置多条sentinel monitor即可实现。
配置提供者和通知
通过客户端原理的介绍，可以加深对哨兵功能的理解：
（1）配置提供者：客户端可以通过哨兵节点+masterName获取主节点信息，在这里哨兵起到的作用就是配置提供者。
需要注意的是，哨兵只是配置提供者，而不是代理。二者的区别在于：
如果是配置提供者，客户端在通过哨兵获得主节点信息后，会直接建立到主节点的连接，后续的请求(如set/get)会直接发向主节点；
如果是代理，客户端的每一次请求都会发向哨兵，哨兵再通过主节点处理请求。
（2）通知：哨兵节点在故障转移完成后，会将新的主节点信息发送给客户端，以便客户端及时切换主节点。
基本原理
哨兵节点支持的命令
哨兵节点作为运行在特殊模式下的redis节点，其支持的命令与普通的redis节点不同。
在运维中可以通过这些命令查询或修改哨兵系统；
哨兵系统要实现故障发现、故障转移等各种功能，离不开哨兵节点之间的通信，而通信的很大一部分是通过哨兵节点支持的命令来实现的。
下面介绍哨兵节点支持的主要命令。
（1）基础查询：通过这些命令，可以查询哨兵系统的拓扑结构、节点信息、配置信息等。
- info sentinel：获取监控的所有主节点的基本信息
- sentinel masters：获取监控的所有主节点的详细信息
- sentinel master mymaster：获取监控的主节点mymaster的详细信息
- sentinel slaves mymaster：获取监控的主节点mymaster的从节点的详细信息
- sentinel sentinels mymaster：获取监控的主节点mymaster的哨兵节点的详细信息
- sentinel get-master-addr-by-name mymaster：获取监控的主节点mymaster的地址信息
- sentinel is-master-down-by-addr：哨兵节点之间可以通过该命令询问主节点是否下线，从而对是否客观下线做出判断
（2）增加/移除对主节点的监控
- sentinel monitor mymaster2 192.168.92.128 16379 2：与部署哨兵节点时配置文件中的sentinel monitor功能完全一样，不再详述
- sentinel remove mymaster2：取消当前哨兵节点对主节点mymaster2的监控
（3）强制故障转移
- sentinel failover mymaster：该命令可以强制对mymaster执行故障转移，即便当前的主节点运行完好；例如，如果当前主节点所在机器即将报废，便可以提前通过failover命令进行故障转移。
基本概念
关键是了解以下几个概念。
（1）定时任务：每个哨兵节点维护了3个定时任务。
- 通过向主从节点发送info命令获取最新的主从结构；
- 通过发布订阅功能获取其他哨兵节点的信息；
- 通过向其他节点发送ping命令进行心跳检测，判断是否下线。
（2）主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。
（3）客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。
（4）选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。
（5）故障转移：选举出的领导者哨兵，开始进行故障转移操作，该操作大体可以分为3个步骤：
- 在从节点中选择新的主节点：选择的原则是，首先过滤掉不健康的从节点；然后选择优先级最高的从节点(由slave-priority指定)；如果优先级无法区分，则选择复制偏移量最大的从节点；如果仍无法区分，则选择runid最小的从节点。
- 更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。
- 将已经下线的主节点(即6379)设置为新的主节点的从节点，当6379重新上线后，它会成为新的主节点的从节点。
配置与实践建议
配置
（1） sentinel monitor {masterName} {masterIp} {masterPort} {quorum}
- masterName指定了主节点名称，
- masterIp和masterPort指定了主节点地址，
- quorum是判断主节点客观下线的哨兵数量阈值：当判定主节点下线的哨兵数量达到quorum时，对主节点进行客观下线。建议取值为哨兵数量的一半加1。
（2） sentinel down-after-milliseconds {masterName} {time}
down-after-milliseconds的默认值是30000，即30s；
sentinel down-after-milliseconds与主观下线的判断有关：哨兵使用ping命令对其他节点进行心跳检测。
如果其他节点超过down-after-milliseconds配置的时间没有回复，哨兵就会将其进行主观下线。该配置对主节点、从节点和哨兵节点的主观下线判定都有效。
可以根据不同的网络环境和应用要求来调整：值越大，对主观下线的判定会越宽松，好处是误判的可能性小，坏处是故障发现和故障转移的时间变长，客户端等待的时间也会变长。
（3） sentinel parallel-syncs {masterName} {number}
sentinel parallel-syncs与故障转移之后从节点的复制有关：它规定了每次向新的主节点发起复制操作的从节点个数。
例如，假设主节点切换完成之后，有3个从节点要向新的主节点发起复制；
如果parallel-syncs=1，则从节点会一个一个开始复制；
如果parallel-syncs=3，则3个从节点会一起开始复制。
parallel-syncs取值越大，从节点完成复制的时间越快，但是对主节点的网络负载、硬盘负载造成的压力也越大；应根据实际情况设置。
例如，如果主节点的负载较低，而从节点对服务可用的要求较高，可以适量增加parallel-syncs取值。parallel-syncs的默认值是1。
（4） sentinel failover-timeout {masterName} {time}
sentinel failover-timeout与故障转移超时的判断有关，但是该参数不是用来判断整个故障转移阶段的超时，而是其几个子阶段的超时。
例如如果主节点晋升从节点时间超过timeout，或从节点向新的主节点发起复制操作的时间(不包括复制数据的时间)超过timeout，都会导致故障转移超时失败。
failover-timeout的默认值是180000，即180s；如果超时，则下一次该值会变为原来的2倍。
实践建议
（1）哨兵节点的数量应不止一个，一方面增加哨兵节点的冗余，避免哨兵本身成为高可用的瓶颈；另一方面减少对下线的误判。此外，这些不同的哨兵节点应部署在不同的物理机上。
（2）哨兵节点的数量应该是奇数，便于哨兵通过投票做出“决策”：领导者选举的决策、客观下线的决策等。
（3）各个哨兵节点的配置应一致，包括硬件、参数等；此外，所有节点都应该使用ntp或类似服务，保证时间准确、一致。
（4）哨兵的配置提供者和通知客户端功能，需要客户端的支持才能实现，如前文所说的Jedis；如果开发者使用的库未提供相应支持，则可能需要开发者自己实现。
（5）当哨兵系统中的节点在docker（或其他可能进行端口映射的软件）中部署时，应特别注意端口映射可能会导致哨兵系统无法正常工作，因为哨兵的工作基于与其他节点的通信，而docker的端口映射可能导致哨兵无法连接到其他节点。例如，哨兵之间互相发现，依赖于它们对外宣称的IP和port，如果某个哨兵A部署在做了端口映射的docker中，那么其他哨兵使用A宣称的port无法连接到A。
作者：编程迷思
出处：http://www.cnblogs.com/kismetv/p/8654978.html
