Sentinel结构是在redis3.0之前的版本实现的。一般使用Sentinel工具来监控master节点的状态。如果master节点异常，会从master切换成slave，一个slave作为master和sentinel的配置稍微复杂，性能和高可用一般，尤其是主从切换发生在访问中断的瞬间，而sentinel模式只有一个master节点对外提供服务，无法支持高并发，单个master节点的内存也不宜设置太大，否则持久化文件会过大，影响数据恢复或主从同步的效率。哨兵初始化哨兵（Sentinel）是一种Redis高可用（highavailability）解决方案，由一个或多个哨兵实例（instance）组成的一个哨兵系统（system）可以监控一个或多个Redis主服务器及其下面的从服务器，并且当监控的master服务下线，当前master服务器的其中一台slave服务器自动升级为主服务器，然后将下线的master服务器设置为新master服务器的slave节点。Sentinel本身可以理解为一个特殊的Redis服务器，也可以通过redis-serverxxx.conf--sentinel启动。下面是我们实验环境中的Sentinel服务器和Redis服务器列表（由于实验是在本地进行，所以我们使用端口来区分多个服务），服务和端口大致如下：IP端口集群127.0.0.16379Master127。0.0。16380Slave127.0.0.16381Slave127.0.0.126379Sentinel127.0.0.126380Sentinel127.0.0.126381Sentinel首先我们找到Redis的配置文件目录，在redis-sentinel.conf文件中修改如下参数：#sentinelportport26381#backgroundrunningdaemonize主服务器和从节点sentinelmonitormymaster127.0.0.163792sentinel启动命令如下：redis-serverredis-sentinel-26379.conf--sentinelredis-serverredis-sentinel-26380.conf--sentinelredis-serverredis-sentinel-26381.conf--sentinel登录Sentinel节点，查询集群状态，使用info命令。sentinel服务和其他redis服务节点的区别在于，在启动过程中，不会加载RDB或者AOF来恢复数据。Sentinel与Redisservice_commandconnection_通信，建立链接接收master/slave服务器的回复（默认10秒发送requestinfo信息获取节点状态，failover时改为1秒。并每隔一秒向服务器节点发送一个PING命令来判断服务是否在线）。用于订阅主服务器的__sentinel__:hello频道的订阅链接。让我们先在主节点上验证查询并执行SUBSCRIBE__sentinel__:hello。我们可以通过INFO命令查询主节点服务上的同步信息。在从节点服务器上通过INFO命令查询同步信息。Sentinels之间的通信对于监控同一个主/从服务器的多个Sentinel节点，它们会每两秒向被监控服务器的__sentinel__:hello通道发送消息以宣告它们的存在。Sentinels之间不会创建订阅链接，通信将通过命令进行通信。因为已经可以通过主/从服务器获取未知的Sentinel服务节点。Sentinel获取Redis节点列表**Sentinel默认每10秒向主服务器发送一次信息，通过发送info命令的回复获取当前主服务器的信息**。#Serverrun_id:5e4d6e3ee147ff231d540ae2add485e906944f2a...#Replicationrole:masterconnected_slaves:2slave0:ip=127.0.0.1,port=6381,state=online,offset=2712947,lag=0slave1:ip=127.0.080,portate=2,71goffset=2,71g1g=0master_replid:f2163cc41b43c20998a54c14647ba5b106dc4677master_replid2:0000000000000000000000000000000000000000master_repl_offset:2713213second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:1664638repl_backlog_histlen:1048576....通过分析主服务器的info命令可以获取到以下两方面的信息：关于服务器本身的信息，Includingrun_idtorecordthe服务器的运行id，以及服务器角色等。还有一个方面就是获取主服务器下的所有从服务器信息，比如：slave0:ip=127.0.0.1,port=6381,state=online,offset=2712947,lag=0这样我们就不需要配置从服务器了在conf文件中Sentinel可以自动发现服务器信息。Sentinel从主服务器获取到从服务器信息后，还会向从服务器发送INFO命令10秒，获取从服务器信息。Wecanexecutethecommandredis-cli-h127.0.0.1-p6380infotogetthefollowinginformation:#Serverrun_id:7ef635af0d3e0b1d60d2776eba0a15883db06245...#Replicationrole:slavemaster_host:127.0.0.1master_port:6379master_link_status:upmaster_last_io_seconds_ago:0master_sync_in_progress:0slave_repl_offset:2779874slave_priority:100slave_read_only:1connected_slaves:0master_replid:f2163cc41b43c20998a54c14647ba5b106dc4677master_replid2:0000000000000000000000000000000000000000master_repl_offset:2779874second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:1731299repl_backlog_histlen:1048576...Wecangetthefollowinginformationfromtheresult:therunningIdoftheserverrun_id.服务器的作用。主服务器信息master_host，master_port。主从服务器的连接状态master_link_status。从机优先级slave_priority。从slave_repl_offset的复制偏移量。服务下线主观下线：一个哨兵判断下线客观下线：主观下线后，会询问其他哨兵节点判断主节点是否下线。如果真的下线了，那就客观下线了。sentinel配置文件中的down-after-millseconds选项指定了sentinel实例进入主观下线所需的时间；如果一个实例在down-after-millseconds毫秒内连续向Sentinel返回无效回复，那么Sentinel会修改这个实例对应的实例结构，并在该结构的flags属性中开启SIR_S_DOWN标志，表示这个实例主观下线.当超过半数的sentinel节点检测到某个redis节点下线时，此时集群中的节点才真正判断为下线，也称为客观下线。leadersentinel的选举当master节点客观下线时，会进行一次sentinel选举，选举出leadersentinel对redissentinel集群进行failover。领袖哨兵选举规则：所有在线哨兵都有资格被选举。每次选举后，无论选举成功与否，哨兵配置epoch都会自动递增。每个configurationepoch都有机会设置某个sentinel作为localleadersentinel，localleadersentinel一旦在当前configurationepoch被设置，就不能修改。每一个发现主服务器客观下线的sentinel都会要求其他sentinel将自己设置为本地leadersentinel。将被拒绝。如果某个哨兵被半数以上哨兵设置为本地首领哨兵，则该哨兵成为首领哨兵。因为leadingsentinel的产生需要半数sentinel的支持，而每个configurationepoch只能设置一个leadingsentinel，所以只会出现一个leadingsentinel。如果在规定时间内没有产生领头哨兵，则进行重新选举，直到选出领头哨兵。Failover故障转移分为三个步骤：在离线的主服务器下的所有服务器中，选择一个从服务器作为主服务器。让离线主服务器下的所有从服务器复制新的主服务器。将下线的主服务器设置为新主服务器的从服务器，当旧的主服务器恢复上线后，它将成为新主服务器的从服务器。选择新的主服务器过滤从服务器。删除掉线的从服务器，确保它们都正常上线。删除列表中所有5秒内没有响应sentinleleader的info命令的服务器，保证列表中剩余的从服务器正常通信。保证从服务器的数据是最新的，主要是删除与主服务器断开连接超过down-after-millseconds*10毫秒的服务器。确保没有过早断开连接。最后按照上面的过滤后，排序选出优先级最高的。1）如果有多个相同优先级的服务器，考虑偏移量最大的从服务器（slave_repl_offset），因为偏移量最大说明保存的数据是最新的。2）如果还有offset相同的slaveserver，则选择runningid（run_id）最小的slaveserver。发生故障转移后，Server2升级为主服务器，修改从服务器的复制目标。当新的主服务器出现时，领头的哨兵会允许其他服务器节点复制新主节点的数据。这可以通过向从服务器发送saveof命令来完成。完成。旧主服务器变为从服务器故障转移的最后一个操作是将下线的主服务器设置为新主服务的从服务器。
