redis(5)-复制

在分布式系统中为了解决单点问题， 通常会把数据复制多个副本部署到其他机器， 满足故障恢复和负载均衡等需求。 Redis也是如此， 它为我们提供了复制功能， 实现了相同数据的多个Redis副本。 复制功能是高可用Redis的基础， 后面章节的哨兵和集群都是在复制的基础上实现高可用的。 复制也
是Redis日常运维的常见维护点。 因此深刻理解复制的工作原理与使用技巧对我们日常开发运维非常有帮助。

建立复制
参与复制的Redis实例划分为主节点（master） 和从节点（slave） 。 默认情况下， Redis都是主节点。 每个从节点只能有一个主节点， 而主节点可以同时具有多个从节点。 复制的数据流是单向的， 只能由主节点复制到从节点。

配置主从方式

1） 在配置文件中加入slaveof{masterHost}{masterPort}随Redis启动生效。
2） 在redis-server启动命令后加入–slaveof{masterHost}{masterPort}生效。
3） 直接使用命令： slaveof{masterHost}{masterPort}生效。

断开复制
slaveof命令不但可以建立复制， 还可以在从节点执行slaveof no one来断开与主节点复制关系
断开复制主要流程：
1） 断开与主节点复制关系。
2） 从节点晋升为主节点。
从节点断开复制后并不会抛弃原有数据， 只是无法再获取主节点上的数据变化。

安全性
对于数据比较重要的节点， 主节点会通过设置requirepass参数进行密码验证， 这时所有的客户端访问必须使用auth命令实行校验。 从节点与主节点的复制连接是通过一个特殊标识的客户端来完成， 因此需要配置从节点的masterauth参数与主节点密码保持一致， 这样从节点才可以正确地连接到主
节点并发起复制流程。

只读
默认情况下， 从节点使用slave-read-only=yes配置为只读模式。 由于复制只能从主节点到从节点， 对于从节点的任何修改主节点都无法感知， 修改从节点会造成主从数据不一致。 因此建议线上不要修改从节点的只读模式。

传输延迟
主从节点一般部署在不同机器上， 复制时的网络延迟就成为需要考虑的问题， Redis为我们提供了repl-disable-tcp-nodelay参数用于控制是否关闭TCP_NODELAY， 默认关闭， 说明如下：
·当关闭时， 主节点产生的命令数据无论大小都会及时地发送给从节点， 这样主从之间延迟会变小， 但增加了网络带宽的消耗。 适用于主从之间的网络环境良好的场景， 如同机架或同机房部署。
·当开启时， 主节点会合并较小的TCP数据包从而节省带宽。 默认发送时间间隔取决于Linux的内核， 一般默认为40毫秒。 这种配置节省了带宽但增大主从之间的延迟。 适用于主从网络环境复杂或带宽紧张的场景， 如跨机房部署。

拓扑
Redis的复制拓扑结构可以支持单层或多层复制关系， 根据拓扑复杂性可以分为以下三种： 一主一从、 一主多从、 树状主从结构。

一主一从
最简单的结构，当主节点宕机的时候，从节点可以提供故障转移支持。当写命令并发高而且需要持久化时，可以关闭主节点的持久化而开启从节点的aof，这样就保证了数据的安全性(开启持久化)也避免了因为持久化而导致主节点的性能降低。需要注意的是当主节点没有开启持久化，并且宕机需要重启时。首先要断开与从节点的主从关系。因为如果不断开，当主节点重启，并且没有持久化文件时。主节点没有数据额并且因为主从关系而清空从节点的数据。安全的做法是在从节点上执行slaveof no one断开与主节点的复制关系， 再重启主节点。

一主多从结构

一主多从结构（又称为星形拓扑结构） 使得应用端可以利用多个从节点实现读写分离 。 对于读占比较大的场景， 可以把读命令发送到从节点来分担主节点压力。 同时在日常开发中如果需要执行一些比较耗时的读命令， 如： keys、 sort等， 可以在其中一台从节点上执行， 防止慢查询对主节点造成阻塞从而影响线上服务的稳定性。 对于写并发量较高的场景， 多个从节点会导致主节点写命令的多次发送从而过度消耗网络带宽， 同时也加重了主节点的负载影响服务稳定性。适合多读少些的情景。

