详述Redis主从复制配置及原理

青旅半醒 2022-11-12 08:22 160阅读 0赞

**目录**

1.配置Redis主从复制 Redis版本：6.2.1

1.1 环境准备

1.2 修改从库redis.conf配置文件

2.Redis主从复制的三种机制

3.Redis主从复制涉及到的相关概念

4. Redis主从复制原理

5.Redis主从复制分析

6.主库关闭持久化对从库复制机制的安全性影响

--------------------

## 1.配置Redis主从复制 Redis版本：6.2.1 ##

###      1.1 环境准备 ###

准备两台安装好相同redis版本的linux服务器，对安装过程有疑问的小伙伴可以看我这篇博文：[Centos7.3安装Redis6.2.1][Centos7.3_Redis6.2.1]，然后在服务器开放防火墙6379端口（如果是阿里云记得在控制台配置6379端口开放规则）

###      1.2 修改从库redis.conf配置文件 ###

配置主库IP和端口，如果主库有密码把密码也配置上，老版本命令：

slaveof

新版本命令：

replicaof

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70][]

配置从库只读（默认为只读），老版本命令：

slave-read-only

新版本命令：

replica-read-only

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 1][]

重启从库redis服务，redis-cli连接用info replication指令查看连接状态：

info replication

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 2][]

可以看到角色已经改为从库且主库已连接

## 2.Redis主从复制的三种机制 ##

以下所有内容整理自官方文档：[https://redis.io/topics/replication][https_redis.io_topics_replication]

（1）当主库和从库连接良好时，主库通过向从库发送命令流来使从库数据保持更新（增量同步），命令流包含：客户端写入、密钥已过期和任何更改主数据集的操作。

（2）当主库和从库的连接断开时，可能由于网络问题在主库或从库实例中检测到超时，从库将尝试重新连接并进行部分数据的重新同步（增量同步）

（3）如果从库判断当前无法进行部分重新同步，则会进行完全重新同步。这将涉及一个复杂的过程，在该过程中主库需要创建其所有数据的快照，将其发送到从库，然后在数据集更改时继续发送命令流来完成同步操作。

总结：主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是：首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

注：如果出现多个Slave断连需要重启时，可能会导致可能会导致Master IO剧增宕机。因为只要Slave启动，就会发送sync请求和主机全量同步。

## 3.Redis主从复制涉及到的相关概念 ##

> psync：增量复制

Redis2.8提供了PSYNC命令来带代替SYNC（全量复制）命令，作用为用于从主发起复制流。PSYNC命令格式是：

PSYNC <runid> <offset>
    runid:主服务器ID
    offset:从服务器最后接收命令的偏移量

> replid：复制ID

每个Redis主数据库都有一个复制ID：它是一个大的伪随机字符串，用于标记数据集的历史记录。每次实例作为主服务器启动或将副本提升为主服务器时，都会为此实例生成一个新的复制ID。握手后，连接到主数据库的副本将继承其复制ID。因此，具有相同ID的两个实例通过以下事实相关联：它们拥有相同的数据，但可能在不同的时间。例如，如果两个实例A和B具有相同的复制ID，但是一个实例的偏移量为1000，另一个实例的偏移量为1023，则意味着第一个实例缺少应用于数据集的某些命令。这也意味着，仅通过应用一些命令，A即可达到与B完全相同的状态。

> offset：复制偏移量

在主从复制的Master和Slave双方都会各自维持一个offset。Master成功发送N个字节的命令后会将Master的offset加上N，Slave在接收到N个字节命令后同样会将Slave的offset增加N。Master和Slave如果状态是一致的那么它的的offset也应该是一致的。

> 复制积压缓冲区（repl\_back\_buffer）

复制积压缓冲区是由Master维护的一个固定长度的FIFO队列，它的作用是缓存已经传播出去的命令。当Master进行命令传播时，不仅将命令发送给所有Slave，还会将命令写入到复制积压缓冲区里。

## 4. Redis主从**复制原理** ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 3][]

主库和从库之间通过复制id进行匹配，避免slave挂到错误的master。Redis的复制方式分为**全量同步**和**增量同步**两种。

Redis在进行全量同步时，master会将内存数据通过bgsave指令存储到rdb文件中，同时将构建内存快照期间的写指令，存放到复制缓冲中，当 rdb 快照构建完毕后，master将rdb和复制缓冲队列中的数据全部发送给slave，slave完全重新创建一份数据。这个过程对master的性能损耗较大，slave构建数据的时间也比较长，而且传递rdb时还会占用大量带宽，对整个系统的性能和资源的访问影响都比较大。

而增量复制master只发送slave上次复制位置之后的写指令，不用构建rdb，而且传输内容非常有限，对 master、slave 的负荷影响很小，对带宽的影响可以忽略，整个系统受影响非常小。

在 Redis 2.8 之前，Redis 基本只支持全量复制。在 slave 与 master 断开连接，或 slave 重启后，都需要进行全量复制。在 2.8 版本之后，Redis 引入 psync，增加了一个复制积压缓冲，在将写指令同步给 slave 时，会同时在复制积压缓冲中也写一份。在 slave 短时断开重连后，上报master runid及复制偏移量。如果 runid 与 master 一致，且偏移量仍然在 master 的复制缓冲积压中，则 master 进行增量同步。但如果 slave 重启后，master runid 会丢失，或者切换 master后，runid 会变化，仍然需要全量同步。

因此 Redis自4.0强化了 psync，引入了 psync2。在 pysnc2 中，主从复制不再使用 runid，而使用 replid（即复制id） 来作为复制判断依据。同时 Redis 实例在构建 rdb 时，会将 replid 作为 aux 辅助信息存入 rbd。重启时，加载 rdb 时即可得到 master 的复制 id。从而在 slave 重启后仍然可以增量同步。在 psync2 中，Redis每个实例除了会有一个复制 id 即 replid 外，还有一个 replid2。Redis 启动后，会创建一个长度为 40 的随机字符串，作为 replid 的初值，在建立主从连接后，会用 master的 replid 替换自己的 replid。同时会用 replid2 存储上次 master 主库的 replid。这样切主时，即便 slave 汇报的复制 id 与新 master 的 replid 不同，但和新 master 的 replid2 相同，同时复制偏移仍然在复制积压缓冲区内，仍然可以实现增量复制。

## 5.Redis主从**复制**分析 ##

在设置 master、slave时，首先通过配置或者命令slaveof no one将节点设置为主库。然后其他各个从库节点，通过 slaveof master\_ip master\_port，将其他从库挂在到master上。同样方法，还可以将slave节点挂载到已有的slave节点上。在准备开始数据复制时，slave首先会主动与master创建连接，并上报信息。具体流程如下。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 4][]

