【Redis】主从集群实现读写分离（二）

淡淡的烟草味﹌ 2024-03-26 19:32 76阅读 0赞

**目录**

2.Redis主从

2.1.搭建主从架构

2.2.主从数据同步原理

2.2.1.全量同步

2.2.2.增量同步

2.2.3.repl\_backlog原理

2.3.主从同步优化

2.4.小结

## 2.Redis主从 ##

### 2.1.搭建主从架构 ###

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

![0039458290904423842e51a748dc8014.png][]

### 2.2.主从数据同步原理 ###

#### 2.2.1.全量同步 ####

主从第一次建立连接时，会执行**全量同步**，将master节点的所有数据都拷贝给slave节点，流程：

![569a6e893ee345a09bc14d9c27711211.png][]

这里有一个问题，master如何得知salve是第一次来连接呢？？

有几个概念，可以作为判断依据：

*  **Replication Id**：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
 *  **offset**：偏移量，随着记录在repl\_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据。

因为slave原本也是一个master，有自己的replid和offset，当第一次变成slave，与master建立连接时，发送的replid和offset是自己的replid和offset。

master判断发现slave发送来的replid与自己的不一致，说明这是一个全新的slave，就知道要做全量同步了。

master会将自己的replid和offset都发送给这个slave，slave保存这些信息。以后slave的replid就与master一致了。

因此，**master判断一个节点是否是第一次同步的依据，就是看replid是否一致**。

如图：

![f3bc6040140e421ab9919b2821860870.png][]

完整流程描述：

*  slave节点请求增量同步
 *  master节点判断replid，发现不一致，拒绝增量同步
 *  master将完整内存数据生成RDB，发送RDB到slave
 *  slave清空本地数据，加载master的RDB
 *  master将RDB期间的命令记录在repl\_baklog，并持续将log中的命令发送给slave
 *  slave执行接收到的命令，保持与master之间的同步

#### 2.2.2.增量同步 ####

全量同步需要先做RDB，然后将RDB文件通过网络传输个slave，成本太高了。因此除了第一次做全量同步，其它大多数时候slave与master都是做**增量同步**。

什么是增量同步？就是只更新slave与master存在差异的部分数据。如图：

![4fc1ff9ccfa54e07acdcb3b5a82b4499.png][]

那么master怎么知道slave与自己的数据差异在哪里呢?

#### 2.2.3.repl\_backlog原理 ####

master怎么知道slave与自己的数据差异在哪里呢?

这就要说到全量同步时的repl\_baklog文件了。

这个文件是一个固定大小的数组，只不过数组是环形，也就是说**角标到达数组末尾后，会再次从0开始读写**，这样数组头部的数据就会被覆盖。

repl\_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset：

![1a5e52a32e87473e870080a46a87f406.png][]

slave与master的offset之间的差异，就是salve需要增量拷贝的数据了。

随着不断有数据写入，master的offset逐渐变大，slave也不断的拷贝，追赶master的offset：

![bb0e5b1f8f6a49338345697014c8f7ff.png][]

直到数组被填满：

![8788ce8cc2104d7ba02a1424bcc76b4d.png][]

此时，如果有新的数据写入，就会覆盖数组中的旧数据。不过，旧的数据只要是绿色的，说明是已经被同步到slave的数据，即便被覆盖了也没什么影响。因为未同步的仅仅是红色部分。

但是，如果slave出现网络阻塞，导致master的offset远远超过了slave的offset：

![c5d0cf8c0d864f8c87c92791aff7c927.png][]

如果master继续写入新数据，其offset就会覆盖旧的数据，直到将slave现在的offset也覆盖：

![17ffd3e582ee43278dabd12156370d62.png][]

棕色框中的红色部分，就是尚未同步，但是却已经被覆盖的数据。此时如果slave恢复，需要同步，却发现自己的offset都没有了，无法完成增量同步了。只能做全量同步。

![a32fa761debf4862b19ee976b06d55fc.png][]

### 2.3.主从同步优化 ###

主从同步可以保证主从数据的一致性，非常重要。

可以从以下几个方面来优化Redis主从就集群：

*  在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
 *  Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
 *  适当提高repl\_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
 *  限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

主从从架构图：

![079a808e2fa04ed4b7ab9db4e076adf9.png][]

### 2.4.小结 ###

简述全量同步和增量同步区别？

*  全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl\_baklog，逐个发送给slave。
 *  增量同步：slave提交自己的offset到master，master获取repl\_baklog中从offset之后的命令给slave

什么时候执行全量同步？

*  slave节点第一次连接master节点时
 *  slave节点断开时间太久，repl\_baklog中的offset已经被覆盖时

什么时候执行增量同步？

*  slave节点断开又恢复，并且在repl\_baklog中能找到offset时

[0039458290904423842e51a748dc8014.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/6de27d24c55742ed988a7c8cec9af78a.png
[569a6e893ee345a09bc14d9c27711211.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/41da248910f24cdc8c0b9ac23ea2002c.png
[f3bc6040140e421ab9919b2821860870.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/fe5f60c73d154a5b81add702de7a7b5d.png
[4fc1ff9ccfa54e07acdcb3b5a82b4499.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/817a9729af184ca3bd0ccbf6882a72d2.png
[1a5e52a32e87473e870080a46a87f406.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/5787b06866ed4fb0b5fcdc2ba78c44c7.png
[bb0e5b1f8f6a49338345697014c8f7ff.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/604cf87656894eccbaf4be6fa2458d10.png
[8788ce8cc2104d7ba02a1424bcc76b4d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/d07058df964b46a88c88117de5347463.png
[c5d0cf8c0d864f8c87c92791aff7c927.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/835fa36491bf4325a5a3e0292cd728f5.png
[17ffd3e582ee43278dabd12156370d62.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/1fb8b3d0bb8c48208f070499a0605d2e.png
[a32fa761debf4862b19ee976b06d55fc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/ecf2495df55647a48ce4fe267a6c27bb.png
[079a808e2fa04ed4b7ab9db4e076adf9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/d2bb807772e4490d88cc31e3fe7f68e9.png