树状主从结构

树状主从结构（又称为树状拓扑结构） 使得从节点不但可以复制主节点数据， 同时可以作为其他从节点的主节点继续向下层复制。 通过引入复制中间层， 可以有效降低主节点负载和需要传送给从节点的数据量。 如图所示， 数据写入节点A后会同步到B和C节点， B节点再把数据同步到D和E节
点， 数据实现了一层一层的向下复制。 当主节点需要挂载多个从节点时为了避免对主节点的性能干扰， 可以采用树状主从结构降低主节点压力。

复制过程
在从节点执行slaveof命令后， 复制过程便开始运作， 下面详细介绍建立复制的完整流程。

1） 保存主节点（master） 信息。

2） 从节点（slave） 内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后， 会尝试与该节点建立网络连接。
从节点会建立一个socket套接字， 例如中从节点建立了一个端口为24555的套接字， 专门用于接受主节点发送的复制命令。从节点连接成功后打印如下日志。
*Connecting to MASTER 127.0.0.1:6379
*MASTER <-> SLAVE sync started
如果从节点无法建立连接， 定时任务会无限重试直到连接成功或者执行slaveof no one取消复制。
关于连接失败， 可以在从节点执行info replication查看master_link_down_since_seconds指标， 它会记录与主节点连接失败的系统时间。 从节点连接主节点失败时也会每秒打印如下日志， 方便运维人员发现问题：
Error condition on socket for SYNC: {socket_error_reason}

3） 发送ping命令。
连接建立成功后从节点发送ping请求进行首次通信， ping请求主要目的如下：
·检测主从之间网络套接字是否可用。
·检测主节点当前是否可接受处理命令。
如果发送ping命令后， 从节点没有收到主节点的pong回复或者超时， 比如网络超时或者主节点正在阻塞无法响应命令， 从节点会断开复制连接， 下次定时任务会发起重连。

从节点发送的ping命令成功返回， Redis打印如下日志， 并继续后续复制流程

4） 权限验证。 如果主节点设置了requirepass参数， 则需要密码验证，从节点必须配置masterauth参数保证与主节点相同的密码才能通过验证； 如果验证失败复制将终止， 从节点重新发起复制流程

5） 同步数据集。 主从复制连接正常通信后， 对于首次建立复制的场景， 主节点会把持有的数据全部发送给从节点， 这部分操作是耗时最长的步骤。 Redis在2.8版本以后采用新复制命令psync进行数据同步， 原来的sync命令依然支持， 保证新旧版本的兼容性。 新版同步划分两种情况： 全量同步和
部分同步。

6） 命令持续复制。 当主节点把当前的数据同步给从节点后， 便完成了复制的建立流程。 接下来主节点会持续地把写命令发送给从节点， 保证主从数据一致性。

数据同步
Redis在2.8及以上版本使用psync命令完成主从数据同步， 同步过程分为： 全量复制和部分复制。

·全量复制： 一般用于初次复制场景， Redis早期支持的复制功能只有全量复制， 它会把主节点全部数据一次性发送给从节点， 当数据量较大时， 会对主从节点和网络造成很大的开销。

·部分复制： 用于处理在主从复制中因网络闪断等原因造成的数据丢失场景， 当从节点再次连上主节点后， 如果条件允许， 主节点会补发丢失数据给从节点。 因为补发的数据远远小于全量数据， 可以有效避免全量复制的过高开销。

部分复制是对老版复制的重大优化， 有效避免了不必要的全量复制操作。 因此当使用复制功能时， 尽量采用2.8以上版本的Redis。
psync命令运行需要以下组件支持：
·主从节点各自复制偏移量。
·主节点复制积压缓冲区。
·主节点运行id。

1.复制偏移量

参与复制的主从节点都会维护自身复制偏移量。 主节点（master） 在处理完写入命令后， 会把命令的字节长度做累加记录， 统计信息在inforelication中的master_repl_offset指标中。

从节点（slave） 每秒钟上报自身的复制偏移量给主节点， 因此主节点也会保存从节点的复制偏移量。

