【Redis—主从复制】

小呆鸟_coding

已于 2023-05-06 11:49:42 修改

阅读量921

点赞数 1

分类专栏： # Redis 文章标签： redis 数据库服务器

于 2023-05-04 11:40:06 首次发布

本文链接：https://blog.csdn.net/weixin_45043334/article/details/130481951

版权

Redis 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

文章目录

概念

如果把数据都存储到一台服务器上，当服务器出现宕机后，数据会丢失。而把数据备份到多台服务器上，那么当一台服务器发生故障后，其他服务器仍然可以继续提供服务。由于是多台服务器，所以服务器之间的数据要保持一致性。
于是Redis提供了主从复制模式，采用的是「读写分离」的方式。主服务器负责读写，从服务器一般只负责读

注意：第一次同步是全量同步的方式。

在这里插入图片描述

主从服务器同步流程

使用replicaof（Redis 5.0 之前使用 slaveof）命令形成主服务器和从服务器的关系。

# 服务器 B 执行这条命令,此时服务器 B 就会变成服务器 A 的「从服务器」
replicaof <服务器 A 的 IP 地址> <服务器 A 的 Redis 端口号>

主从服务器间的第一次同步的过程可分为三个阶段：

第一阶段是建立链接、协商同步；
第二阶段是主服务器同步数据给从服务器；
第三阶段是主服务器发送新写操作命令给从服务器。

具体流程
在这里插入图片描述

执行了 replicaof 命令后，从服务器就会给主服务器发送psync命令,该命令包含主服务器的 runID(每个Redis服务器启动的唯一标识) 和复制进度 offset。第一次同步runID="?",offset=-1。
主服务器收到 psync 命令后，会用 FULLRESYNC (全增量)作为响应命令返回给对方。
主服务器会执行 bgsave 命令来fork一个子进程生成 RDB 文件（异步的，不会阻塞主线程），然后把文件发送给从服务器。
从服务器收到 RDB 文件后，会先清空当前的数据，然后载入 RDB 文件。
- 在此期间写操作命令并没有记录到刚刚生成的 RDB 文件中，这时主从服务器间的数据就不一致了。
- 为了保证主从服务器的数据一致性，主服务器在下面这三个时间间隙中将收到的写操作命令，写入到 replication buffer 缓冲区里：
  - 主服务器生成 RDB 文件期间；
  - 主服务器发送 RDB 文件给从服务器期间；
  - 「从服务器」加载 RDB 文件期间；
从服务器加载完数据后，会回复一个确认消息给主服务器。主服务器将 replication buffer 缓冲区里所记录的写操作命令发送给从服务器，服务器执行发来的命令。

命令传播

主从服务器在完成第一次同步后，双方之间就会维护一个 TCP 长连接。目的是避免频繁的 TCP 连接和断开带来的性能开销。

分摊压力

问题

主服务器会做两件耗时的操作：生成 RDB 文件和传输 RDB 文件。当从服务器比较多的时候，就会带来两个问题：
1. 如果主服务器的内存数据非大，在执行 fork() 函数时是会阻塞主线程的，从而使得 Redis 无法正常处理请求；
2. 传输 RDB 文件会占用主服务器的网络带宽，会对主服务器响应命令请求产生影响。

解决办法

主服务器生成 RDB 和传输 RDB 的压力可以分摊到充当经理角色的从服务器。

'在「从服务器」上执行下面这条命令，使其作为目标服务器的从服务器'
replicaof <目标服务器的IP> 6379

在这里插入图片描述

增量复制

主从第一次同步后就是保持长连接，但是由于网络问题，连接可能断开，当网络恢复后，主从服务器会采用增量复制的方式继续同步

增量复制的流程
从服务器在恢复网络后，会发送 psync 命令给主服务器，此时的 psync 命令里的 offset 参数不是 -1；
主服务器收到该命令后，然后用 CONTINUE 响应命令告诉从服务器接下来采用增量复制的方式同步数据；
主服务将主从服务器断线期间，所执行的写命令发送给从服务器，然后从服务器执行这些命令。

主服务器
在这里插入图片描述

repl_backlog_buffer，是一个「环形」缓冲区，用于主从服务器断连后，从中找到差异的数据；
- 在主服务器进行命令传播时，不仅会将写命令发送给从服务器，还会将写命令写入到 repl_backlog_buffer 缓冲区里。
replication offset，标记上面那个缓冲区的同步进度，主从服务器都有各自的偏移量，主服务器使用 master_repl_offset 来记录自己「写」到的位置，从服务器使用 slave_repl_offset 来记录自己「读」到的位置。
- 网络断开恢复后，从服务器会通过 psync 命令将自己的复制偏移量 slave_repl_offset 发送给主服务器，主服务器根据自己的 master_repl_offset - slave_repl_offset 的值决定执行增量还是全量
  - 从服务器要读取的数据还在 repl_backlog_buffer 缓冲区里，那么主服务器将采用增量同步的方式；
  - 从服务器要读取的数据已经不存在 repl_backlog_buffer 缓冲区里，那么主服务器将采用全量同步的方式。

