Redis 主从架构数据同步

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)响应写命令时，不但会把命令发送给从节点，还会写入复制积压缓冲区

参考地址

• https://redis.io/docs/manual/replication/#partial-sync-after-restarts-and-failovers
• https://blog.csdn.net/iflink/article/details/122389644