从节点在接收到主节点发送的命令后， 也会累加记录自身的偏移量。 统计信息在info relication中的slave_repl_offset指标中。

通过对比主从节点的复制偏移量， 可以判断主从节点数据是否一致。

2.复制积压缓冲区

复制积压缓冲区是保存在主节点上的一个固定长度的队列， 默认大小为1MB， 当主节点有连接的从节点（slave） 时被创建， 这时主节点（master）响应写命令时， 不但会把命令发送给从节点， 还会写入复制积压缓冲区。

由于缓冲区本质上是先进先出的定长队列， 所以能实现保存最近已复制数据的功能， 用于部分复制和复制命令丢失的数据补救。 复制缓冲区相关统计信息保存在主节点的info replication中。

根据统计指标， 可算出复制积压缓冲区内的可用偏移量范围：[repl_backlog_first_byte_offset，
repl_backlog_first_byte_offset+repl_backlog_histlen]。

3.主节点运行ID

每个Redis节点启动后都会动态分配一个40位的十六进制字符串作为运行ID。 运行ID的主要作用是用来唯一识别Redis节点， 比如从节点保存主节点的运行ID识别自己正在复制的是哪个主节点。 如果只使用ip+port的方式识别主节点， 那么主节点重启变更了整体数据集（如替换RDB/AOF文件） ，从节点再基于偏移量复制数据将是不安全的， 因此当运行ID变化后从节点将做全量复制。 可以运行info server命令查看当前节点的运行ID。需要注意的是Redis关闭再启动后， 运行ID会随之改变。

当需要调优一些内存相关配置， 例如： hash-max-ziplist-value等， 这些配置需要Redis重新加载才能优化已存在的数据， 这时可以使用debug reload命令重新加载RDB并保持运行ID不变， 从而有效避免不必要的全量复制。

4.psync命令

从节点使用psync命令完成部分复制和全量复制功能， 命令格式：psync{runId}{offset}， 参数含义如下：
·runId： 从节点所复制主节点的运行id。
·offset： 当前从节点已复制的数据偏移量。

流程说明：
1） 从节点（slave） 发送psync命令给主节点， 参数runId是当前从节点保存的主节点运行ID， 如果没有则默认值为， 参数offset是当前从节点保存的复制偏移量， 如果是第一次参与复制则默认值为-1。
2） 主节点（master） 根据psync参数和自身数据情况决定响应结果：
·如果回复+FULLRESYNC{runId}{offset}， 那么从节点将触发全量复制流程。
·如果回复+CONTINUE， 从节点将触发部分复制流程。
·如果回复+ERR， 说明主节点版本低于Redis2.8， 无法识别psync命令，
从节点将发送旧版的sync命令触发全量复制流程。

全量复制
全量复制是Redis最早支持的复制方式， 也是主从第一次建立复制时必须经历的阶段。 触发全量复制的命令是sync和psync。redis2.8以下的是sync。2.8及2.8以上的是psync。

这里主要介绍psync全量复制流程， 它与2.8以前的sync全量复制机制基本一致。

1） 发送psync命令进行数据同步， 由于是第一次进行复制， 从节点没有复制偏移量和主节点的运行ID， 所以发送psync-1。
2） 主节点根据psync-1解析出当前为全量复制， 回复+FULLRESYNC响应。
3） 从节点接收主节点的响应数据保存运行ID和偏移量offset， 执行到当前步骤时从节点打印如下日志：Partial resynchronization not possible (no cached master)
Full resync from master: 92d1cb14ff7ba97816216f7beb839efe036775b2:216789
4） 主节点执行bgsave保存RDB文件到本地， bgsave操作细节和开销见前面的博客。 主节点bgsave相关日志如下：
M * Full resync requested by slave 127.0.0.1:6380377
M * Starting BGSAVE for SYNC with target: disk
C * Background saving started by pid 32618
C * RDB: 0 MB of memory used by copy-on-write
M * Background saving terminated with success
5） 主节点发送RDB文件给从节点， 从节点把接收的RDB文件保存在本地并直接作为从节点的数据文件， 接收完RDB后从节点打印相关日志， 可以在日志中查看主节点发送的数据量：
16:24:03.057 * MASTER <-> SLAVE sync: receiving 24777842 bytes from master

