【Redis】高可用方案（主从、集群、哨兵集群、主动复制、脑裂）

https://zhuanlan.zhihu.com/p/596995935   推荐，详细的主从、哨兵、集群等搭建过程实战

参考：

https://segmentfault.com/a/1190000039060249

https://blog.csdn.net/weixin_41385912/article/details/122817029

---

 

一、Redis主从复制模式

一主多从（一个或者多个从节点）：其中主节点主要负责读和写，然后会将数据同步到多个从节点上

主从库同步：先全量同步（刚建立主从连接阶段） + 增量同步（全量同步结束后）

Client 也可以对多个从节点发起读请求，这样可以减轻主节点的压力，但和 ZK 一样，由于只有一个主节点，存在单点隐患，所以必须引入第三方仲裁者的机制来判定主节点是否宕机以及在判定主节点宕机后快速选出某个从节点来充当主节点的角色，这个第三方仲裁者在 Redis 中我们一般称其为「哨兵」（sentinel），

　　  

哨兵进程本身也有可能挂掉，所以为了安全起见，需要部署多个哨兵（即哨兵集群）；哨兵通过 gossip协议来接收关于主服务器是否下线的信息，并在判定主节点宕机后使用 Raft 协议来选举出新的主节点。

　　

主从存在的问题：

1、主节点写的压力难以降低：因为只有一个主节点能接收写请求，如果在高并发的情况下，写请求如果很高的话可能会把主节点的网卡打满，造成主节点对外无法服务

2、主节点的存储能力受到单机存储容量的限制：因为不管是主节点还是从节点，存储的都是全量缓存数据，那么随着业务量的增长，缓存数据很可能直线上升，直到达到存储瓶颈

3、同步风暴：因为数据都是从 master 同步到 slave 的，如果有多个从节点的话，master 节点的压力会很大

哨兵工作机制

1、周期性给所有主从库PING；

2、主库挂了以后，哨兵基于一定规则评分选选举出一个从库实例新的主库；

3、哨兵会将新主库的信息发送给其他从库，让它们和新主库建立连接，并进行数据复制。同时，哨兵会把新主库的信息广播通知给客户端，让它们把请求操作发到新主库上。

哨兵集群：

基于少数服从多数原则， 当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线” （可以自定义设置阙值）。

 

二、Redis分片集群

 所谓分片集群即将数据分片，每一个分片数据由相应的主节点负责读写，这样的话就有多个主节点来分担写的压力，并且每个节点只存储部分数据，也就解决了单机存储瓶颈的问题，但需要注意的是每个主节点都存在单点问题，所以需要针对每个主节点做高可用，整体架构如下

    

 

原理也很简单，在 Proxy 收到 client 执行的 redis 的读写命令后，首先会对 key 进行计算得出一个值，如果这个值落在相应 master 负责的数值范围（一般将每个数字称为槽，Redis 一共有 16384 个槽）之内，那就把这条 redis 命令发给对应的 master 去执行，可以看到每个 master 节点只负责处理一部分的 redis 数据，同时为了避免每个 master 的单点问题，也为其配备了多个从节点以组成集群，当主节点宕机时，集群会通过 Raft 算法来从从节点中选举出一个主节点

三、Redis实现高可用可能的问题

数据丢失：

1、主备切换的过程， 异步复制导致的数据丢失

     因为master 将数据复制给slave是异步实现的，在复制过程中，这可能存在master有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了。

2、脑裂导致的数据丢失

    当一个集群中的 master 恰好网络故障，导致与 sentinal 通信不上了，sentinal会认为master下线，且sentinal选举出一个slave 作为新的 master，此时就存在两个 master了。

    此时，可能存在client还没来得及切换到新的master，还继续写向旧master的数据，当master再次恢复的时候，会被作为一个slave挂到新的master 上去，自己的数据将会清空，重新从新的master 复制数据，这样就会导致数据缺失。

数据不一致：主备切换的过程，异步复制导致数据不一致

在主从异步复制过程，当从库因为网络延迟或执行复杂度高命令阻塞导致滞后执行同步命令，这样就会导致数据不一致