动力节点最新Redis7笔记-第五章Redis主从集群

5 Redis主从集群

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

5.1 主从集群搭建

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

5.1.1 伪集群搭建与配置

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

5.1.1.1 复制redis.conf

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

5.1.1.2 修改redis.conf

在redis.conf中做如下几项修改：

5.1.1.2.1 masterauth

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

5.1.1.2.2 repl-disable-tcp-nodelay

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

| tcp-nodelay：为了充分复用网络带宽，TCP总是希望发送尽可能大的数据块。为了达到该目的，TCP中使用了一个名为Nagle的算法。
Nagle算法的工作原理是，网络在接收到要发送的数据后，并不直接发送，而是等待着数据量足够大（由TCP网络特性决定）时再一次性发送出去。这样，网络上传输的有效数据比例就得到了大大提升，无效数据传递量极大减少，于是就节省了网络带宽，缓解了网络压力。

tcp-nodelay则是TCP协议中Nagle算法的开头。

5.1.1.3 新建redis6380.conf

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

5.1.1.4 再复制出两个conf文件

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

修改redis6381.conf的内容如下：

修改redis6382.conf的内容如下：

5.1.1.5 启动三台Redis

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

5.1.1.6 设置主从关系

再打开三个会话框，分别使用客户端连接三台Redis。然后通过slaveof命令，指定6380的Redis为Master。

5.1.1.7 查看状态信息

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

5.1.2 分级管理

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

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

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

5.1.3 容灾冷处理

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

5.2 主从复制原理

5.2.1 主从复制过程

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

5.2.1.1 保存master地址

当slave接收到slaveof指令后，slave会立即将新的master的地址保存下来。