需要注意， 对于数据量较大的主节点， 比如生成的RDB文件超过6GB以上时要格外小心。 传输文件这一步操作非常耗时， 速度取决于主从节点之间网络带宽， 通过细致分析Full resync和MASTER<->SLAVE这两行日志的时间差， 可以算出RDB文件从创建到传输完毕消耗的总时间。 如果总时间超过repl-timeout所配置的值（默认60秒） ， 从节点将放弃接受RDB文件并清理已经下载的临时文件， 导致全量复制失败。

6） 对于从节点开始接收RDB快照到接收完成期间， 主节点仍然响应读写命令， 因此主节点会把这期间写命令数据保存在复制客户端缓冲区内， 当从节点加载完RDB文件后， 主节点再把缓冲区内的数据发送给从节点， 保证主从之间数据一致性。 如果主节点创建和传输RDB的时间过长， 对于高流量写入场景非常容易造成主节点复制客户端缓冲区溢出。 默认配置为clientoutput-buffer-limit slave256MB64MB60， 如果60秒内缓冲区消耗持续大于64MB或者直接超过256MB时， 主节点将直接关闭复制客户端连接， 造成全量同步失败。

7） 从节点接收完主节点传送来的全部数据后会清空自身旧数据。

8） 从节点清空数据后开始加载RDB文件， 对于较大的RDB文件， 这一步操作依然比较耗时， 可以通过计算日志之间的时间差来判断加载RDB的总耗时。

9） 从节点成功加载完RDB后， 如果当前节点开启了AOF持久化功能，它会立刻做bgrewriteaof操作， 为了保证全量复制后AOF持久化文件立刻可用。

通过分析全量复制的所有流程， 读者会发现全量复制是一个非常耗时费力的操作。 它的时间开销主要包括：
·主节点bgsave时间。
380·RDB文件网络传输时间。
·从节点清空数据时间。
·从节点加载RDB的时间。
·可能的AOF重写时间。
例如我们线上数据量在6G左右的主节点， 从节点发起全量复制的总耗时在2分钟左右。 因此当数据量达到一定规模之后， 由于全量复制过程中将进行多次持久化相关操作和网络数据传输， 这期间会大量消耗主从节点所在服务器的CPU、 内存和网络资源。 所以除了第一次复制时采用全量复制在所
难免之外， 对于其他场景应该规避全量复制的发生。 正因为全量复制的成本问题， Redis实现了部分复制功能。

部分复制

部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施，使用psync{runId}{offset}命令实现。 当从节点（slave） 正在复制主节点（master） 时， 如果出现网络闪断或者命令丢失等异常情况时， 从节点会向主节点要求补发丢失的命令数据， 如果主节点的复制积压缓冲区内存在这部
分数据则直接发送给从节点， 这样就可以保持主从节点复制的一致性。 补发的这部分数据一般远远小于全量数据， 所以开销很小。

流程说明：
1） 当主从节点之间网络出现中断时， 如果超过repl-timeout时间， 主节点会认为从节点故障并中断复制连接。如果此时从节点没有宕机， 也会打印与主节点连接丢失日志。
2） 主从连接中断期间主节点依然响应命令， 但因复制连接中断命令无法发送给从节点， 不过主节点内部存在的复制积压缓冲区， 依然可以保存最近一段时间的写命令数据， 默认最大缓存1MB。
3） 当主从节点网络恢复后， 从节点会再次连上主节点。
4） 当主从连接恢复后， 由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。 因此会把它们当作psync参数发送给主节点， 要求进行部分复制操作。
5） 主节点接到psync命令后首先核对参数runId是否与自身一致， 如果一致， 说明之前复制的是当前主节点； 之后根据参数offset在自身复制积压缓冲区查找， 如果偏移量之后的数据存在缓冲区中， 则对从节点发送+CONTINUE响应， 表示可以进行部分复制。
6） 主节点根据偏移量把复制积压缓冲区里的数据发送给从节点， 保证主从复制进入正常状态。