Redis主从同步原理

Redis主从同步原理

• 主从建立连接时第一次同步：全量同步

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

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

主节点如何判断从节点是第一次同步

第一阶段：建立连接后，
1.1携带Replication ld和offest给主节点
1.2去校验是否是第一次，以及是否需要同步
1.3如果是第一次，返回主节点的Replication ld和offest给从节点

全量同步流程

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

• slaver记录

29312:S 08 Jan 2022 18:01:32.915 * Connecting to MASTER 192.168.183.128:7001 # 连接到master
29312:S 08 Jan 2022 18:01:32.915 * MASTER <-> REPLICA sync started # 增量同步开始
29312:S 08 Jan 2022 18:01:32.915 * REPLICAOF 192.168.183.128:7001 enabled (user request from 'id=8 addr=127.0.0.1:34642 laddr=127.0.0.1:7002 fd=10 name= age=12 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=49 qbuf-free=40905 argv-mem=26 obl=0 oll=0 omem=0 tot-mem=61490 events=r cmd=slaveof user=default redir=-1')
29312:S 08 Jan 2022 18:01:32.915 * Non blocking connect for SYNC fired the event. # 异步事件开启
29312:S 08 Jan 2022 18:01:32.915 * Master replied to PING, replication can continue... # ping pong测试
29312:S 08 Jan 2022 18:01:32.915 * Trying a partial resynchronization (request c11a5b3d74b35ccae8305aad9861dda75b749a15:1). # 尝试增量(局部更新)
29312:S 08 Jan 2022 18:01:32.957 * Full resync from master: 248da2404d55443fa353d5ca30858eb3aba9cbdd:0 # master告知slaver全量更新并给与Replication Id、offerset
29312:S 08 Jan 2022 18:01:32.957 * Discarding previously cached master state. # 丢弃slaver缓存
29312:S 08 Jan 2022 18:01:33.058 * MASTER <-> REPLICA sync: receiving 175 bytes from master to disk # 接受到数据并保存磁盘
29312:S 08 Jan 2022 18:01:33.058 * MASTER <-> REPLICA sync: Flushing old data
29312:S 08 Jan 2022 18:01:33.058 * MASTER <-> REPLICA sync: Loading DB in memory # 读取到内存
29312:S 08 Jan 2022 18:01:33.059 * Loading RDB produced by version 6.2.4
29312:S 08 Jan 2022 18:01:33.059 * RDB age 1 seconds
29312:S 08 Jan 2022 18:01:33.059 * RDB memory usage when created 1.86 Mb
29312:S 08 Jan 2022 18:01:33.059 * MASTER <-> REPLICA sync: Finished with success # 成功

• master记录

20493:M 08 Jan 2022 17:41:43.577 * Ready to accept connections
# 7002请求同步
20493:M 08 Jan 2022 18:01:32.915 * Replica 192.168.183.128:7002 asks for synchronization

# 增量同步(局部)更新请求被拒绝, master要182c13fb1ca83481f74cf098ebe0b5ce08c7bc7a, slaver给的不一致
20493:M 08 Jan 2022 18:01:32.915 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'c11a5b3d74b35ccae8305aad9861dda75b749a15', my replication IDs are '182c13fb1ca83481f74cf098ebe0b5ce08c7bc7a' and '0000000000000000000000000000000000000000')

# backlog创建并更新replication ID、offset
20493:M 08 Jan 2022 18:01:32.916 * Replication backlog created, my new replication IDs are '248da2404d55443fa353d5ca30858eb3aba9cbdd' and '0000000000000000000000000000000000000000'

# 开始RDB持久化
20493:M 08 Jan 2022 18:01:32.916 * Starting BGSAVE for SYNC with target: disk
20493:M 08 Jan 2022 18:01:32.956 * Background saving started by pid 95356
95356:C 08 Jan 2022 18:01:32.958 * DB saved on disk # 保存到磁盘
95356:C 08 Jan 2022 18:01:32.959 * RDB: 4 MB of memory used by copy-on-write
20493:M 08 Jan 2022 18:01:33.058 * Background saving terminated with success
20493:M 08 Jan 2022 18:01:33.058 * Synchronization with replica 192.168.183.128:7002 succeeded # 同步成功

增量同步流程

• 如果是slave重启后同步是增量同步

repl_baklog大小有上限，写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于repl_baklog做增量同步，只能再次全量同步。

全量更新和增量更新的场景

• 全量更新

  1. 主从节点连接
  2. 从节点宕机过久，数据覆盖从节点记录repl_baklog offset位置

• 增量更新

  1. 从节点宕机不久后恢复，repl_baklog offset位置还未被覆盖

优化Redis主从集群

• 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘lO

repl-diskless-sync yes

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

从从节点设置主节点为从节点即可