redis主从复制 主从概念 master/slave配置

在分布式系统中为了解决单点问题,通常会把数据复制多个副本部署到其他机器,满足故障恢复和负载均衡等需
求。Redis也是如此,它为我们提供了复制功能,实现了相同数据的多个Redis副本。复制功能是高可用Redis的基
础,后面的哨兵和集群都是在复制的基础上进行的。

一   建立配置：

 默认情况下，每台redis都是主节点，每个从节点只能有一个主节点，主节点可以同时拥有多个从节点。复制的数据是单向的，只能由主节点复制到从节点，配置从节点主要有以下三种方式：

      (1)配置文件中加入slaveof  （masterhost）（masterport）随redis启动生效

      (2)在redis-server启动命令后加入--slaveof (masterHost} ( asterPort)生效。

      (3)直接使用命令：slaveof (masterHost) (masterPort)生效。

查看主从复制状态：

主节点查看

从节点查看

 

     

1. 断开主从复制：

   1. slaveof  no one

2. 安全性：

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

3.  只读：

   1. 默认从节点为slave-read-only=yes

4.  传输延迟

   1. 参数repl-disable-tcp-nodelay默认关闭

   2. 关闭时：主节点的数据无论大小都会及时的发送给从节点，这样主从延迟变小，但是增加了网络的带宽，适用于同机架或同机房
   3. 开启时：主节点会合并较小的TCP数据包来节省带宽，默认发送间隔取决于linux内核，默认40毫秒，这种配置节省了网络的带宽，但是增加了主从之间的延迟，适用于跨机房部署
5. 主从拓补结构：
   1. 一般分为三种：一主一从，一主多从，树状主从
   2. 一主一从：最简单的拓补结构，用于主节点出现宕机时，从节点提供故障转移支持。当主节点写命令并发量高时，可以开启从节点上的AOF，这样既保证了数据的安全性同时也避免了持久化对主节点性能的干扰。需要注意的是，当主节点关闭持久化时，要避免主节点重启的操作，因为主节点没有开启持久化，如果重启后，数据会为空，如果此时从节点继续复制主节点会导致从节点数据也被清空的情况。如果生产环境需要进行主库的重启操作，安全的做法是在主节点重启之前，在从节点执行slaveof no one 来断开与主节点的复制，再执行主节点的重启操作。
   3. 树状主从结构：从节点不但可以复制主节点的数据，还可以作为其他从节点的主节点继续向下层复制，这种结构解决的单一主节点的高负载问题。
   4. 一主多从结构：又称为星型拓补结构，可以利用多从节点实现读写分离，降低主节点压力，同时日常开发需要使用到一些比较耗时间的读命令，比如keys，sort等，可以在其中一台从节点上进行，这种结构也有一些问题，比如有些场景写并发比较高，多个从节点会导致主节点多次发送命令而过度消耗网络带宽，加重了主节点的负载
6. 复制过程的原理：
   1. 保存主节点信息(master)信息
   2. 从节点无法建立链接，定时任务会无限重复，直到链接成功，或执行 slaveof no one
   3. 从节点会尝试与该新主节点建立网络连接；从节点会建立一个socket套接字，专门用于接受主节点发送的复制命令。
   4. 从节点内部通过每秒运行的定时任务维护，来复制相关的逻辑，当定时任务发现存在的新的主节点
7. 节点失败原因：
   1. 命令：Info replication 查看master_link_down_since_seconds 记录着与主节点连接失败的系统时间
   2. 同步数据集 psync同步，主节点全部发送给从节点
   3. 执行权限的验证，密码验证
   4. 检测主节点当前是否接受处理命令 如果发送ping命令后，从节点没有收到主节点的pong回复时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制连接，下次定时任务会发起重连
   5. 连接成功时，从节点发送ping命令，请求进行首次通信，检测主从间网络套接字是否可用
   6. 命令持续复制

二 数据同步

1. 偏移量：
   1. 参与复制的主从节点都会维护自身复制偏移量，主节点在处理完写入命令后，会把命令的字节长度做累计记录，统计在info replication 命令下的参数master_repl_offset ，从节点每秒上报自身复制的偏移量给主节点，主节点也会保存从节点的复制偏移量
   2. 每时每刻都会发生变更，但是主节点和从节点相差不能过大，过大说明复制有延迟，或没有同步
2. 复制积压缓冲区：

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

