Redis的高可用性

1、Redis的不可用

redis如果宕机，那么你基于缓存的高并发高性能就不可用了。那么大量的流量直接连接数据库，就可能把数据库搞死，这时候会直接造成系统的崩溃，后果很严重的。

2、Redis如何保证高可用

redis高可用架构叫做故障转移，failover，也可以叫做主备切换。一旦master node出现故障现象，会将一个slave node切换为master node。并且这个过程中只影响了写的操作，并不会影响读的操作，所以用户的感知也会相对小一些

3、哨兵模式

哨兵是redis中一个非常重要的组件主要功能如下：

1. 集群监控，负责监控master和slave是否正常工作
2. 消息通知，如果某个redis实例失效，哨兵负责发送消息给管理员
3. 故障转移，如果master node挂掉了，那么需要自动转移到slave上
4. 配置中心，如果发生故障转移，需要通知client客户端新的master地址

哨兵也是分布式的，并且故障转移时，必须要大部分的哨兵都同意才可以，这涉及到分布式选举的问题。

哨兵的核心知识

1. 哨兵至少需要3个实例，来保证自己的健壮
2. 哨兵+redis的主从架构部署，不能保证数据的0丢失，只能保证高可用性
3. 对于哨兵+redis主从架构部署，一定要多进行测试和容灾演练
4. 哨兵只有两个实例的时候是无法正常工作的，因为故障转移是需要大部分哨兵同意，但是故障转移时可能会有一个哨兵挂掉了，只剩下一个哨兵的话没有其他哨兵同意它进行故障转移，那么久没办法执行。

4、哨兵+redis主从导致数据丢失

异步复制：
前面我们说了，为了保证redis的高性能，做了主从模式redis。master node进行写数据操作，slave node进行读数据操作。并且往master写数据的时候写成功之后master是会直接返回成功的回执。但是！如果还没来得及将更新的数据复制给slave node，master node就宕机了，那slave node变成了新的master node，那么刚才更新的数据就会丢失了

集群脑裂：
这种情况一般不会出现，但也有一定的概率。我们都知道，集群主机之间是通过网络通信的那么如果哨兵、slaver node都和master node失去联系了，那么可能会认为master node已经挂掉了，就会重新选举出一个master node。但是原来的master node实际上并没有死，还在和client继续通信，那么这段时间更新的数据就会丢失

5、解决哨兵+redis主从导致数据丢失问题

min-slaves-to-write 1
min-slaves-max-lag 10
这两个参数的意思是，要求至少有一个slave node，数据复制和同步的时间延迟不能超过10s，一旦所有的slave节点数据复制和同步的延迟都超过了10s，那么master就不会再接收任何请求了。
这样就解决了“异步复制”和“集群脑裂”带来的问题，因为一旦slave的复制和同步延时太长，就默认master可能宕机或者失去联系，避免损失数据过多，直接拒绝接收请求。这样可以把损失的数据减小到一定的范围内。
我们在client客户端可以做降级处理，访问不到master时候先将数据临时存入kafak队列中或者存入其他缓存之类的10分钟之后再取出来，同时对外来请求做限流，减慢请求涌入速度

6、哨兵如何选举slave

我们要了解几个知识点：

• sdown和odown转换机制
• 哨兵和slave集群的自动发现机制
• slave的自动纠正
• slave-master的选举算法

首先第一个：sdown和odown转换机制。sdown是主观宕机，是一个哨兵自己觉得master宕机了；odown是客观宕机，其他的quorum数量（redis哨兵的配置）的哨兵都认为master宕机了并且给这个哨兵发送消息说master宕机了，这时候就从sdown转为odown。
第二个：哨兵和slave集群的自动发现机制，哨兵之间的相互发现是通过redis的pub/sub来实现的。每隔两秒钟，每个哨兵都会往_sentinel_:hello这个channel里发送一个消息，内容是自己的host、ip和runid还有对自己这个master的监控配置，每个哨兵也会监听自己监控的每个master+slave的_sentinel_:hello channel，然后去感知同样在监听这个master+slave的其他哨兵存在。
第三个：slave的自动纠正，比如某个slave要成为潜在的master，哨兵会确保这个slave完全复制了master的数据。比如新的master诞生了，哨兵会确保slave可以连接到新的master上。
第四个：slave-master的选举算法，首先通过断开时长过滤掉一些不合格的从节点，然后看slave有没有配置优先级，没有的话就看谁的offset大，就复制的多。最后都一样，就看run id。run id越小的说明启动时间越早越适合做master。