什么是Sentinel？哨兵（Sentinel）是redis的高可用解决方案。我们前面讲的主从复制是高可用的基础，但是纯主从复制需要人工干预才能完成故障转移。Sentinel可以解决这个问题。在主从复制的情况下，当master节点出现故障时，Sentinel可以自动检测故障并完成故障转移，实现真正的redis高可用。在sentinel集群中，sentinel会监控所有redis服务器和其他sentinel节点的状态，及时发现故障完成传输，保证redis的高可用。Sentinel集群搭建Sentinel本质上也是一个redis服务，只是它提供的功能与普通的redis服务不同。Sentinel是一个分布式架构，因为如果要保证redis的高可用，首先要保证你是高可用的，所以如果我们需要搭建一个sentinel，我们至少需要部署三个实例，最好是奇数个，因为在后续的failover中会涉及到Voting。sentinel配置文件可以在redis的github项目下下载。项目下有一个叫sentinel.conf的文件，可以作为我们sentinel的配置模板。当然也可以使用redis.conf配置文件，只需要添加Sentinel相关配置即可。sentinel相关的配置项不多，主要是以下配置项：//端口号，默认是redis实例+20000，所以我们就按照这个规则port26379//daemonizeyes是否运行daemonizeyes//日志存放位置，这个很重要，可以通过日志logfile"26379.log"查看故障转移过程//监控一个名为mymaster（自定义）的redis主服务器，这个主服务器的IP地址为127.0.0.1，端口号为6379,//最后2表示在failover之前至少有两个sentinel认为masterserver发生故障，否则判定masterservice没有发生故障。收到服务器的响应后，认为服务器失效。sentineldown-after-millisecondsmymaster30000//故障转移完成后，有多少从服务器可以同时发起数据复制。数字越小，完成所有从服务数据复制所需的时间越长//数字越大，主服务器的压力越大。sentinelparallel-syncsmymaster1//failovertimeoutsentinelfailover-timeoutmymaster180000每个Sentinel实例配置，除了port和logfile，其他配置项相同。修改完配置后，我们就可以使用./redis-sentinelsentinel.conf命令来启动sentinel了。该命令类似于redis实例启动，因为sentinel也是一个redis实例，所以我们可以使用./redis-cli-p26379infosentinel命令查看当前sentinel信息如下图所示：哨兵信息问题：如何在只配置主服务器的情况下发现从服务器和其他Sentinels？对于从服务器的发现，Sentinel可以通过询问主服务器来获取从服务器的信息。对于其他Sentinel节点的发现，是通过发布和订阅，向通道sentinel:hello发送信息来实现的。主要有两个步骤：1.每个Sentinel每隔2秒会向所有主服务节点发布和订阅一次。并从服务器的sentinel:hello通道发送消息，消息中包含Sentinel的IP地址、端口号和运行ID(runid)2，每个Sentinel订阅它监控的所有主从服务器的sentinel:hello通道，looking对于以前没有出现过的哨兵（寻找未知的哨兵）。当Sentinel发现一个新的Sentinel时，它会将新的Sentinel添加到一个列表中，该列表包含监视同一主服务器的Sentinel已知的所有其他Sentinel。Failover原理Failover是最主要的工作，这背后的实现逻辑也很复杂。具体实现逻辑可以参考相关书籍。关于Sentinel的failover我总结了以下三点：1.监听服务器的每个Sentinel节点向master节点发送消息，Slave节点和其他Sentinel节点发送ping命令进行心跳检测，以确定服务器的状态.节点也会相应地回复Sentinel。在这些回复中，以下三个回复为有效回复：返回+PONG返回-LOADING返回-MASTERDOWN如果节点在Sentinel配置文件中设置的master-down-after-milliseconds选项的值如果没有有效回复甚至一次，Sentinel会将服务器标记为离线。我们称这个离线为主观离线，也就是说只有这个哨兵认为服务器离线了。如果主观下线的服务器是主服务器，为了确认主服务器是否真的下线，Sentinel会询问其他同样监控主服务器的Sentinel，看是否也认为主服务器已经进入下线state，当足够多的Sentinels认为主服务器下线时，Sentinel会客观判断主服务器下线，即真正下线，并对其进行故障转移操作。2、选举Sentinel节点完成转移任务Failover并不是所有的sentinel一起完成的，而是选举一个sentinel节点作为leader来完成本次failover，所以当主服务器被标记为客观下线时，sentinel的Aleader会通过Raft算法被选举出来完成故障转移工作。Redis选举leadersentinel的规则和方法大致如下：所有在线的sentinel都有被选举为leader的资格，也就是说每个sentinel都有机会成为leader。当sentinel将主服务器标记为主观下线时，它会向其他Sentinel节点发送sentinelis-master-down-by-addr命令，请求将自己设置为接收到leader命令的Sentinel节点，使用first-先到先得的规则，如果没有同意其他Sentinel节点的sentinelis-mastermaster-down-by-addr命令会同意请求，否则会被拒绝。如果Sentinel节点发现自己拥有超过半数的选票，它就会成为领导者。如果sentinelleader在规定的时间内没有被选出，那么它会在一段时间后重新进行Election，直到选出sentinelleader。3.选举新的主服务器完成故障转移。Theelectedsentinelleaderwillcompletetherestofthefailoverwork.故障转移主要有以下三个步骤：(1)在所有已经下线的主服务器中选择一个新的主服务器。从从服务器中，选择一个从服务器并将其转换为主服务器。选择新主服务器的规则如下：在故障主服务器下的从服务器中，那些被标记为主观下线、断开连接，或者最后一次回复PING命令时间超过5秒的从服务器将被淘汰。故障主服务器下的从服务器，以及与故障主服务器断开连接时间超过down-after选项指定时间十倍以上的从服务器将被淘汰。在经过上述两轮淘汰后剩余的从服务器中，选择复制偏移量（replicationoffset）最大的从服务器作为新的主服务器；如果复制偏移量不可用，或者如果从服务器的复制偏移量相同，则具有最小运行ID的从服务器成为新的主服务器。在选中的从服务器上执行slaveofnoone命令，使其成为主节点。(2)修改其他从服务器的复制目标。当新的主服务器出现时，sentinelleader下一步就是通过向其他从服务器发送slaveofnew_masterport命令让其他从服务器复制新的主服务器。完成，复制规则与配置文件的parallel-syncs参数相关(3)将旧的主服务器变成从服务器的故障转移操作最后要做的是将离线的主服务器设置为从服务器newmasterservice，并时刻关注它，等它恢复正常后，命令它复制新的master节点。以上就是我今天要分享的redissentinel知识，希望大家看完后有所收获。
