redis学习笔记之主从复制篇

1.主从配置：

3种配置主从的方式：

a.配置文件slaveof {masterHost} {masterPort}

b. redis-server --slaveof {masterHost} {masterPort}

c. slaveof {masterHost} {masterPort} 命令

断开主从复制关系：从节点执行slaveof no one

切主操作流程：断开与旧主节点的复制关系→与新主节点建立复制关系→删除从节点当前所以数据→对新节点进行复制操作

数据传输延迟repl-disable-tcp-nodelay参数：用于控制是否关闭tcp-nodelay,默认关闭；关闭时,主节点产生的命令数据无论大小都会及时发送给从节点,主从延迟变小,网络带宽消耗增加,开启时,主节点会合并较小的TCP数据包,默认间隔40毫秒发送一次,主从延迟变大,网络带宽消耗减少

2.三种复制拓扑结构：

A.一主一从：用于主节点出现故障时从节点提供故障转移,当应用写命令并发量较高且需要持久化时,可以只在从节点上开启aof,当主节点关闭持久化功能时,要避免自动重启操作,因为主节点没开启持久化功能自动重启后数据集为空,这是从节点如果继续复制主节点将导致从节点数据也被清空,安全的做法是先在从节点上执行slaveof no one命令,与主节点断开复制关系,再重启主节点

B.一主多从：可利用多个从节点实现读写分离,对于读占比较大的场景,可以把读命令发送到从节点来分担主节点压力,同时在日常开发中如果需要执行一些比较耗时的读命令,如：keys、sort等,可以在其中一台从节点上执行,防止慢查询对主节点造成阻塞从而影响线上服务的稳定性；但对于写并发量较高的场景，多个从节点会导致主节点写命令的多次发送从而过度消耗网络带宽,同时也加重了主节点的负载影响服务稳定性

C.树状结构：从节点不但可以复制主节点数据,同时可以作为其他从节点的主节点继续向下层复制,通过引入复制中间层,可以有效降低主节点负载和需要传送给从节点的数据量, 数据实现了一层一层的向下复制,当主节点需要挂载多个从节点时为了避免对主节点的性能干扰,可以采用树状主从结构降低主节点压力

3.复制流程：

A.复制的大体流程：

a.保存主节点信息：执行完slaveof命令后从节点只保存主节点的信息地址便返回,此时建立复制流程还未开始

b.主从建立socket连接：从节点内部通过每秒运行定时任务维护复制相关逻辑,当定时任务发现存在新的主节点后,会尝试与该节点建立网络连接,若无法建立连接,定时任务会无限重试直到连接成功或执行slaveof no one命令为止

c.发送ping命令：用于检测主从之间网络套接字是否可用和主节点当前是否可接受处理命令,若从节点没收到主节点的pong回复或超时,则断开复制连接,下次定时任务会发起重连

d.权限验证：若主节点设置了requirepass参数,则需要密码验证,从节点必须配置masterauth参数保证与主节点相同的密码才能通过验证,若验证失败则复制终止,从节点重新发起复制流程

e.数据集同步：主从复制连接正常通信后,对于首次建立复制的场景,主节点会把持有的数据全部发送给从节点,这步操作耗时最长(全量复制)

f.命令持续复制：当主节点把当前的数据同步给从节点后,便完成复制的建立流程,接下来主节点会持续把写命令发送给从节点,保证主从数据一致性

B.数据同步(基于psync命令)：

全量复制：用于初次复制场景(不可避免),主节点将全部数据一次性发送给从节点,当数据量较大时,会对主从节点与网络造成很大开销

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

psync命令：需复制偏移量、复制积压缓冲区、主节点运行id支持

复制偏移量：用于记录主从节点数据同步偏差的量,可用info replication查看

复制积压缓冲区：保存在主节点上的一个固定长度的队列,默认大小1M,当主节点有连接的从节点被创建时,主节点响应写命令时,不但会把命令发送给从节点，还会写入复制积压缓冲区,可用info replication查看,用于数据补救

主节点运行id：每个主节点的唯一标识,运行id变化,则从节点发生全量复制,可使用info server查看(PS：若只是用ip+port方式进行标识,当主节点重启变更整体数据集(如替换RDB/AOF文件),从节点再基于偏移量复制数据将不再安全,redis重启,运行id也会改变)

不改变运行ID的情况下重启：使用debug reload命令(PS：该命令会阻塞当前redis节点主线程,阻塞期间会生成本地RDB快照并清空数据后再加载RDB文件,对于大数据量的主节点和无法容忍阻塞的场景,慎用！)

psync命令流程：psync runId(主节点运行id) offset(从节点复制偏移量)

a.从节点(slave)发送psync命令给主节点,若是第一次参与复制则offset为-1

b.主节点(master)根据psync参数和自身数据情况决定响应结果：

若回复+FULLRESYNC {runId} {offset}，则从节点将触发全量复制流程

若回复+CONTINUE，则从节点将触发部分复制流程

若回复+ERR，说明主节点版本低于Redis2.8,无法识别psync命令,从节点将发送旧版的sync命令触发全量复制流程

C.全量复制流程：

1.发送psync命令进行数据同步,是第一次进行复制,从节点没有复制 偏移量和主节点的运行id,所以发送psync-1

