难缠的Redis主从复制原理，这次通透了！

点击关注公众号，一周多次包邮送书

来源：经授权转自 Java技术指北（ID：javanorth）作者：指北君

今天来看一看面试中必问的 Redis 主从复制是什么?

主从复制

主从复制，将一台 Redis 服务器的数据，复制到其他 Redis 服务器。前者称为主（master）节点，后者称为从（slave）节点 。在默认的情况下，Redis 都是主节点，每个从节点只能有一个主节点，一个主节点可以有多个从节点并且复制的数据只能从主节点复制到从节点。

配置方式

1. 在从节点的配置文件中配置：slaveof {masterip} {masterport}
2. 在 redis-server 启动命令后加入：--slaveof {masterip} {masterport}
3. 在 redis 客户端使用命令：slaveof {masterip} {masterport}

建立主从关系

启动两个实例

//实例一：默认端口 6379
./redis-server

//实例二：修改端口为 6380
./redis-server --port 6380

结果如下图

master

salve

建立主从连接

// 把端口为 6380 的 redis-server 挂在 6379 的 redis-server 下
./redis-cli -p 6380
127.0.0.1:6380> slaveof 127.0.0.1 6379
OK

1. 主节点添加 key

127.0.0.1:6379} set masterKey 'This is master Key'
OK

1. 从节点查询 key

127.0.0.1:6380> get masterKey
"This is master Key"

可以发现主节点的 Key 已经同步到从节点了

1. 主节点删除 key

127.0.0.1:6379} del masterKey
(integer) 1

1. 从节点再次查询 key

127.0.0.1:6380> get masterKey
(nil)

可以发现从节点的 key 也已经被删除了

断开连接

通过 slaveof {masterip} {masterport} 命令建立主从复制关系以后，可以通过 slaveof no one 断开。从节点断开复制后，不会删除已有的数据，只是不再接受主节点新的数据变化。

使用命令 slaveof no one

127.0.0.1:6380> slaveof no one
OK

主从原理

在从节点执行 slaveof 命令后，主从复制的过程就开始了，可以分为 6 个步骤：

1. 保存主节点信息

//从节点的 redis-server 中日志
27604:S 21 Aug 22:38:56.934 * SLAVE OF 127.0.0.1:6379 enabled (user request from 'id=3 addr=127.0.0.1:60092 fd=8 name= age=69 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')

从上面的日志中可以看到 salveof 中的 masterhost 和 masterport 都被保存了下来。

1. 建立连接

//从节点的 redis-server 中日志
27604:S 21 Aug 22:38:57.444 * Connecting to MASTER 127.0.0.1:6379
27604:S 21 Aug 22:38:57.445 * MASTER {-} SLAVE sync started

从节点内部会使用一个每秒运行的定时任务，当发现了新的主节点后根据主节点的 host 和 port 建立一个 socket 连接。

当连接失败的时候定时任务会无限重试连接直到连接成功或者使用 slaveof on one 命令取消主从连接。

//从节点的 redis-server 中日志
27639:S 21 Aug 22:50:02.825 # Error condition on socket for SYNC: Connection refused

1. 发送 ping 命令

连接建立成功后从节点（salve）发送 ping 命令进行首次通信，主要目的是：

• 检查主从之间网络套接字是否可用
• 检查主节点当前是否可接受处理命令

从节点发送 ping 命令后会收到主节点的 pong 回复或者是超时问题，从节点便会断开连接，下次定时任务时再次发送 ping 命令

发送 PING 命令

1. 权限验证

如果主节点设置了 requierpass 参数，则从节点必须配置 masterauth 参数进行密码验证。

从节点会向主节点发送 auth 命令进行验证，auth 参数为 masterauth 参数的值。如果验证没通过从节点会断开连接，并重连

1. 从节点发送端口信息

身份验证之后，从节点会向主节点发送其监听的端口号，主节点将该信息保存到该从节点对应的客户端的 slave_listening_port 字段中

1. 数据同步

主从复制能正常通信后，首次建立连接后主节点会把全部数据发送给从节点，相当于从节点完成数据初始化工作。

同步的方式有全量同步和部分同步。

1. 命令复制

当主节点把所有数据复制给从节点后，主节点会把命令传输给从节点，从节点接收到命令后执行，以保证数据完整性

数据同步方式

Redis 数据同步方式有全量同步和部分同步，Redis 使用 psync 命令进行主从同步。

psync 命令需要以下组件支持：

• 主从节点各自复制偏移量
• 主节点复制积压缓冲区
• 主节点运行 id

复制偏移量

主节点和从节点都会维护自身复制偏移量（offset），主节点在处理完命令后，会将命令的字节长度做累加并记录，统计在 info replication 中的 master_repl_offset 中。

127.0.0.1:6379> info replication
# Replication
role:master
...
master_repl_offset:308

从节点在接收到主节点发送的命令后，同样累计记录自身的偏移量，统计在 info replication 中的 slave_repl_offset 中。

127.0.0.1:6380> info replication
# Replication
role:slave
...
slave_repl_offset:1050