slave创建与master的连接后，首先发送ping指令，如果master没有返回异常，而是返回pong，则说明master可用。如果Redis设置了密码，slave会发送 auth masterauth指令，进行鉴权。当鉴权完毕，从库就通过 replconf 发送自己的端

口及IP给master。

接下来，slave继续通过replconf发送capa eof capa psync2 进行复制版本校验。如果master校验成功。从库接下来就通过psync将自己的复制 id、复制偏移发送给master，正式开始准备数据同步。

主库接收到从库发来的psync指令后，则开始判断可以进行数据同步的方式。前面讲到Redis当前保存了复制id，replid和replid2。

如果从库发来的复制id，与master的复制id（即 replid 和 replid2）相同，并且复制偏移在复制缓冲积压中，则可以进行增量同步。master发送continue响应，并返回master的replid。slave将master的replid替换为自己的replid，并将之前的复制 id设置为replid2。之后，master则可继续发送，复制偏移位置之后的指令给slave，完成数据同步。

如果主库发现从库传来的复制id和自己的replid、replid2 都不同，或者复制偏移不在复制积压缓冲中，则判定需要进行全量复制。master发送fullresync响应，附带replid及复制偏移。然后master根据需要构建rdb，并将 rdb 及复制缓冲发送给 slave。

对于增量复制，slave接下来就等待接受master传来的复制缓冲及新增的写指令，进行数据同步。

