很多人都知道redis支持高并发，单节点可以支持10w/s的高并发。在实际生产使用环境中，除了追求高并发外，通常还要求高可用。这也就是redis集群的由来。
分布式中存在一个CAP理论的概念。
C代表Consistent 一致性
A代表 Availability 可用性
P代表 Partition tolerence 分区一致性
分布式系统一般都部署在多台服务器上，这也就意味着肯定会发生网络断开的风险。也就是说发生网络断开的时候，两台服务器间的数据一致性或者是否可用不能够同时满足。所以分布式系统中一般都是追求满足AP或者CP的服务。
Redis主从服务就是AP的了。当网络分区发生的时候，主从节点都可以对外提供服务。网络分区消除的时候，从节点会继续同步主节点产生的不一致数据。
同步有分为全量同步和增量同步，全量同步呢？就是redis此时此刻生成一个快照，把快照导入从服务器。全量同步一般会占用一定的资源。
增量同步呢？就是主节点10秒内修改了什么内容，从节点把这些内容同步过去。Redis同步的是指令流。主节点会把新增、修改、删除的指令记录到本地的buffer中，然后通过异步把buffer传到从节点。但是内存中的buffer是有限的，所以我们可以把redis的buffer想象成为一个buffer环，如果环满了，前面的内容就会被覆盖。于是主从断开时间过长的话，从节点就无法使用指令流的方式进行主从同步了，必须使用快照的方式。
主从同步的时候，主服务发送指令集的命令在半路丢失了。那么redi提供了一个REPLCONF ACK功能，从服务器会向主服务器发送指令，核对自身的偏移量。当两者的偏移量存在相差的时候，主服务器会补发缺失的数据。
我们来探讨下redis的哨兵模式。
存在一种情况，主从模式下假如主节点宕机了，怎么办呢？还需要程序员人为的去重启、分配主节点。那就不能存在一种方式，机器自己去配置主节点吗？哨兵模式也就应运而生。
顾名思义。哨兵就是存在一个单独的部门(程序)，专门用来做放哨使用。通过放哨来监控redis各个节点的状态。
Sentinel 负责监控主从节点的健康，当主节点挂掉后，Sentinel会选择一个最优的从节点切换成主节点。
主观下线：当第一个哨兵发现主节点宕机后，此时当前redis节点为主观下线
客观下线：当三分之二的哨兵都认为此主节点宕机后，此时当前的redis节点为客观下线
Sentinel选举算法：
当redis的节点宕机后，sentinel会进行故障转移，在这个时候所有的哨兵都拥有选举权，而且是发现主服务器进入客观下线的哨兵会要求其他哨兵选举自己，哨兵选举是遵守先到先得的原则。获取的票数大于半数，则此哨兵成为主节点。
redis哨兵模式的故障转移分为三大步：
1、从节点选择一个节点转换为新的主节点。
2、已下线主节点的从节点与新的主节点建立主从同步。
3、已下线的主节点降级为从服务器。
客户端连接集群的时候，会首先连接sentinel通过查询主节点信息，然后连接主节点进行数据的交互。进行故障转移后，客户端从哨兵里面获取到新的主节点信息。
除此之外，redis哨兵模式还会执行心跳检测。
我是凯腾凯，互联网浪潮下一枚苟且偷生的程序员。