一文带你深入理解Redis的主从架构

发布时间：2024-04-05 15:26:26 来源：网络

.

Redis主从架构概述 Redis主从架构是一种分布式数据库架构，它包括一个主节点（Master）和一个或多个从节点（Slave）。主节点处理所有写操作，从节点

Redis主从架构概述

Redis主从架构是一种分布式数据库架构，它包括一个主节点（Master）和一个或多个从节点（Slave）。主节点处理所有写操作，从节点负责复制主节点的数据并处理读请求。以下是主从架构的核心组件：

主节点（Master）：

主节点是Redis集群的核心，负责处理所有写操作。
客户端连接到主节点，并向其发送写请求。
主节点将写操作同步到所有连接的从节点，以保持数据一致性。

从节点（Slave）：

从节点是主节点的复制品，其数据与主节点保持同步。
从节点可以处理读操作，但不允许进行写操作（只读）。
如果主节点不可用，可以将从节点提升为新的主节点。

主从同步步骤

具体步骤如下：

1、从节点根据自身状态，发送 psync命令给 master：

如果从实例从未执行过 replicaof ，则从节点发送 psync ? -1，代表全量，从 -1 处开始复制。
如果从节点之前执行过 replicaof，则取当前实例中记录下 runID和 offset，执行命令 psync <runID> <offset>, runID 是主节点 runID，offset 是复制偏移量。

2、主节点根据接收到的psync命令及当前服务器状态，决定执行全量复制还是部分复制：

对比主、从节点的 runID 一致，且从节点发送 slave_repl_offset 之后的数据在 repl_backlog_buffer缓冲区中均存在（队列是环形的，有可能被擦除重写了），则回复 CONTINUE，代表以追加模式进行部分复制。
runID 与从节点发送的 runID 不同，或者从节点发送的 slave_repl_offset 之后的数据已不在主节点的 repl_backlog_buffer缓冲区中 (因为队列是环形的，所以等待时间太长或者有断连的情况，有可能被擦除重写了)，则回复从节点 FULLRESYNC <runid> <offset>，表示要进行全量复制，同时记下主节点的 runID 和offset。日志如下：

repl_backlog_buffer：它是为了从库断开之后，如何找到主从差异数据而设计的环形缓冲区，从而避免全量复制带来的性能开销。如果从库断开时间太久，repl_backlog_buffer环形缓冲区被主库的写命令覆盖了，那么从库连上主库后只能乖乖地进行一次全量复制，所以repl_backlog_buffer配置尽量大一些，可以降低主从断开后全量复制的概率。而在repl_backlog_buffer中找主从差异的数据后，如何发给从库呢？这就用到了replication buffer。

replication buffer：Redis和客户端通信也好，和从库通信也好，Redis都需要给分配一个内存buffer进行数据交互，客户端是一个client，从库也是一个client，我们每个client连上Redis后，Redis都会分配一个client buffer，所有数据交互都是通过这个buffer进行的：Redis先把数据写到这个buffer中，然后再把buffer中的数据发到client socket中再通过网络发送出去，这样就完成了数据交互。所以主从在增量同步时，从库作为一个client，也会分配一个buffer，只不过这个buffer专门用来传播用户的写命令到从库，保证主从数据一致，我们通常把它叫做replication buffer。

repl_backlog_size环形缓冲区写满之后，从库是会丢失掉那部分被覆盖掉的数据，还是直接进行全量复制

一个从库如果和主库断连时间过长，造成它在主库repl_backlog_buffer的slave_repl_offset位置上的数据已经被覆盖掉了，此时从库和主库间将进行全量复制。
每个从库会记录自己的slave_repl_offset，每个从库的复制进度也不一定相同。在和主库重连进行恢复时，从库会通过psync命令把自己记录的slave_repl_offset发给主库，主库会根据从库各自的复制进度，来决定这个从库可以进行增量复制，还是全量复制。