Redis主从集群

为了避免 Redis 的单点故障问题，我们可以搭建一个 Redis 集群，将数据备份到集群中的其它节点上。若一个 Redis 节点宕机，则由集群中的其它节点顶上。

1.1主从集群搭建

Redis 的主从集群是一个“一主多从”的读写分离集群。集群中的 Master 节点负责处理客户端的读写请求，而 Slave 节点仅能处理客户端的读请求。只所以要将集群搭建为读写分离模式，主要原因是，对于数据库集群，写操作压力一般都较小，压力大多数来自于读操作请求。所以，只有一个节点负责处理写操作请求即可。

1.1.1 伪集群搭建与配置

在采用单线程 IO 模型时，为了提高处理器的利用率，一般会在一个主机中安装多台 Redis，构建一个 Redis 主从伪集群。当然，搭建伪集群的另一个场景是，在学习 Redis，而学习用主机内存不足以创建多个虚拟机。
下面要搭建的读写分离伪集群包含一个 Master 与两个 Slave。它们的端口号分别是：6380、6381、6382。

（1） 复制 redis.conf
在 redis 安装目录中 mkdir 一个目录，名称随意。这里命名为 cluster。然后将 redis.conf文件复制到 cluster 目录中。该文件后面会被其它配置文件包含，所以该文件中需要设置每个 Redis 节点相同的公共的属性。

（2） 修改 redis.conf
在 redis.conf 中做如下几项修改：
A、masterauth

因为我们要搭建主从集群，且每个主机都有可能会是 Master，所以最好不要设置密码验证属性 requirepass。如果真需要设置，一定要每个主机的密码都设置为相同的。此时每个配置文件中都要设置两个完全相同的属性：requirepass 与 masterauth。其中 requirepass 用于指定当前主机的访问密码，而 masterauth 用于指定当前 slave 访问 master 时向 master 提交的访问密码，用于让 master 验证自己身份是否合法

B、 repl-disable-tcp-nodelay

该属性用于设置是否禁用 TCP 特性 tcp-nodelay。设置为 yes 则禁用 tcp-nodelay，此时master 与 slave 间的通信会产生延迟，但使用的 TCP 包数量会较少，占用的网络带宽会较小。相反，如果设置为 no，则网络延迟会变小，但使用的 TCP 包数量会较多，相应占用的网络带宽会大。

（3） 新建 redis6380.conf
新建一个 redis 配置文件 redis6380.conf，该配置文件中的 Redis 端口号为 6380。

（4） 再复制出两个 conf 文件
再使用 redis6380.conf 复制出两个 conf 文件：redis6381.conf 与 redis6382.conf。然后修改其中的内容。

修改 redis6381.conf 的内容如下：

修改 redis6382.conf 的内容如下：

（5） 启动三台 Redis
分别使用redis6380.conf、redis6381.conf与redis6382.conf 三个配置文件启动三台Redis。

（6） 设置主从关系
再打开三个会话框，分别使用客户端连接三台 Redis。然后通过 slaveof 命令，指定 6380的 Redis 为 Master。

（7） 查看状态信息
通过 info replication 命令可查看当前连接的 Redis 的状态信息。

1.1.2 分级管理

若 Redis 主从集群中的 Slave 较多时，它们的数据同步过程会对 Master 形成较大的性能压力。此时可以对这些 Slave 进行分级管理。

设置方式很简单，只需要让低级别 Slave 指定其 slaveof 的主机为其上一级 Slave 即可。
不过，上一级 Slave 的状态仍为 Slave，只不过，其是更上一级的 Slave。
例如，指定 6382 主机为 6381 主机的 Slave，而 6381 主机仍为真正的 Master 的 Slave。

此时会发现，Master 的 Slave 只有 6381 一个主机。

1.1.3 容灾冷处理

在 Master/Slave 的 Redis 集群中，若 Master 出现宕机怎么办呢？有两种处理方式，一种是通过手工角色调整，使 Slave 晋升为 Master 的冷处理；一种是使用哨兵模式，实现 Redis集群的高可用 HA，即热处理。
无论 Master 是否宕机，Slave 都可通过 slaveof no one 将自己由 Slave 晋升为 Master。如果其原本就有下一级的 Slave，那么，其就直接变为了这些 Slave 的真正的 Master 了。而原来的 Master 也会失去这个原来的 Slave。

1.2主从复制原理

1.2.1 主从复制过程