2.主节点解析出为全量复制,回复+FULLRESYNC响应

3.从节点接收主节点的响应数据保存运行id和偏移量offset

4.主节点执行bgsave保存RDB文件到本地

5.主节点发送RDB文件给从节点,从节点把接收的RDB文件保存在本地并直接作为从节点的数据文件

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

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

8.从节点清空数据后开始加载RDB文件

9.从节点加载完RDB后,若当前节点开启aof功能,会立刻做 bgrewriteaof操作,保证全量复制后aof持久化文件立刻可用

PS：RDB文件大于6G的主节点,复制要格外注意,若复制的总时间超 过repl-timeout所配置的值(默认60s),从节点将放弃接受RDB文件并 清理已下载的临时文件,全量复制将失败,对于数据量较大的节点,建 议跳大repl-timeout参数防止超时 全量复制主要时间开销=主节点bgsave+RDB文件网络传输+从节点清空数据+从节点记载RDB+可能的aof重写

D.部分复制流程：

1.当主从节点之间网络出现中断时,若超过repl- timeout时间,主节点会认为从节点故障并中断复制连接

2.主从连接中断期间主节点依然响应命令,但因复制连接中断命令无法发送给从节点,但主节点内部 存在复制积压缓冲区,可保存最近一段时间的写命令数据

3.当主从节点网络恢复,从节点将再次连上主节点

4.当主从连接恢复后,由于从节点之前保存了自身 已复制的偏移量和主节点的运行id,因此会把它们 当作psync参数发送给主节点,要求进行部分复制 操作

5.主节点接到psync命令后首先核对参数runId是否与自身一致,若一致,说明之前复制的是当前主节点,之后根据参数offset在自身复制积压缓冲区查找,如果偏移量之后的数据存在缓冲区中,则对从节点发送+CONTINUE响应, 表示可进行部分复制

6.主节点根据偏移量把复制积压缓冲区里的数据发送给从节点,保证主从复制进入正常状态

4.主从常见问题：

 A.读写分离：

a.数据延迟：取决于网络网络带宽与命令阻塞情况

处理方式：编写外部监控程序监听主从节点的复制偏移量,当延迟较大时触发报警或通知客户端避免读取延迟过高的节点,可采用Zookeeper的监听回调机制实现客户端通知,成本较高

b.读到过期数据：当主节点存储大量设置超时的数据,且在某一时间点数据大量超时,主节点采样速度跟不上过期速度且主节点没读取过期键的操作,则从节点无法收到del命令,此时从节点可以读取到超时过期的数据

惰性删除：主节点每次处理读取命令时,都会检查键是否超时,若超时则执行del命令删除键对象,之后del命令异步发送给从节点(为保证复制一致性,从节点不会主动删除超时数据),有可能存在内存泄漏问题,当过期键一直没被访问将无法及时删除,从而导致内存不能及时释放,或者在从节点上可能会读取到已过期的数据

定时删除：redis主节点在内部定时任务会循环采样一定数量的键,当发现采用的键过期时执行del命令,之后再同步给从节点(后面详细介绍) 处理方式：从节点读取数据前检查键的过期时间来决定是否返回数据,可升级到3.2版本来规避

c.从节点故障：

处理方式：客户端维护可用的从节点列表,当从节点故障时切换到其他从节点或主节点上

B.主从配置不一致：

对于内存方面的配置,主从必须一致,如maxmemory,hash-max-ziplist-entries等参数；当配置的maxmemory从节点小于主节点,如果复制的数据量超过从节点maxmemory时,它会根据maxmemory-policy策略进行内存溢出控制,此时从节点数据已经丢失,但主从复制流程依然正常进行,复制偏移量也正常,修复此类问题只能手动进行全量复制

C.避免全量复制：

a.第一次建立复制,此场景无法避免

b.运行id不匹配,主节点重启后运行id将改变

c.复制积压缓冲区不足,当主从节点网络中断后,从节点再次连上主节点时会发送psync {offset} {runId}命令请求部分复制,若请求的偏移量不在主节点的积压缓冲区内,则无法提供给从节点数据,此时部分复制会退化为全量复制,需根据网络中断时长,写命令数据量分析出合理的积压缓冲区大小,写命令数据量可统计高峰期主节点每秒info replication的master_repl_offset差值获取

D.复制风暴：

指大量从节点对同一主节点或者对同一台机器的多个主节点短时间内发起全量复制的过程

a.单节点复制风暴：一主多从场景下,主节点重启后,从节点发起全量复制,主节点创建rdb快照,且多个从节点共享该快照,主节点同时向多个从节点发送rdb快照,可能使主节点网络带宽消耗严重,主节点延迟变大,甚至发送主从节点连接断开,复制失败

解决法案：减少主节点挂载从节点的数量,或采用树状复制结构(运维复杂,手动与自动处理故障转移难度增加)

b.单机器复制风暴：当一台机器同时部署多个主节点时,若该机器出现故障或网络长时间中断,重启恢复后,会有大量从节点针对这台机器的主节点进行全量复制,导致当前机器网络带宽耗尽

解决方案：应该将主节点尽量分散在多台机器上,避免单机部署多主节点