Redis的几种高可用方案部署

一、主从复制

什么是主从复制模式

主从复制模式就是，部署多台redis节点，其中只有一台节点是主节点（master），其他的节点都是从节点（slave），也叫备份节点（replica）。只有master节点提供数据的事务性操作（增删改），slave节点只提供读操作。所有slave节点的数据都是从master节点同步过来的。该模式的架构图如下：

该图只是最简单的一种主从结构方式，所有的slave节点都挂在master节点上，这样做的好处是slave节点与master节点的数据延迟较小；缺点是如果slave节点数量很多，master同步一次数据的耗时就很长。针对这一问题，可以使用下图中的主从架构：

master下面只挂一个slave节点，其他的slave节点挂在这个slave节点下面，这样，master节点每次只需要把数据同步给它下面的那一个slave节点即可，后续slave节点的数据同步由这个slave节点完成。这样做虽然降低了master节点做数据同步的压力，但也导致slave节点与master节点数据不一致的延迟更高。

主从复制模式原理

从主从模式的架构图可以看出，主从模式的核心就是master节点与slave节点之间的数据同步。需要注意的是，Redis和大部分中间件的主从模式中的数据同步都是由slave节点主动发起的，原因是主从模式中只有一个master节点，剩余的全是slave节点，如果由master节点主动推送数据到各个slave节点，首先维护成本太大，master节点上要维护所有slave的地址信息，而且在增加slave节点的时候，也要同步维护到master上，这样master才能将数据同步到所有的slave上面；其次master性能受影响，节点之间同步数据肯定要通过网络传输数据，由master节点建立所有slave节点的连接会对master的性能产生较大影响。而由slave发起数据同步则避免了上述问题，只需在每个slave中维护一个master的地址即可。

Redis中主从节点数据同步有两种方式：全量数据同步和增量数据同步。

全量数据同步

全量数据同步一般发生在slave节点初始化阶段，需要将master上的所有数据全部复制过来。全量同步的流程图如下：

1. slave节点根据配置的master节点信息，连接上master节点，并向master节点发送SYNC命令；

2. master节点收到SYNC命令后，执行BGSAVE命令异步将内存数据生成到rdb快照文件中，同时将生成rdb文件期间所有的写命令记录到一个缓冲区，保证数据同步的完整性；

3. master节点的rdb快照文件生成完成后，将该rdb文件发送给slave节点；

4. slave节点收到rdb快照文件后，丢弃所有内存中的旧数据，并将rdb文件中的数据载入到内存中；

5. master节点将rdb快照文件发送完毕后，开始将缓冲区中的写命令发送给slave节点；

6. slave节点完成rdb文件数据的载入后，开始执行接收到的写命令。

以上就是master-slave全量同步的原理，执行完上述动作后，slave节点就可以接受来自用户的读请求，同时，master节点与slave节点进入命令传播阶段，在该阶段master节点会将自己执行的写命令发送给slave节点，slave节点接受并执行写命令，从而保证master节点与slave节点的数据一致性。

增量数据同步

Redis2.8版本之前，是不支持增量数据同步的，只支持全量同步。增量数据同步是指slave节点初始化完成后，master节点执行的写命令同步到slave节点的过程。该过程比较简单，master节点每执行一个写命令后就会将该命令发送给slave节点执行，从而达到数据同步的目的。

但有一点需要注意，当增量复制过程中发生了异常导致同步失败时，是要支持断点续传的，也就是在异常恢复之后，是要支持从上次断掉的地方继续同步的，而不是全量数据同步。这就需要在master节点和slave节点分别维护一个复制偏移量（offset），代表master向slave节点同步的字节数。master节点每次向slave节点发送N个字节后，master节点的offset增加N；slave节点每次接收到master节点发送过来的N个字节后，slave节点的offset增加N。master节点和slave节点的这两个偏移量分别保存在master_repl_offset和slave_repl_offset这两个字段中。

谋朝篡位

slaveof no one

 

主机断开后，从机如果想要当主机，可以使用 slaveof no one 进行“谋朝篡位”，从而变成主机。

但此时其他节点还是很“忠心”，依然认定之前的主机为主机，这样变成的主机是没有从机的，是个“孤家寡人”。

主机如果恢复，可以“平息叛乱”，之前的从机依旧认定它为主机。

改朝换代

 