当一个 Redis 节点（slave 节点）接收到类似 slaveof 127.0.0.1 6380 的指令后直至其可以从 master 持续复制数据，大体经历了如下几个过程：

（1） 保存 master 地址
当 slave 接收到 slaveof 指令后，slave 会立即将新的 master 的地址保存下来。
（2） 建立连接
slave 中维护着一个定时任务，该定时任务会尝试着与该 master 建立 socket 连接。如果连接无法建立，则其会不断定时重试，直到连接成功或接收到 slaveof no one 指令。

（3） slave 发送 ping 命令
连接建立成功后，slave 会发送 ping 命令进行首次通信。如果 slave 没有收到 master 的回复，则 slave 会主动断开连接，下次的定时任务会重新尝试连接。
（4） 对 slave 身份验证
如果 master 收到了 slave 的 ping 命令，并不会立即对其进行回复，而是会先进行身份验证。如果验证失败，则会发送消息拒绝连接；如果验证成功，则向 slave 发送连接成功响应。

（5） master 持久化
首次通信成功后，slave 会向 master 发送数据同步请求。当 master 接收到请求后，会 fork出一个子进程，让子进程以异步方式立即进行持久化。

（6） 数据发送
持久化完毕后 master 会再 fork 出一个子进程，让该子进程以异步方式将数据发送给slave。slave 会将接收到的数据不断写入到本地的持久化文件中。

（7） slave 恢复内存数据
当 slave 与 master 的数据同步完成后，slave 就会读取本地的持久化文件，将其恢复到本地内存，然后就可以对外提供读服务了

1.2.2 数据同步演变过程

（1） sync 同步
Redis 2.8 版本之前，首次通信成功后，slave 会向 master 发送 sync 数据同步请求。然后master 就会将其所有数据全部发送给 slave，由 slave 保存到其本地的持久化文件中。这个过程称为全量复制。
但这里存在一个问题：在全量复制过程中可能会出现由于网络抖动而导致复制过程中断。当网络恢复后，slave 与 master 重新连接成功，此时 slave 会重新发送 sync 请求，然后会从头开始全量复制。
由于全量复制过程非常耗时，所以期间出现网络抖动的概率很高。而中断后的从头开始不仅需要消耗大量的系统资源、网络带宽，而且可能会出现长时间无法完成全量复制的情况。
（2） psync 同步
Redis 2.8 版本之后，全量复制采用了 psync（Partial Sync，不完全同步）同步策略。当全量复制过程出现由于网络抖动而导致复制过程中断时，当重新连接成功后，复制过程可以“断点续传”。即从断开位置开始继续复制，而不用从头再来。这就大大提升了性能。
为了实现 psync，整个系统做了三个大的变化：

A、复制偏移量
系统为每个要传送数据进行了编号，该编号从 0 开始，每个字节一个编号。该编号称为复制偏移量。参与复制的主从节点都会维护该复制偏移量

master 每发送过一个字节数据后就会进行累计。统计信息通过 info replication 的master_repl_offset 可查看到。同时，slave 会定时向 master 上报其自身已完成的复制偏移量给 master，所以 master 也会保存 slave 的复制偏移量 offset。

slave在接收到master的数据后，也会累计接收到的偏移量。统计信息通过info replication的 slave_repl_offset 可查看到。

B、 主节点复制 ID
当 master 启动后就会动态生成一个长度为 40 位的 16 进制字符串作为当前 master 的复制 ID，该 ID 是在进行数据同步时 slave 识别 master 使用的。通过 info replication 的master_replid 属性可查看到该 ID。

C、 复制积压缓冲区
当 master 有连接的 slave 时，在 master 中就会创建并维护一个队列 backlog，默认大小为 1MB，该队列称为复制积压缓冲区。master 接收到了写操作数据不仅会写入到 master 主存，写入到 master 中为每个 slave 配置的发送缓存，而且还会写入到复制积压缓冲区。其作用就是用于保存最近操作的数据，以备“断点续传”时做数据补偿，防止数据丢失。

2.1 哨兵机制实现

2.1.1 简介

对于 Master 宕机后的冷处理方式是无法实现高可用的。Redis 从 2.6 版本开始提供了高可用的解决方案—— Sentinel 哨兵机制。在集群中再引入一个节点，该节点充当 Sentinel 哨兵，用于监视 Master 的运行状态，并在 Master 宕机后自动指定一个 Slave 作为新的 Master。整个过程无需人工参与，完全由哨兵自动完成。

