Redis 主从架构数据同步

news/2024/4/29 20:40:34/文章来源:https://blog.csdn.net/qq_41956014/article/details/127610511

Redis 主从架构图

主从架构能够很大提升并发能力，master 节点负责写数据，slave 节点负责读数据，这样就涉及到 master 和 slave 数据同步的一个过程
一起来看一下数据是如何同步的吧
- redis 的主从同步机制可以确保 master 和 slave 之间的数据同步
- redis 在 2.8 及以上版本使用 psync 命令完成主从数据同步
- 同步方式：全量复制、增量复制

数据同步详细流程

全量同步

slave 第一次启动时，连接 master，发送 psync 命令，格式为 psync {runId} {offset}
- {runId} 为 master 的运行ID，{offset} 为 slave 自己的复制偏移量
- slave 第一次连接 master 时，slave 并不知道 master 的 runId，也不知道自己偏移量，这时候 slave 会传一个问号和 -1，告诉 master 节点是第一次同步，格式为 psync ? -1
当 master 接收到 psync ? -1 时，知道 slave 是要全量复制，就会将自己的 runId 和 offset 告知 slave，回复命令 fullresync {runId} {offset}，同时 master 会执行 bgsave 命令来生成 rdb 文件，期间的所有写命令将被写入缓冲区
- slave 接受到 master 的回复命令后，会保存 master 的 runId 和 offset，slave 此时处于同步状态
- slave 处于同步状态，如果此时收到请求，当配置参数 slave-server-stale-data yes 时，会响应当前请求，slave-server-stale-data no，返回错误
master bgsave 执行完毕，向 slave 发送 rdb 文件，rdb 文件发送完毕后，开始向 slave 发送缓冲区中的写命令
slave 收到 rdb 文件，丢弃所有旧数据，开始载入 rdb 文件
rdb 文件同步结束之后，slave 执行从 master 缓冲区发送过来的所以写命令
此后 master 每执行一个写命令，就向 slave 发送相同的写命令

增量同步

如果出现网络闪断或者命令丢失等异常情况时，当主从连接恢复后，由于从节点之前保存了自身己复制的
偏移量和主节点的运行ID。因此会把它们当作 psync 参数发送给主节点，要求进行部分复制操作，格式为 psync {runId} {offset}
主节点接到 psync 命令后首先核对参数 runld 是否与自身一致，如果一致，说明之前复制的是当前主节点，之后根据参数 offset 在自身复制积压缓冲区查找，如果偏移量之后的数据存在缓冲区中，则对从节点发送 +continue 响应，表示可以进行部分复制，否则进行全量复制
主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态

数据同步问题

同步超时问题

redis.conf 中的默认配置 repl-timeout 60，默认超时时间 60 秒
假设网卡带宽理论峰值大约每秒传输 100MB，在不考虑其他进程消耗带宽的情况下，6GB 的 RDB 文件至少需要 60 秒传输时间，默认配置下，很容易出现数据同步超时

积压缓冲区拷贝溢出

slave 节点从开始接收 RDB 文件到接收完成期间，主节点仍然响应读写命令，因此主节点会把这期间写入命令保存在复制积压缓冲区内，当从节点加载完 RDB 文件后，主节点再把缓冲区内的数据发送给从节点，保证主从之间数据一致性
如果主节点创建和传输 RDB 的时间过长，对于高流量写入场景非常容易造成主节点复制客户端缓冲区溢出，默认配置为 client-output-buffer-limit slave 256MB 64MB 60，如果 60 秒内缓冲区消耗持续大于 64MB 或者直接超过 256MB 时，主节点将直接关闭复制客户端连接，造成全量同步失败
运维人员需要根据主节点数据量和写命令并发量调整 client-output-buffer-limit slave 配置，避免全量复制期间客户端缓冲区溢出；对于主节点，当发送完所有的数据后就认为全量复制完成，打印成功日志：synchronization with slave127.0.0.1：6380 succeeded

slave全量同步的响应问题

slave 节点接收完主节点传送来的全部数据后会清空自身旧数据，执行 flash old data，然后加载 rdb 文件，对于较大的 rdb 文件，这一步操作依然比较耗时
对于线上做读写分离的场景，从节点也负责响应读命令，如果 slave 节点正出于全量复制阶段，那么 slave 节点在响应读命令可能拿到过期或错误的数据
对于这种场景，redis 复制提供了slave-server-stale-data yes 参数(默认开启)，如果开启则 slave 节点依然响应所有命令
对于无法容忍不一致的应用场景可以设置no 来关闭命令执行，此时从节点除了 info 和 slaveof 命令之外所有的命令只返回 sync with master in progress 信息

数据被清空问题

采用主从架构，建议开启 master 的持久化，不建议用 slave 节点作为 master 的数据备份，假设关掉 master 的持久化，可能在 master 宕机重启的时候数据是空的，然后可能一经过复制， slave 的数据也丢了
master 节点的备份文件需要各种备份，假设 master 本地的备份文件丢失、宕机， sentinel 还没检测到 master failure，master node 就自动重启，还是可能导致上面所有的 slave node 数据被清空

主从节点通讯

主从节点互相都会发送 heartbeat 信息
master 默认每隔 10 秒发送一次 heartbeat，slave node 每隔 1 秒发送一个 heartbeat

名词阐述

节点运行ID
- 每个 redis 节点启动后，都会动态分配一个 40 位的十六进制字符串作为运行id，即 {runId}，runId 主要用来唯一识别 redis 节点，比如从节点保存主节点的 runId 识别自己正在复制的是哪个主节点
- 如果只使用 ip + port 的方式识别主节点，那么主节点重启变更了，整体数据集(如替换rdb、aof文件)，从节点再基于偏移量复制数据将是不安全的，因此当 runId 变化后从节点将做全量复制
- 可以运行 info server 命令查看当前节点的 runId
偏移量拷贝
- 参与复制的主从节点都会维护自身复制偏移量，即 {offset}。
- 主节点(master) 在处理完写入命令后，会把命令的字节长度做累加记录，统计信息在 info relication中的 master_repl_offset 指标中
- 从节点(slave) 在接收到主节点发送的命令后，也会累加记录自身的偏移量，统计信息在 info relication 命令的 slave_repl_offset 指标中
- 从节点(slave) 每秒钟上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量
积压缓存区拷贝
- 存在于主节点(master)，默认大小为 1MB，可以通过参数 rel_backlog_size 来修改默认大小
- 复制积压缓冲区是保存在主节点上的一个固定长度的队列，当从节点(slave) 连接主节点时被创建，这时主节点(master)响应写命令时，不但会把命令发送给从节点，还会写入复制积压缓冲区