从节点每秒钟把自身的复制偏移量上报给主节点，主节点会保存这个从节点的复制偏移量。记录在从节点对应的 ip，port 行的 offset 中

127.0.0.1:6379> info replication
# Replication
role:master
...
slave0:ip=127.0.0.1,port=6380,state=online,offset=308,lag=1

复制积压缓冲区

复制积压缓冲区是主服务器维护的一个固定长度，先进先出的队列，默认为 1M 大小。当主节点有连接的从节点时被创建，主节点将命令发送给从节点时，还会写入复制积压缓冲区，作为写命令的备份，并且会为队列里的每个字节记录相应的复制偏移量。

复制积压缓冲区的一些数据保存在 info replication 中

127.0.0.1:6379> info replication
# Replication
role:master
...
repl_backlog_active:1                   # 开启复制积压缓冲区
repl_backlog_size:1048576               # 缓冲区最大长度
repl_backlog_first_byte_offset:1        # 起始偏移量，计算当前缓冲区可用范围
repl_backlog_histlen:308                # 已保存数据的有效长度

主节点运行 ID

每个 Redis 节点在启动后都会动态分配一个唯一的 40 位十六进制字符串作为运行 ID（run_id）。当 Redis 重启后，运行 ID 也会改变。

127.0.0.1:6379> info server
# Server
...
run_id:9cc202d7825028c28e91207452e993de8cdb145c
tcp_port:6379
...

当主从节点第一次复制的时候，主节点会将 run_id 发送给从节点，从节点断线重新连接的时候，从节点将 run_id 发送给主节点，主节点和当前的自身的 run_id 判断是否需要全量复制。

1. 当从节点发送 run_id 和主节点当前的 run_id 不相同，说明从节点在断线前和断线后的主节点不相同，需要全量复制
2. 当从节点发送 run_id 和主节点当前的 run_id 相同，主节点根据复制偏移量和复制积压缓冲区判断是需要全量复制还是部分复制

psync 命令

从节点使用 psync {run_id} {offset}命令完成全量复制或者部分复制

1. run_id：从节点保存的主节点 run_id
2. offset：从节点的复制偏移量

psync 运行流程，来自《Redis 设计与实现》

从节点向主节点发送命令

• 从节点从未执行过 slaveof 或者最近一次执行了 slaveof no one，从节点向主节点发送 psync ? -1 请求全量复制。
• 从节点执行过 slaveof，从节点向主节点发送 psync {run_id} {offset}命令，主节点判断是否需要全量复制。

主节点判断是否需要全量复制

• 主节点根据 pysnc 参数和自身服务器状态，判断是全量复制还是部分复制
• 如果主节点的 Redis 版本小于 2.8，则返回+ERR，从节点发送重新 sync 命令触发全量复制
• 如果主节点的 run_id 和 psync 命令中 run_id 参数相同，且命令中的 offset 参数之后的数据都存在复制积压缓冲区，则返回+CONTINUE，从节点等待主节点的部分复制
• 如果主节点的 run_id 和 psync 命令中 run_id 参数不同，或者命令中的 offset 参数之后的数据有部分不再复制积压缓冲区中，则返回+FULLRESYNC {run_id} {offset}，从节点触发全量复制，并且保存主节点的 run_id 和 offset

心跳机制

主从复制建立之后，主从节点之间会维护两个心跳机制

心跳

PING

主节点向从节点默认每隔 10 秒发送 PING 命令，判断从节点是否存活和连接状态。配置参数 repl-ping-slave-period 可以控制 PING 命令的频率。

REPLCONF ACK

从节点向主节点默认每隔 1 秒发送 replconf ack {offset}命令。它的作用是：

1. 实时监测主从节点网络状态

127.0.0.1:6379> info replication
# Replication
role:master
...
slave0:ip=127.0.0.1,port=6380,state=online,offset=308,lag=1

在主节点的 info replication 中可以看到 lag=1，表示主节点上次收到 replconf ack 命令的间隔，正常情况下应该为 0 或者 1

1. 上报自身的偏移量

从节点上报自身偏移量判断是否丢失数据，主节点把自身的 offset 和从节点的 offset，如果从节点丢失数据，主节点会推送数据给从节点，如果从节点的 offset 之后的数据不在复制积压缓冲区中，则需要全量复制否则为部分复制。

1. 实现保证从节点的数量和延迟功能

主节点中使用 min-slaves-to-write（默认 3 个）和 min-slaves-max-lag（默认 10s）参数，保证从节点小于 3 个或所有从节点延迟大于 10 秒，主节点拒绝执行写命令。从节点的延迟数据是通过 replconf ack 命令的时间判断的，保存在 info replication 中的 lag 信息中。如果超过 repl-timeout（默认 60s）配置的值，则判断从节点下线并断开复制连接。

总结

简单的介绍了从如何建立连接到断开连接，从全量复制到部分复制的操作与原理。

参考文献

• [1] [Redis 设计与实现]
• [2] [Redis 开发与运维]

·················END·················

推荐阅读

👇更多内容请点击👇