Redis中sentinel集群的搭建和Jedis测试图文教程[三] - 数据库编程

.1:16379 voted for 1eb0f03b7a7815c3c5506b0fa041ad8d6ca9db90 1（投票选举Leader）； g.127.0.0.1:36379 voted for 1eb0f03b7a7815c3c5506b0fa041ad8d6ca9db90 1（投票选举Leader）； h.+elected-leader master mymaster 127.0.0.1 6379（之前被选举出来的 master）； i.+failover-state-select-slave master mymaster 127.0.0.1 6379（Leader 开始查找合适的slave）； j.+selected-slave slave 127.0.0.1:63792 127.0.0.1 63792 @ mymaster 127.0.0.1 6379 （leader已经找到合适的 slave）； k.+failover-state-send-slaveof-noone slave 127.0.0.1:63792 127.0.0.1 63792 @ mymaster 127.0.0.1 6379（Leader 向 slave 发送“slaveof no one”指令，此时 slave 已经完成角色转换，此 slave 即为 master）； l.+failover-state-wait-promotion slave 127.0.0.1:63792 127.0.0.1 63792 @ mymaster 127.0.0.1 6379（等待其他 sentinel 确认 slave）； m.+promoted-slave slave 127.0.0.1:63792 127.0.0.1 63792 @ mymaster 127.0.0.1 6379（确认成功）； n.+failover-state-reconf-slaves master mymaster 127.0.0.1 6379 （开始对slaves进行reconfig 操作）； o.+slave-reconf-sent slave 127.0.0.1:63791 127.0.0.1 63791 @ mymaster 127.0.0.1 6379 （向指定的 slave 发送“slaveof”指令，告知此 slave 跟随新的 master）； p. +slave-reconf-inprog slave 127.0.0.1:63791 127.0.0.1 63791 @ mymaster 127.0.0.1 6379（此 slave 正在执行 slaveof + SYNC 过程，如过 slave 收到“+slave-reconf-sent”之后将会执行 slaveof 操作，循环 n）； q.+slave-reconf-done slave 127.0.0.1:63791 127.0.0.1 63791 @ mymaster 127.0.0.1 6379（此 slave 同步完成，此后 leader 可以继续下一个 slave 的 reconfig 操作）； r.+failover-end master mymaster 127.0.0.1 6379（故障转移结束）； s.+switch-master mymaster 127.0.0.1 6379 127.0.0.1 63792（故障转移成功后，各个sentinel 实例开始监控新的 master）； t.+slave slave 127.0.0.1:63791 127.0.0.1 63791 @ mymaster 127.0.0.1 63792（下面几步在给新的 master 加入 slave）； u.+slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 63792； v.+sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 63792。

 　　当环境稳定后，我们发现，redis-2 被提升(“promoted”)为 master，且 redis-1 也通过”slave-reconf”过程之后跟随了 redis-2。 
 如果此时 redis-0 服务器恢复正常， sentinel 会自动将 redis-0 作为 slave 加入到 redis-2 中。 
 　　下面是 redis-0 的 sentinel 控制台输出的信息。 
 　　 
 　　 
 　　再次查看 redis-2(当前 master 的 info) 
 　　 
 　　提示：sentinel 实例需要全程处于启动状态,如果只启动 server 而不启动相应的 sentinel,仍然不能确保 server 能够正确的被监控和管理。
 四、Redis-sentinel原理分析
 1）SDOWN 和 ODOWN 转换过程 
 【名词解释】 
 　　SDOWN:subjectively down，直接翻译的为”主观”失效，即当前 sentinel 实例认为某个redis 服务为”不可用”状态。 
 　　ODOWN:objectively down，直接翻译为”客观”失效，即多个 sentinel 实例都认为 master处于”SDOWN”状态，那么此时 master 将处于 ODOWN，ODOWN 可以简单理解为 master已经被集群确定为”不可用”，将会开启 failover。 
 　　（ SDOWN 适合于 master 和 slave，但是 ODOWN 只会使用于 master；当 slave 失效超过”down-after-milliseconds”后，那么所有 sentinel 实例都会将其标记为”SDOWN”。）





 【转换过程】 
 　　a.每个 sentinel 实例在启动后，都会和已知的 slaves/master 以及其他 sentinels 建立 TCP连接,并周期性发送 PING(默认为 1 秒)； 
 　　b.在交互中，如果 redis-server 无法在”down-after-milliseconds”时间内响应或者响应错误信息，都会被认为此 redis-server 处于 SDOWN 状态； 
 　　c.如果 b.中 SDOWN 的 server 为 master， 那么此时 sentinel 实例将会向其他 sentinel 间歇性(一秒)发送”is-master-down-by-addr “指令并获取响应信息， 如果足够多的 sentinel 实例检测到 master 处于 SDOWN，那么此时当前 sentinel 实例标记 master 为 ODOWN…其他 sentinel实例做同样的交互操作.配置项”sentinel monitor “，如果检测到 master 处于 SDOWN 状态的slave 个数达到，那么此时此 sentinel 实例将会认为 master 处于 ODOWN； 
 　　d.每个 sentinel 实例将会间歇性(10 秒)向 master 和 slaves 发送”INFO”指令，如果 master失效且没有新 master 选出时，每 1 秒发送一次”INFO”；”INFO”的主要目的就是获取并确认当前集群环境中 slaves 和 master 的存活情况； 
 　　经过上述过程后，所有的 sentinel 对 master 失效达成一致后，开始 failover。
 2） Sentinel 与 slaves”自动发现”机制 
 　　在 sentinel 的配置文件中(local-sentinel.conf)，都指定了 port，此 port 就是 sentinel 实例侦听其他 sentinel 实例建立链接的端口.在集群稳定后，最终会每个 sentinel 实例之间都会建立一个 tcp 链接，此链接中发送”PING”以及类似于”is-master-down-by-addr”

Redis中sentinel集群的搭建和Jedis测试图文教程[三](二)

四、Redis-sentinel原理分析