Redis 高可用性

高可用性定义

高可用性是指通过尽量缩短日常维护操作和突发的系统崩溃所导致系统停机时间，以提高系统和应用的可用性。

高可用性一般来说有两个含义：数据尽量不丢失，保证服务尽可能可用。AOF(快照)、RDB(操作日志)数据持久化保证数据尽量不丢失；多节点方式保证某个节点出问题其他节点可以正常服务

高可用性实现

主从模式

主从模式就是部署多态redis服务器，其中一台是主节点其他是slave节点。主从节点实现读写分离，主节点负责数据写入，从节点负责数据读取；只有主节点提供数据的事务性（增删改，例如共享锁）

 主从模式数据同步流程

在主从服务器建立连接，并且确认好各自身份后，就开始数据同步。从服务器向主服务器发送psync命令，并把自己数据节点状态更新致主服务器用以决定全量重同步还是增量重同步

 

全量同步 -- 全量同步过程中感觉也有增量同步的内容

首次配置完成主从节点之后的全量复制：从节点第一次连接到主节点时，采用psync方式进行全量复制，这意味着从节点会从头开始复制主节点的所有数据

step1: 从节点向主节点发送psync指令

step2：判断是第一次同步即全量同步，主节点执行bgsave生成快照文件

step3:主节点发送快照文件到从节点

step4:从节点接收快照文件，同时删除从节点中旧数据,从节点载入新接收的快照文件

step5: 将step2 step3执行阶段新的写指令继续发送给从节点

step6: 从节点执行接收到命令

 

如何判断从节点是第一次连接主节点

可以通过以下参数进行判断

•  Replication Id:从数据节点是否第一次连接主节点就是根据这个字段值进行判断的，如果主从节点Replication id一致，那么表明主从节点不是第一次连接，如果不一致则表明是第一次连接。因为redis不同节点最开始的replication id是不一样，只有主从连接一次后，主节点的replication Id会同步到从节点
•  Offset: 主节点完成一次数据同步到从节点时会将自己当前的offset同步到从节点。之后主节点又进行写指令那么主节点的offset会与从节点的offset不一致，这样就会将主节点offset与从节点offset差值部分以增量同步方式复制到从节点

增量同步

step1: 从节点向主节点发送psycn指令

step2：主节点判断不是第一次同步

step3: 根据主从节点offset差值部分发送给从节点进行增量同步

 

哨兵模式

主从模式中如果主节点宕机那么所有服务将会瘫痪，这是需要采用哨兵模式对主从模式中所有节点进行监控。哨兵模式就是在主从模式基础上增加了故障转移功能，当主节点出现故障时通过投票机制选择新的master，并将其他所有slave节点连接到master节点，如果从节点发生故障则会将该从节点剔除

哨兵功能：监视、选举主节点、通知

监控

哨兵会使用PING命令检测它自己和主从节点网络连接情况

监控主节点

对主节点监控需要引入哨兵集群，一般来说，当有N个节点，最好有N/2+1个实例Ping主节点超时就会判断该主节点下线

 

监控从节点

针对从节点，一般不用哨兵集群，简单的PING从节点超时就会认为该从节点下线

选举主节点

 哨兵从从节点选择主节点过程主要分两步：筛选和打分

筛选

筛选正常在线的从节点才可以有资格成为主节点

打分

分别按照三个规则依次进行三轮打分，这三个规则分别是从库优先级、从库复制进度以及从库 ID 号

 

哨兵集群有多个实例，那怎么确定由哪个哨兵来进行实际的主从切换呢？

任何一个实例只要自身判断主库“主观下线”后，就会给其他实例发送 is-master-down-by-addr 命令。接着，其他实例会根据自己和主库的连接情况，做出 Y 或 N 的响应，Y 相当于赞成票，N 相当于反对票。

一个哨兵获得了仲裁所需的赞成票数后，就可以标记主库为“客观下线”。这个所需的赞成票数是通过哨兵配置文件中的 quorum 配置项设定的。

     

　　此时，这个哨兵就可以再给其他哨兵发送命令，表明希望由自己来执行主从切换，并让所有其他哨兵进行投票。在投票过程中，任何一个想成为 Leader 的哨兵，要满足两个条件：第一，拿到半数以上的赞成票；第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。

哨兵模式缺点

哨兵模式下主节点还是单机，写操作无法做到负载均衡，以及由于是单机所以存储空间有限

集群模式

 Redis集群是一种分布式缓存解决方案，通过多节点协同工作实现高可用性、数据分片存储和负载均衡，核心特点包括

水平扩展：可以横向添加多个redis节点，存储容量增加

故障自愈：与哨兵模式类似，如果某个主节点发生故障从节点自动接替

去中心化架构：避免单点故障

集群模式架构图

 集群模式原理

集群中的hash槽

当客户端发来请求，Redis集群并没有采用一致性hash方式来决定使用哪个分片，而是采用了hash槽的概念

Redis集群有16384个hash槽，每个key通过校验CRC16后对16384取模来决定放在哪个槽位

 集群模式读写过程

 

 

参考文献：

https://juejin.cn/post/7426213075726090278

https://www.cnblogs.com/yangyixin/p/17436853.html