而对于全量同步，slave会首先进行，嵌套复制的清理工作，比如 slave 当前还有嵌套的子slave，则该slave会关闭嵌套子slave 的所有连接，并清理自己的复制积压缓冲。然后，slave会构建临时 rdb 文件，并从master连接中读取rdb的实际数据，写入rdb 中。在写 rdb文件时，每写 8M，就会做一个fsync操作， 刷新文件缓冲。当接受rdb完毕则将rdb临时文件改名为rdb的真正名字。接下来，slave 会首先清空老数据，即删除本地所有DB中的数据，并暂时停止从master继续接受数据。然后slave 就开始全力加载 rdb 恢复数据，将数据从 rdb 加载到内存。在 rdb 加载完毕后，slave 重新利用与 master 的连接 socket，创建与 master 连接的 client，并在此注册读事件，可以开始接受master的写指令了。

此时，slave还会将master的replid和复制偏移设为自己的复制 id 和复制偏移 offset，并将自己的 replid2 清空，因为，slave 的所有嵌套子slave 接下来也需要进行全量复制。

最后，slave 就会打开 aof 文件，在接受 master 的写指令后，执行完毕并写入到自己的 aof 中。

相比之前的 sync，psync2 优化很明显。在短时间断开连接、slave 重启、切主等多种场景，只要延迟不太久，复制偏移仍然在复制积压缓冲，均可进行增量同步。master 不用构建并发送巨大的 rdb，可以大大减轻 master 的负荷和网络带宽的开销。同时，slave 可以通过轻量的增量复制，实现数据同步，快速恢复服务，减少系统抖动。但是，psync 依然严重依赖于复制缓冲积压，太大会占用过多内存，太小会导致频繁的全量复制。而且，由于内存限制，即便设置相对较大的复制缓冲区，在 slave 断开连接较久时，仍然很容易被复制缓冲积压冲刷，从而导致全量复制。

## 6.主库关闭持久化对从库复制机制的安全性影响 ##

在使用Redis复制时，我们强烈建议在主库和从库中开启持久化。如果实在不能开启持久化时，**不要将实例配置为出现故障后自动重启**。为了更好地理解为关闭持久化的主库配置自动重启是危险的，官方举了一个例子：

（1）假设有三个结点，其中节点A充当主节点，关闭持久化，节点B和C从节点A复制。

（2）当节点A崩溃重新启动进程时，因为其关闭了持久化机制，导致节点A将使用空数据集重新启动。

（3）节点B和结点C将从节点A复制，节点A为空，因此结点B和结点C最终会销毁其数据副本。

当将Redis Sentinel（哨兵）用于高可用性时，关闭主服务器上的持久性以及自动重启该过程也是很危险的。例如，主服务器可以足够快速地重新启动，以使Sentinel无法检测到故障，从而发生上述故障模式。

此文整理自：[https://redis.io/topics/replication][https_redis.io_topics_replication]

[https://www.bilibili.com/video/BV1oW411u75R][https_www.bilibili.com_video_BV1oW411u75R]

[https://zhuanlan.zhihu.com/p/96191405][https_zhuanlan.zhihu.com_p_96191405]

[https://blog.csdn.net/sk199048/article/details/50725369][https_blog.csdn.net_sk199048_article_details_50725369]

[http://blog.itpub.net/31545684/viewspace-2213629/][http_blog.itpub.net_31545684_viewspace-2213629]

[Centos7.3_Redis6.2.1]: https://blog.csdn.net/qq_36756682/article/details/115068778
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70]: /images/20221022/3e26e9ae059a446bb57822b9d03bb562.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 1]: /images/20221022/55ff119adfeb445597a5fd0a37f9b856.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 2]: /images/20221022/c43396f55788455cb842b61170a6bdfe.png
[https_redis.io_topics_replication]: https://redis.io/topics/replication
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 3]: /images/20221022/1f65d37e0619408c940f92c2cf468025.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzU2Njgy_size_16_color_FFFFFF_t_70 4]: /images/20221022/47ce7fbf949d4ccea454020bdb3f750c.png
[https_www.bilibili.com_video_BV1oW411u75R]: https://www.bilibili.com/video/BV1oW411u75R
[https_zhuanlan.zhihu.com_p_96191405]: https://zhuanlan.zhihu.com/p/96191405
[https_blog.csdn.net_sk199048_article_details_50725369]: https://blog.csdn.net/sk199048/article/details/50725369
[http_blog.itpub.net_31545684_viewspace-2213629]: http://blog.itpub.net/31545684/viewspace-2213629/