前面的操作在实际场景中并不适用，因为我们希望的是主机断开后有从机作为主机，依旧实现主从复制。

所以在从机“谋朝篡位”后，还需要让剩余的从机“认主”，让他们都“归顺”于新的主机。

这样原来的主机恢复后就变成了“孤家寡人”。

以上的配置十分繁琐，任何一个环节出错都可能导致失败。

下一章节将介绍更加智能也是工作中常用的哨兵模式。

二、哨兵模式

概述

主从切换技术的操作是：当主机宕机后，需要手动把一台从机切换为主机。

这就需要人工干预，费事费力，还会造成一段时间内服务不可用。

这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

Redis 从 2.8 开始正式提供了 Sentinel（哨兵） 架构来解决这个问题。

它是“谋朝篡位”的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从机转换为主机。

哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程，它会独立运行。

Redis sentinel工作原理

在哨兵模式架构中，client端在首次访问Redis服务时，实际上访问的是哨兵（sentinel），sentinel会将自己监控的Redis实例的master节点信息返回给client端，client后续就会直接访问Redis的master节点，并不是每次都从哨兵处获取master节点的信息。

简单来说其原理是哨兵通过发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。

 

这里的哨兵有两个作用：

• 通过发送命令，让 Redis 服务器返回监控其运行状态，包括主机和从机。

• 当哨兵监测到 master 宕机，会自动将 slave 切换成 master，然后通过发布订阅模式通知其他的从机，修改配置文件，让它们切换主机。

然而一个哨兵进程对 Redis 服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。

各个哨兵之间还会进行监控，这样就形成了多哨兵模式（集群）：

 

Redis sentinel是如何进行监控的

要实现Redis节点的监控，sentinel首先要得到所有的Redis节点的信息。sentinel通过在配置文件中配置 sentinel monitor 选项来指定要监控的redis master节点的地址，然后在启动sentinel时，会创建与redis master节点的连接并向master节点发送一个info命令，master节点在收到info命令后，会将自身节点的信息和自己下面所有的slave节点的信息返回给sentinel，sentinel收到反馈后，会与新的slave节点创建连接，接下来就会每隔10秒钟向所有的redis节点发送info命令来获取最新的redis主从结构信息。

有了redis实例的主从信息后，sentinel就会以每秒钟一次的频率向所有redis实例发送一个PING命令，而且如果sentinel是集群部署的话，每个sentinel还会以同样的频率向其他sentinel实例发送PING命令。当redis实例和sentinel实例收到PING命令后，会向sentinel返回一个有效的回复：+PONG 、-LOADING 或者 -MASTERDOWN，若返回其他的回复，或者在指定时间内（sentinel down-after-milliseconds 选项配置）没有回复，那么sentinel认为实例的回复无效。如果实例在 sentinel down-after-milliseconds 时间内未返回过一次有效的回复，那该实例就会被sentinel标记为主观下线（Subjectively Down，简称 SDOWN，指的是单个 sentinel 实例对服务节点做出的下线判断）。

当redis master节点被足够数量（sentinel monitor 选项配置，其中的quorum即为指定的sentinel数量，下面会详细介绍相关参数）的sentinel标记为主观下线后，那么master节点就会被标记为客观下线（Objectively Down，简称 ODOWN，指的是多个 sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。【一个 sentinel 可以通过向另一个 sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线】）。客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例，sentinel 在将它们判断为下线前不需要进行协商， 所以slave服务器或者其他 sentinel 永远不会达到客观下线条件。

当redis master被标记为客观下线时，每个sentinel向其他slave节点发送info命令的频率由之前的10秒钟一次变为1秒钟一次。并且会通过raft算法在sentinel中选出一个leader，由leader节点完成redis的故障转移工作。

哨兵监控总结：

假设主机宕机，哨兵 1 先检测到这个结果，系统并不会马上进行 failover（故障转移） 过程，仅仅是哨兵 1 主观的认为主机不可用，这个现象称为主观下线。

当后面的哨兵也检测到主机不可用，并且数量达到一定值时，哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行 failover 操作。

切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从机实现切换主机，这个过程称为客观下线。

Redis sentinel选举redis-master的规则

如何从众多slave节点中选出一个作为master节点呢？redis文档中是这样描述sentinel选择新master的规则的：

三、Redis集群

百度安全验证https://baijiahao.baidu.com/s?id=1730440988136689035