在 sentinel 之间建立连接之前，sentinel 将会尽力和配置文件中指定的 master 建立连接。sentinel 与 master 的连接中的通信主要是基于 pub/sub 来发布和接收信息，发布的信息内容包括当前 sentinel 实例的侦听端口。
3）Leader 选举
其实在 sentinels 故障转移中，仍然需要一个“Leader”来调度整个过程：master 的选举以及 slave 的重配置和同步。当集群中有多个 sentinel 实例时，如何选举其中一个 sentinel 为leader 呢？
redis2.8.7的选举有两个条件，首先是要下面的条件过滤掉一些节点
1、slave节点状态处于S_DOWN,O_DOWN,DISCONNECTED的除外
2、最近一次ping应答时间不超过5倍ping的间隔（假如ping的间隔为1秒，则最近一次应答延迟不应超过5秒，redis sentinel默认为1秒）
3、info_refresh应答不超过3倍info_refresh的间隔（原理同2,redis sentinel默认为10秒）
4、slave节点与master节点失去联系的时间不能超过（ (now - master->s_down_since_time) + (master->down_after_period * 10)）。总体意思是说，slave节点与master同步太不及时的（比如新启动的节点），不应该参与被选举。
5、Slave priority不等于0（这个是在配置文件中指定，默认配置为100）。 从备选node中，按照如下顺序选择新的master
1、较低的slave_priority（这个是在配置文件中指定，默认配置为100）
2、较大的replication offset（每个slave在与master同步后offset自动增加）
3、较小的runid（每个redis实例，都会有一个runid,通常是一个40位的随机字符串,在redis启动时设置，重复概率非常小）
4、如果以上条件都不足以区别出唯一的节点，则会看哪个slave节点处理之前master发送的command多，就选谁。
我们期望有足够多的sentinel实例， 这样能够确保当leader失效时， 能够选举某个sentinel为 leader，以便进行 failover。如果 leader 无法产生，比如较少的 sentinels 实例有效，那么failover 过程将无法继续。
4）failover 过程
在 Leader 触发 failover 之前，首先 wait 数秒(随即 0~5)，以便让其他 sentinel 实例准备和调整，如果一切正常，那么 leader 就需要开始将一个 salve 提升为 master，此 slave 必须为状态良好(不能处于 SDOWN/ODOWN 状态)且权重值最低(redis.conf 中)的， 当 master 身份被确认后，开始 failover。
五、Redis-sentinel学习总结
1）redis 的水平扩展。 前文所实现的是 redis 的主从 HA 集群 （从服务器做备份而存在） ，试想当缓存到了一个级别一台服务器已经不能满足了，就想到了 redis 的分布式，将缓存放到分配到多台服务器中。Redis 官方也提供了 redis cluster 来实现分布式，但目还没有正式版发布（redis 3.0貌似提供了支持，还没来得及研究）。Java 可以通过 jedis 的 ShardedJedis 来做分片 。
2）redis 的监控。一个东西运行的是否正常、稳定和性能情况，这就涉及到了对它的监控。目前 redis 的监控工具有：redmon、redis-live 等。本文暂不做监控，读者可参考其他资料学习使用。
3）集群时的读写分离。主用来写，从用来读。在 redis 的 HA 集群中，主从服务器是变化的，这就导致在程序中，不容易获得当前哪台服务是主，哪几台服务是从。我们可以自己通过代码实现获得从服务器的 jedis 实例，具体可以参见Redis中sentinel集群的搭建和Jedis测试 图文教程[二] 从而达到读写分离。
4）“缓存数据同步”也是所有缓存工具的一个必须思考的问题。