不过，此时的 Sentinel 哨兵又成为了一个单点故障点：若哨兵发生宕机，整个集群将瘫痪。所以为了解决 Sentinel 的单点问题，又要为 Sentinel 创建一个集群，即 Sentinel 哨兵集群。一个哨兵的宕机，将不会影响到 Redis 集群的运行。

那么这些 Sentinel 哨兵是如何工作的呢？Sentinel 是如何知道其监视的 Master 状态的呢？每个 Sentinel 都会定时会向 Master 发送心跳，如果 Master 在有效时间内向它们都进行了响应，则说明 Master 是“活着的”。如果 Sentinel 中有 quorum 个哨兵没有收到响应，那么就认为 Master 已经宕机，然后会有一个 Sentinel 做 Failover 故障转移。即将原来的某一个 Slave晋升为 Master。

2.2.2 Redis 高可用集群搭建

在“不差钱”的情况下，可以让 Sentinel 占用独立的主机，即在 Redis 主机上只启动 Redis进程，在 Sentinel 主机上只启动 Sentinel 进程。下面要搭建一个“一主二从三哨兵”的高可用伪集群，即这些角色全部安装运行在一台主机上。“一主二从”使用前面的主从集群，下面仅搭建一个 Sentinel 伪集群。

（1） 复制 sentinel.conf
将 Redis 安装目录中的 sentinel.conf 文件复制到 cluster 目录中。该配置文件中用于存放一些 sentinel 集群中的一些公共配置。

（2） 修改 sentinel.conf
修改 cluster/sentinel.conf 配置文件。
A、sentinel monitor

该配置用于指定 Sentinel 要监控的 master 是谁，并为 master 起了一个名字。该名字在后面很多配置中都会使用。同时指定 Sentinel 集群中决定该master“客观下线状态”判断的法定 sentinel 数量。的另一个用途与sentinel 的 Leader 选举有关。要求中至少要有 max(quorum, sentinelNum/2+1)个 sentinel 参与，选举才能进行。
这里将该配置注释掉，因为要在后面的其它配置文件中设置，如果不注释就会出现配置冲突。

B、 sentinel auth-pass

如果 Redis 主从集群中的主机设置了访问密码，那么该属性就需要指定 master 的主机名与访问密码。以方便 sentinel 监控 master。

（3） 新建 sentinel26380.conf
在 Redis 安装目录下的 cluster 目录中新建 sentinel26380.conf 文件作为 Sentinel 的配置文件，并在其中键入如下内容：

sentinel monitor 属性用于指定当前监控的 master 的 IP 与 Port，同时为集群中 master 指定一个名称 mymaster，以方便其它属性使用。
最后的 2 是参数 quorum 的值，quorum 有两个用途。一个是只有当quorum 个 sentinel都认为当前 master 宕机了才能开启故障转移。另一个用途与 sentinel 的 Leader 选举有关。
要求中至少要有 max(quorum, sentinelNum/2+1)个 sentinel 参与，选举才能进行。

（4） 再复制两个 conf 文件

再使用sentinel26380.conf 复制出两个conf文件：sentinel26381.conf与sentinel26382.conf。然后修改其中的内容。
修改 sentinel26381.conf。

修改 sentinel26382.conf

2.2.3 Redis 高可用集群的启动

（1） 启动并关联 Redis 集群
首先要启动三台 Redis，然后再通过 slaveof 关联它们。

（2） 启动 Sentinel 集群

A、启动命令
在/usr/local/bin 目录下有一个命令 redis-sentinel 用于启动 Sentinel。不过，我们发现一个奇怪的现象：/usr/local/bin 目录中的 redis-sentinel 命令是 redis-server 命令的软链接，这是为什么呢？

查看 Redis 安装目录中的 src 目录中的 redis-server 与 redis-sentinel 命令，我们发现这两个命令的大小一模一样。其实，这两个命令本质上是同一个命令。

只所以可以启动不同的进程，主要是因为在启动时所加载的配置文件的不同。所以在启动 Sentinel 时，需要指定 sentinel.conf 配置文件。

B、 两种启动方式
由于 redis-server 与 redis-sentinel 命令本质上是同一个命令，所以使用这两个命令均可启动 Sentinel。

• 方式一，使用 redis-sentinel 命令：redis-sentinel sentinel26380.conf
• 方式二，使用 redis-server 命令：redis-server sentinel26380.conf --sentinel

C、 启动三台 Sentinel


（3） 查看 Sentinel 信息

运行中的 Sentinel 就是一个特殊 Redis，其也可以通过客户端连接，然后通过 info sentinel来查看当前连接的 Sentinel 的信息