总结

为了避免在网络恢复时，主服务器频繁地使用全量同步的方式，我们应该调整下 repl_backlog_buffer 缓冲区大小，尽可能的大一些，减少出现从服务器要读取的数据被覆盖的概率，从而使得主服务器采用增量同步的方式。

面试题

1.Redis主从节点时长连接还是短连接？

长连接

2.怎么判断 Redis 某个节点是否正常工作？

通过互相的 ping-pong 心态检测机制，如果有一半以上的节点去 ping 一个节点的时候没有 pong 回应，集群就会认为这个节点挂掉了，会断开与这个节点的连接。
- Redis 主节点默认每隔 10 秒对从节点发送 ping 命令，判断从节点的存活性和连接状态。
- Redis 从节点每隔 1 秒发送 replconf ack{offset} 命令。
  - 监测主从节点网络状态；
  - 上报自身复制偏移量，检查复制数据是否丢失，如果从节点数据丢失，再从主节点的复制缓冲区中拉取丢失数据。

3.主从复制架构中，过期key如何处理？

主节点处理了一个key或者通过淘汰算法淘汰了一个key，这个时间主节点模拟一条del命令发送给从节点，从节点收到该命令后，就进行删除key的操作。

4.Redis 是同步复制还是异步复制？

Redis 主节点每次收到写命令之后，先写到内部的缓冲区，然后异步发送给从节点。

5.主从复制中两个 Buffer(replication buffer 、repl backlog buffer)有什么区别？

出现的阶段不一样：
- repl backlog buffer 是在增量复制阶段出现，一个主节点只分配一个 repl backlog buffer；
- replication buffer 是在全量复制阶段和增量复制阶段都会出现，主节点会给每个新连接的从节点，分配一个 replication buffer；
这两个 Buffer 都有大小限制的，当缓冲区满了之后，发生的事情不一样：
- 当 repl backlog buffer 满了，因为是环形结构，会直接覆盖起始位置数据;
- 当 replication buffer 满了，会导致连接断开，删除缓存，从节点重新连接，重新开始全量复制。

6.为什么会出现主从数据不一致？

主从节点间的命令复制是异步进行的，所以无法实现强一致性保证（主从数据时时刻刻保持一致）。
主节点并不会等到从节点实际执行完命令后，再把结果返回给客户端，而是主节点自己在本地执行完命令后，就会向客户端返回结果了。如果从节点还没有执行主节点同步过来的命令，主从节点间的数据就不一致了。

7.如何应对主从数据不一致？

第一种方法，尽量保证主从节点间的网络连接状况良好，避免主从节点在不同的机房。
第二种方法，可以开发一个外部程序来监控主从节点间的复制进度
- 如果某个从节点的进度差值大于我们预设的阈值，可以让客户端不再和这个从节点连接进行数据读取。不过，为了避免出现客户端和所有从节点都不能连接的情况，我们需要把复制进度差值的阈值设置得大一些。

8.主从切换如何减少（不可能保证数据完全不丢失）数据丢失？
主从切换过程中，产生数据丢失的情况有两种：

异步复制同步丢失
集群产生脑裂数据丢失

异步复制同步丢失?

主从复制时异步的，当客户端发送写请求给主节点的时候，客户端会返回 ok，接着主节点将写请求异步同步给各个从节点，如果此时主节点还没来得及同步给从节点时发生了断电，那么主节点内存中的数据会丢失。

减少异步复制的数据丢失的方案

Redis 配置里有一个参数 min-slaves-max-lag，当主从数据复制和同步延迟超过该值，那么主节点会拒绝接收任何请求
假设将 min-slaves-max-lag=10s,如果数据同步完成所需要时间超过10s,master 就拒绝写入新请求。这样主从数据控制在10s内，即使主节点宕机也只损失10s数据

对于客户端，当客户端发现 master 不可写后，将数据暂时写入本地缓存和磁盘中，在一段时间（等 master 恢复正常）后重新写入 master 来保证数据不丢失，也可以将数据写入 kafka 消息队列，等 master 恢复正常，再隔一段时间去消费 kafka 中的数据，让将数据重新写入 master 。

集群产生脑裂数据丢失?

由于网络问题，主从节点之间失去联系，当主节点与客户端正常，主从数据不同步；哨兵重新选取主节点，此时有两个主节点。等网络恢复，旧主节点会降级为从节点，再与新主节点进行同步复制的时候，由于会从节点会清空自己的缓冲区，所以导致之前客户端写入的数据丢失了。

减少脑裂的数据丢的方案

min-slaves-to-write x，主节点必须要有至少 x 个从节点连接，如果小于这个数，主节点会禁止写数据。
min-slaves-max-lag x，主从数据复制和同步的延迟不能超过 x 秒，如果主从同步的延迟超过 x 秒，主节点会禁止写数据。
主节点连接的从节点中至少有 N 个从节点，「并且」主节点进行数据复制时的 ACK 消息延迟不能超过 T 秒，否则，主节点就不会再接收客户端的写请求了。

9.主从如何做到故障自动切换？