Redis特性解析-复制

Redis特性解析-复制

---

前言

redis复制原理介绍以及Redis2.8后复制升级

---

一、Redis复制有哪些？

1.同步

将从数据库更新到主数据库状态，从而实现从数据库和主数据库数据一致。

流程步骤：

1. 当从服务器首次连接或者收到用户的slaveof指令时，向主数据库发送SYN指令。
2. 主服务器收到从服务器发送过来的SYN指令，执行BGSAVE指令（新起后台线程全量备份），生成RDB备份文件，同时新建一个缓冲区记录从开始执行BGSAVE指令后的所有写命令。
3. 备份完成后，主服务器将这个RDB文件发送给从服务器，从服务器按照接收的RDB文件进行载入。
4. 主服务器将缓冲区中所有的写指令发送到从数据库，从而实现从数据库和主数据库的数据一致。

同步流程如下图所示：

2.命令传播

命令传播用于当主服务器的数据被修改时，主服务器会主动向从服务器发送相应的指令，从而保证主服务器和从服务器数据一致。

二、上诉复制方案存在问题

问题场景：当从服务器完成同步，处于命令传播阶段时，因为某种原因导致短时间的从数据库和主数据库断开连接，但之后从数据库自动重连上主数据库，这个时候如果按照原先的方案应该是怎样完成主数据库和从数据库的数据一致呢？

旧方案解决：由于从数据库在命令传播阶段断开连接，导致断开期间无法接收主数据库的写命令，这个时候按照原先的复制方案，就只能够重新进行同步，主数据库重新进行BGSAVE，发送RDB文件的方式来保证主从数据库的数据一致。

影响点：

1. 主数据库需重新进行RDB文件生成，占用大量的CPU和内存资源。
2. 主数据库将RDB文件发送给从数据库占用带宽。
3. 从数据库在重新加载RDB文件时，无法对外提供服务。

二、Redis2.8之后的改进

为了解决上述存在的问题，Redis2.8之后使用PSYNC取代了SYNC，PSYNC同样分为完整重同步和部分重同步，其中完整重同步和之前同步过程基本一致，主要看下部分重同步的升级：

1.部分重同步解决方案

新版实现的部分重同步主要针对断线重复制进行了优化，当从数据库断线重新连接主数据库时，在满足条件下，主数据库将从数据库断线期间的写命令发送给从数据库，从数据库只需要执行相应的写命令，就可以继续采用命令传播的方式保证数据的一致性，这样就避免了发送SYN指令，重新进行BGSAVE以及加载RDB文件等消耗资源的操作。

2.部分重同步实现原理

实现部分重同步主要依赖于以下三点

1. 主数据库和从数据库各自的复制偏移量
2. 主数据库的复制缓冲区
3. 服务器运行ID

重同步写过程

1. 在同步完成后，主从拥有一致的数据偏移量。
2. 每写入数据时，主从分别将自己的偏移量加上传输数据的字节数，这样说明如果从数据库和主数据库的偏移量一致，则数据一致。反之，则不一致。
3. 当某台从数据库断开重连后，向主数据库发送PSYNC指令。
4. 主数据库判断该从数据库之前同步的主数据库是否为自己（通过比较服务器运行ID）。
5. 若断开前后主数据库机器运行ID未修改，则比较主数据库的偏移量以及从数据库的偏移量。
6. 如果偏差的数据位移都处在主数据库的复制缓冲区中，则发送断开期间缺失的写命令,否则执行BGSAVE指令，完成全量的同步操作。

总结

感谢大家的阅读