（4） 查看 sentinel 配置文件
打开任意 sentinel 的配置文件，发现其配置内容中新增加了很多配置。

2.2.4 Sentinel 优化配置

在公共的 sentinel.conf 文件中，还可以通过修改一些其它属性的值来达到对 Sentinel 的配置优化。
（1） sentinel down-after-milliseconds

每个 Sentinel 会通过定期发送 ping 命令来判断 master、slave 及其它 Sentinel 是否存活。
如果 Sentinel 在该属性指定的时间内没有收到它们的响应，那么该 Sentinel 就会主观认为该主机宕机。默认为 30 秒。

（2） sentinel parallel-syncs

该属性用于指定，在故障转移期间，即老的 master 出现问题，新的 master 刚晋升后，允许多少个 slave 同时从新 master 进行数据同步。默认值为 1 表示所有 slave 逐个从新 master进行数据同步

（3） sentinel failover-timeout

指定故障转移的超时时间，默认时间为 3 分钟。该超时时间的用途很多：

• 由于第一次故障转移失败，在同一个 master 上进行第二次故障转移尝试的时间为该failover-timeout 的两倍
• 新 master 晋升完毕，slave 从老 master 强制转到新 master 进行数据同步的时间阈值。
• 取消正在进行的故障转换所需的时间阈值。
• 新 master 晋升完毕，所有 replicas 的配置文件更新为新 master 的时间阈值。

（4） sentinel deny-scripts-reconfig

指定是否可以通过命令 sentinel set 动态修改 notification-script 与 client-reconfig-script 两个脚本。默认是不能的。这两个脚本如果允许动态修改，可能会引发安全问题。

（5） 动态修改配置

通过 redis-cli 连接上 Sentinel 后，通过 sentinel set 命令可动态修改配置信息。例如，下面的命令动态修改了 sentinel monitor 中的 quorum 的值。
下表是 sentinel set 命令支持的参数：

3.1 哨兵机制原理

3.1.1 三个定时任务

Sentinel 维护着三个定时任务以监测 Redis 节点及其它 Sentinel 节点的状态。

（1） info 任务
每个 Sentinel 节点每 10 秒就会向 Redis 集群中的每个节点发送 info 命令，以获得最新的Redis 拓扑结构。
（2） 心跳任务
每个Sentinel节点每1秒就会向所有Redis节点及其它Sentinel节点发送一条ping命令，以检测这些节点的存活状态。该任务是判断节点在线状态的重要依据。
（3） 发布/订阅任务
每个 Sentinel 节点在启动时都会向所有 Redis 节点订阅_ sentinel :hello 主题的信息，当 Redis 节点中该主题的信息发生了变化，就会立即通知到所有订阅者。
启动后，每个 Sentinel 节点每 2 秒就会向每个 Redis 节点发布一条 sentinel _:hello 主题的信息，该信息是当前 Sentinel 对每个 Redis 节点在线状态的判断结果及当前 Sentinel 节点信息。

当 Sentinel 节点接收到_ sentinel _:hello 主题信息后，就会读取并解析这些信息，然后
主要完成以下三项工作：
 如果发现有新的 Sentinel 节点加入，则记录下新加入 Sentinel 节点信息，并与其建立连接。
 如果发现有 Sentinel Leader 选举的选票信息，则执行 Leader 选举过程。
 汇总其它 Sentinel 节点对当前 Redis 节点在线状态的判断结果，作为 Redis 节点客观下线的判断依据。

3.1.2 Redis 节点下线判断

对于每个 Redis 节点在线状态的监控是由 Sentinel 完成的。

（1） 主观下线
每个 Sentinel 节点每秒就会向每个 Redis 节点发送 ping 心跳检测，如果 Sentinel 在down-after-milliseconds 时间内没有收到某 Redis 节点的回复，则 Sentinel 节点就会对该 Redis节点做出“下线状态”的判断。这个判断仅仅是当前 Sentinel 节点的“一家之言”，所以称为主观下线。

（2） 客观下线
当 Sentinel 主观下线的节点是 master 时，该 Sentinel 节点会向每个其它 Sentinel 节点发送 sentinel is-master-down-by-addr 命令，以询问其对 master 在线状态的判断结果。这些Sentinel 节点在收到命令后会向这个发问 Sentinel 节点响应 0（在线）或 1（下线）。当 Sentinel收到超过 quorum 个下线判断后，就会对 master 做出客观下线判断