3. 主节点的run_id：

   1. 每个redis节点启动后都会动态分配1个40位16进制的字符串作为运行id，运行id的作用是用来表示唯一识别redis的节点，用命令info server查看当前节点的run_id，关闭再启动后，运行id会改变

4. 执行Psync命令进行全量复制和部分复制：

   1. Psync [runid] [offset]
   2. offset当前从节点已复制的数据偏移量 默认-1
   3. runid从节点所复制主节点运行id 默认值？
5. 注意事项：

   1. 从节点每次重新连接主节点都会刷新数据，会刷新本身的原有的所有的key值。所以当从节点加入主从复制之前，为了保证原有的数据不丢失，应该shutdown关闭redis，然后保存dump.rdb文件

6. 全量复制过程;
   1. slave第一次连接master会发送psync ？-1 ，master以此知道slave是第一次连接自己
   2. Master会将runid和offset（偏移量）传给slave
   3. Master会执行bgsave保存RDB持久化文件保存到本地，
   4. Master把RDB文件传给slave，slave保存传过来的RDB文件并直接保存在自己的数据文件中，
   5. Slave收到后会flushall自己的库，并由内存加载传送过来的RDB文件的数据。
   6. 与此同时master还在持续的向RDB储存文件，这时的文件会存在一个buffer中，当slave加载完RDB文件数据后，master再将自己的buffer的文件传给slave保证数据一致。
7. 部分复制工作流程：
   1. 主从节点之间断开连接时，如果超过reply-timeout时间，主节点会认为从节点出现了故障，并且中断复制连接
   2. 从连接终断期间，主节点依然响应命令，但因为复制命令无法发送给从节点，不过主节点内部存在复制积压缓冲区，依然保证最近一段时间的写入命令不丢失，默认情况下缓存1M 3 主从节点网络恢复之后，从节点会再次连接上主节点
   3. 从节点发送给主节点恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行id，从会把他们当作psync发送给主节点，要求进行复制操作

   4. 主节点连接到psync命令后首先核对参数runid是否一致，如果一致，当前节点为主节点，主节点发送continue表示可以进行部分复制

   5. 主节点根据偏移量把复制积压缓冲区里的数据发送给从节点

8. 心跳机制：

   1. 主从节点在建立复制后，它们之间维护着长连接并彼此发送心跳命令，主从心跳判断机制 1 主从节点彼此都有
      心跳检测机制，各自模拟成对方的客户端进行通信，通过client list命令查看复制相关的客户端信息，主节点的
      连接状态为Flags:M，从节点的连接状态为flags:S

三 开发与运维中遇到的问题

1. 读写分离问题：
   1. 复制数据延迟 ：可以编写外部监控程序监听主从节点的复制偏移量,当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点
   2. 读到过期数据 ：可以升级到3.2版本来规避这个问题
   3. 从节点故障：需要在客户端维护，维护可用的节点列表，当从节点故障时，会立刻切换到其他的从节点或主节点上，由监控程序去完成。
2. 主从复制不一致问题：
   1. 主从配置不一致是一个容易忽视的问题。对于有些配置主从之间是可以不一致,比如:主节点关闭AOF在从节点开启。但对于内存相关的配置必须要一致,比如maxmemory,hash-max-ziplist-entries等参数。当配置的maxmemory从节点小于主节点,如果复制的数据量超过从节点maxmemory时,它会根据maxmemory-policy策略进行内存溢出控制,此时从节点数据已经丢失,但主从复制流程依然正常进行,复制偏移量也正常。修复这类问题也只能手动进行全量复制。当压缩列表相关参数不一致时,虽然主从节点存储的!数据一致但实际内存占用情况差异会比较大
3. 规避全量复制
   1. 建议在低峰时进行操作,或者尽量规避使用大数据量的Redis节点
4. 规避复制风暴
   1. 复制风暴是指大量从节点对同一主节点或者对同一台机器的多个主节点短时间内发起全量复制的过程
   2. 规避方式有如下几个：

      1. 单主节点复制风暴：同时向多个从节点发送RDB快照,可能使主节点的网络带宽消耗严重,造成主节点的延迟变大,极端情况会发生主从节点连接断开,导致复制失败。 解决方案首先可以减少主节点(master)挂载从节点(slave)的数量,或者采用树状复制结构,加人中间层从节点用来保护主节点

      2. 单机器复制风暴：应该把主节点尽量分散在多台机器上,避免在单台机器上部署过多的主节点。当主节点所在机器故障后提供故障转移机制,避免机器恢复后进行密集的全量复制。