redis主从复制详解

目录

前言：

分布式系统

主从模式

主从同步连接过程

replication id作用

offset作用

psync命令（psync replicationId offset)

全量复制

全量复制过程

部分复制

部分复制过程

实时复制

---

前言：

    redis为了保证高可用，它支持主从模式进行部署服务。可以引入更多硬件资源，提供高可用的服务器。主节点和从节点数据需要一致，那么在读数据就可以在服务器集群中任意选择一个节点进行读取。redis主从复制默认只能在主节点中修改数据，从节点是不可以修改的，也是为了保证主从节点数据的一致性。

分布式系统

    采用分布式模式部署redis服务，引入更多的硬件资源。

    1）可用性，某个节点服务挂了，还有其他节点可以代替。

    2）并发性，硬件资源多了，可处理的请求并发数也就多了。

主从模式

    一个主节点，多个从节点。主节点上的数据和从节点数据是同步的，可以认为从节点是主节点的副本。

    redis中的主从模式，从节点不允许修改数据，只可以在主节点上同步数据，主节点数据有任何修改都需要同步到从节点。写数据仍然是在主节点上写。

    那么读数据，主节点和从节点数据是一致的，都可以去读。写数据只可以在主节点上写，主节点还是有一定的压力。但通常情况下读操作数量远远大于写操作。（很好的解决了读并发的可用性和并发数的提高）

主从同步连接过程

注意：

1）通过配置文件保存主节点ip地址和端口号等一些信息。

2）通过TCP的三次握手进行连接。

3）验证主节点是否能正常工作。

4）redis可能会开启密码，在连接的时候就需要验证。

5）从节点连接到主节点进行数据同步，涉及全量同步和部分同步。

6）当从节点和主节点连接成功后，主节点还是会修改数据，那么就需要持续进行数据同步。

    redis提供了psync命令。用于完成数据同步过程。不需要手动执行，redis服务器在建立好主从同步关系后，自动执行。从节点负责执行psync同步主节点数据。

replication id作用

    主节点启动的时候就会生成，从节点晋升为主节点也会生成。（即使同一个主节点，每次重启，replication id都是不同的）。从节点和主节点建立了复制关系，就会从主节点这边获取到replication id。

    如果从节点认为主节点挂了，自己就会晋升为主节点，给自己生成一个replid（从节点主动断开）。此时这个节点也会记得之前主节点的replid，就是通过replid2。后续发现主节点可以正常通信了，就可以使用replid2来恢复之前的主从关系。（需要手动干预，哨兵机制可以自动完成这个过程）。

offset作用

1）主节点和从节点都会维护 偏移量（整数）。

2）主节点的偏移量，主节点会收到很多的修改命令（每个命令都要占据几个字节）。主节点会把这些修改命令，每个命令的字节数进行累加。

3）从节点偏移量就描述数据同步到哪里了。从节点每秒钟会上报自己的offset给主节点。

4）如果主节点和从节点offset一样，并且replication id也一致，说明主节点和从节点的数据完全一致。

psync命令（psync replicationId offset)

    从节点主动发起，用来从主节点同步数据。可能是全量复制，也可能是复制一部分数据（增量复制）

    offset如果为-1则是获取全量数据。如果是具体的整数，那么就从当前偏移量进行获取。

全量复制

    不是从节点索要哪部分数据，主节点就会给从节点哪部分数据。主节点会做一个判断，如果方便就给部分数据，如果不方便就是全量复制了。

全量复制时机：

    从节点首次和主节点进行数据同步

    主节点积压缓冲区不足以从节点缺失是数据（主节点积压缓冲区，和从节点断开连接后，数据保存位置）

部分复制时机：

    之前已经复制过一部分数据了，由于网络抖动，两者断开连接了。当从节点再次连接上之后。

全量复制过程

1）从节点发送psync命令给主节点进行数据同步，由于是第一次同步，从节点没有主节点replid和offset，所以发送psync ? -1进行全量复制。

2）主节点根据命令，解析出需要全量复制，回复+FULLRESYNC响应。

3）从节点接收主节点的运行信息进行保存。

4）主节点执行bgsave进行rdb文件持久化。

5）主节点发送rdb文件到从节点，从节点保存rdb文件到本地。

6）主节点将从生成rdb文件到从节点接收完成期间执行写命令，写入缓冲区。等从节点保存完rdb文件后，主节点再将缓冲区数据补发给从节点，补发的数据仍然按照rdb二进制格式追加到收到的rdb文件中，保持主从一致性。

7）从节点清空自身原有旧数据。

8）从节点加载rdb文件得到与主节点一致的数据。

9）如果从节点加载完成rdb文件后，并且开启了AOF持久化功能，它会进行bgrewrite操作，得到最近AOF文件。

部分复制

    之前已经复制过一部分数据了，由于网络抖动，两者断开连接了。当从节点再次连接上之后。

部分复制过程

1）从主从节点之间出现网络中断时，如果超过rep-timeout时间，主节点就会认为从节点出现故障并中断复制连接。

2）主从连接中断期间主节点仍然接收命令，但无法发送给从节点，所以暂时将这些命令保存在复制积压缓冲区中。

3）当主从节点网络恢复后，从节点再次连接上主节点。

4）从节点将之前保存的replid和offset作为psyns命令参数发送给主节点，请求进行部分复制。

5）主节点接收到psync请求后，进行必要验证，随后根据offset去复制积压缓冲区中查找合适的数据，并响应+CONTINUE给从节点进行部分复制。

6）主节点将从节点需要同步的数据发送给它，完成数据一致性操作。

replication id

    从节点再次连接主节点，首先进行replication id判断，如果和之前主节点保存的不一致，则进行全量复制。

    如果和之前保存的一致，然后再根据offset进行判断。

offet

    当从节点和主节点断开连接后，主节点会临时将数据保存到积压缓冲区中。通过offset进行判断，如果积压缓冲区可以满足从节点，则就部分复制了。

    如果积压缓冲去不能满足从节点缺失的数据，则只能全量复制了。

从节点和主节点断开：

    从节点和主节点主动断开。从节点就会升级为主节点（生成自己的replication id）

    主节点挂了。从节点不会升级为主节点，必须通过人工干预，恢复主节点。

注意：

    全量复制：从节点刚连接上主节点之后，进行的数据初始化工作。

    部分复制：特殊情况的处理方式，一种优化手段，毕竟全量复制操作比较重量。

实时复制

    当从节点和主节点数据已进同步完成，后续主节点还会收到修改数据的操作。主节点和从节点会使用tcp长连接，主节点将变化数据同步到从节点上。

注意：

    进行实时复制的时候需要保证连接处于可用状态，使用心跳包机制进行判定。

    主节点：默认，每隔10s给从节点发送一个ping命令，从节点收到后返回pong

    从节点：默认，每隔1s给从节点发送一个特定的请求，上报从节点的复制进度（offset）

注意：

    主从复制最大的问题还是在主节点上，如果主节点挂了，从节点就迷茫了。只能提供读操作，从节点不能自动升级为主节点，替换不了原来主节点角色。只能手动干预，改变拓扑结构。

    redis哨兵模式，可以自动对挂了的主节点进行替换。