在前面文章介绍了Redis的一些常用命令，及持久化方式，那么Redis作为一个分布式缓存是怎么保证自己数据的高可用的，下边我们来介绍一下Redis的集群
Redis的主从复制
主从复制流程
1.slave服务器通过psync命令发送它自己已有的同步进度(同步源ID-可以理解用master-server的唯一id,同步进度offset)
2.master收到请求后，如果同步源id为当前master-server，则根据偏移量offset增量同步
3.如果同步源非当前master，则进入全量同步，master-server生成rdb数据快照传输到slave，加载到slave内存中
4.复制的过程是异步复制
5.一个master可以拥有多个slave
6.slave可以接受其他slave的连接，同事slave也可以有下级的sub-slave
7.主从同步时，在master侧是非阻塞的
8.slave初次同步，会删除旧数据，加载新数据，会阻塞到来的连接请求
主从复制使用场景
1.读多写少
2.slave设为只读，数据安全隔离
但会出现复制风暴的问题，一主多从，每个slave都要复制，并且主从复制，还是只有一个master，写的能力还是有限
主从复制的使用
1.为提升master写的性能，master关闭持久化，slave开启aof,减少master持久化的压力
2.关闭故障自动重启，master重启后，无数据，会导致集群数据丢失。
3.故障后，从slave拿到备份文件就行恢复，然后手动重启master
Redis哨兵模式
1.哨兵连接到master，为client提供服务，如果哨兵是一个集权，只有超过一定数量的哨兵，判定master存在问题，才会做故障切换
2.client在使用期间，真正访问的是Redis-server master，当客户端发现Redis-server出现问题时，会去询问哨兵，如果哨兵出现了问题，此时集群中还有其他哨兵，客户端在重试之后，会连接到其他哨兵，这里只有当客户端无法去连接redis-server 的master时，才会去通过询问哨兵，获取最新的可用连接
3.哨兵搭建与故障恢复流程
哨兵如何知道Redis主从信息
1.哨兵配置文件中，保存这主从集权中master的信息，哨兵启动时，通过info命令，进行主从信息的自动发现
2.哨兵的检测机制，哨兵通过向Redis服务发送ping请求，来判断Redis服务的状态。
主观下线与客观下线
1.主观下线：单个哨兵自认为Redis实例已经不能提供服务。
2.客观下线：一定数量值的哨兵认为master下线。当哨兵认为master下线后，则通过sentinelis-master-down-by-addy 命令询问其他哨兵，是否认为master已经下线，如果达成共识（到达quorum个数,哨兵配置文件中可以配置），就认为master节点客观下线，开始故障转移。
哨兵之间如何通信
哨兵之间通过PUB/SUB消息订阅。
sentinel 命令来订阅
哨兵的选举规则：Raft算法
Raft算法主要分为四个阶段。
1.拉票阶段，所有的哨兵都希望自己成为领导者，都会去发起选举
2.sentinel节点收到拉票命令后，如果没有收到或者同意过其他的sentinel节点的请求，就同意该sentinel节点的请求，每个sentinel只持有一张票数
3.如果sentinel节点发现自己的票数已经超过一半的值，那么它就成为领导者，去执行故障转移
4.投票结束后，如果超过failover-timeout的时间内，没进行实际的故障转移操作，则重新拉票选举
Raft算法为避免出现无法选举的情况，在每个sentinel去发送拉票的时候，会有随机休眠去进行拉票，这样有效避免了无法选举出leader的情况。
