如何保证Redis的高可用

 

什么是高可用

　　全年时间里，99%的时间里都能对外提供服务，就是高可用

 

 

主备切换

　　在master故障时，自动检测，将某个slave切换为master的过程，叫做主备切换。这个过程，实现了Redis主从架构下的高可用性。

 

哨兵是redis集群架构中非常重要的一个组件，主要功能如下

　　集群监控，负责监控redis master和slave进程是否正常工作
　　消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
　　故障转移，如果master node挂掉了，会自动转移到slave node上
　　配置中心，如果故障转移发生了，通知client客户端新的master地址

 

哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作

　　故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
　　即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了

 

哨兵的核心知识

　　哨兵至少需要3个实例，来保证自己的健壮性
　　哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性
　　对于哨兵 + redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练

 

 

 

 

 

两种数据丢失的情况

主备切换的过程，可能会导致数据丢失

（1）异步复制导致的数据丢失

　　因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了

 

（2）脑裂导致的数据丢失

　　脑裂(网络分区)，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着

　　此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master

　　这个时候，集群里就会有两个master，也就是所谓的脑裂

　　此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了

　　因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据

 

解决异步复制和脑裂导致的数据丢失

　　min-slaves-to-write 1
　　min-slaves-max-lag 10

　　要求至少有1个slave，数据复制和同步的延迟不能超过10秒

　　如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了

　　上面两个配置可以减少异步复制和脑裂导致的数据丢失

 

（1）减少异步复制的数据丢失

　　有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内

 

（2）减少脑裂的数据丢失

　　如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求

　　这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失

　　上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求

　　因此在脑裂场景下，最多就丢失10秒的数据

 转自：中华石杉Java工程师面试突击