集群：Sentinel

主从方案下，假如主节点宕机的话，需要把程序的IP、端口改成从节点的，这些工作太麻烦，还不如把主节点做成集群，即便某一台主节点宕机了，也不用去修改程序，这里Redis提供了Sentinel来解决这个问题。

可以把Sentinel集群看成是一个ZooKeeper集群，它是集群高可用的心脏，它一般是由3～5个节点组成，这样挂了个别节点集群还可以正常运转。

其工作过程简述如下：它负责持续监控主从节点的健康，当主节点挂掉时，自动选择一个最优的从节点切换为主节点。客户端来连接集群时，会首先连接sentinel，通过sentinel来查询主节点的地址，然后再去连接主节点进行数据交互。当主节点发生故障时，客户端会重新向sentinel要地址，sentinel会将最新的主节点地址告诉客户端。如此应用程序将无需重启即可自动完成节点切换。

这里有个潜在的问题：因为Redis一般是异步复制，当主节点宕机之后，从节点可能没有收到全部的同步消息，这部分未同步的消息就丢失了。如果主从延迟特别大，那么丢失的数据就可能会特别多。Sentinel无法保证消息完全不丢失，但是也尽可能保证消息少丢失。它有两个选项可以限制主从延迟过大。

①min-slaves-to-write 1

②min-slaves-max-lag 10

第一个参数表示主节点必须至少有一个从节点在进行正常复制，否则就停止对外写服务，丧失可用性。

何为正常复制，何为异常复制？这个就是由第二个参数控制的，它的单位是秒，表示如果 10s 没有收到从节点的反馈，就意味着从节点同步不正常，要么网络断开了，要么一直没有给反馈。

sentinel的默认端口是 26379，通过sentinel对象的 discover_xxx 方法可以发现主从地址，主地址只有一个，从地址可以有多个。

通过 xxx_for 方法可以从连接池中拿出一个连接来使用，因为从地址有多个，redis 客户端对从地址采用轮询方案，也就是 RoundRobin轮着来。