【Redis进阶】主从复制

我们知道Redis的AOF和RDB数据持久化技术保证了在服务器重启的情况下也不会丢失数据（或者少丢）。但是如果数据是存储在单点服务器上，当服务器出现宕机情况下，由于数据恢复是需要时间，这个时间无法处理请求或者更严重的情况下，如果服务器硬盘出问题，那么会造成数据的无法恢复。因此为了避免这种单点故障带来的一系列问题，有了主从复制，就是把数据备份到不同的服务器上。

主从复制架构

一主一从
一主多从

主从保证数据一致性

有了架构，那么多个服务器之间是如何保证数据一致性的，对此，Redis提供了主从复制模式。

主服务器可以读写
从服务器一般都是读
接受主服务器同步来的写操作命令

主从复制原理

先来认识一下几个概念

runid

每个 Redis 服务器在启动时都会自动生产一个随机的 ID 来唯一标识自己。

offset（偏移量）

当前数据的偏移量，例如执行一条指令后，产生一条数据后，会增大偏移量，从节点请求复制主节点的时候，会带上这个信息，让主节点从这个偏移量之后的数据返回给我。

全量复制

图解

执行步骤

执行了 replicaof 命令后，从服务器就会给主服务器发送 psync 命令，表示要进行数据同步。psync携带runid和offset，如果第一次同步，传？和 -1
主服务器收到 psync 命令后，会用 FULLRESYNC 作为响应命令返回给对方。并且这个响应命令会带上两个参数：主服务器的 runID 和主服务器目前的复制进度 offset。从服务器收到响应后，会记录这两个值。
主服务器执行bgsave，生成RDB文件，在此期间生成的命令全部放到buffer中
主服务器将生成的rdb文件，传输给从服务器
从服务器收到 RDB 文件后，会先清空当前的数据，然后载入 RDB 文件。
在主服务器生成的 RDB 文件发送后，然后将 replication buffer 缓冲区里所记录的写操作命令发送给从服务器，然后从服务器重新执行这些操作。

增量复制

主从服务器在完成第一次同步后，就会基于长连接进行命令传播。

但是如果由于网络问题出现抖动或连接断开，则会导致主从复制不同步，所以当网络连接正常时，则主从之间将发生增量复制。

先来了解一下几个概念

repl_backlog_buffer ，是一个「环形」缓冲区，用于主从服务器断连后，从中找到差异的数据；
replication offset ，标记上面那个缓冲区的同步进度，主从服务器都有各自的偏移量，主服务器使用 master_repl_offset 来记录自己「写」到的位置，从服务器使用 slave_repl_offset 来记录自己「读」到的位置。

repl_backlog_buffer 缓冲区从什么时候写入？

在主服务器进行命令传播时，不仅会将写命令发送给从服务器，还会将写命令写入到 repl_backlog_buffer 缓冲区里，因此这个缓冲区里会保存着最近传播的写命令。

网络断开后，当从服务器重新连上主服务器时，从服务器会通过 psync 命令将自己的复制偏移量 slave_repl_offset 发送给主服务器，主服务器根据自己的 master_repl_offset 和 slave_repl_offset 之间的差距，然后来决定对从服务器执行哪种同步操作：

如果判断出从服务器要读取的数据还在 repl_backlog_buffer 缓冲区里，那么主服务器将采用增量同步的方式；
相反，如果判断出从服务器要读取的数据已经不存在repl_backlog_buffer 缓冲区里，那么主服务器将采用全量同步的方式。

图解

步骤

从节点向主节点发送psync命令携带已保存的runid和offset
主节点判断runid是否和自己的id一致，如果不一致则执行全量同步
主节点判断offset是否在环形缓冲区内，如果不在则执行全量同步
offset如果在环形缓冲区内，则执行增量同步

repl_backlog_buffer 缓行缓冲区的默认大小是 1M，并且由于它是一个环形缓冲区，所以当缓冲区写满后，主服务器继续写入的话，就会覆盖之前的数据。因此，为了避免在网络恢复时，主服务器频繁地使用全量同步的方式，我们应该调整下 repl_backlog_buffer 缓冲区大小，尽可能的大一些，减少出现从服务器要读取的数据被覆盖的概率，从而使得主服务器采用增量同步的方式。

主从复制的配置

配置 Redis 主从复制非常简单，只需要在从服务器的配置文件中指定主服务器的地址和端口即可。

XML 复制代码

# 从服务器的配置文件
replicaof 127.0.0.1 6379

主从复制的优缺点

优点：

提高系统可用性：通过将数据复制到多个从服务器，系统能够在主服务器故障时继续提供服务，提升了整体的可靠性和可用性。
扩展读性能：从服务器可以处理读请求，这样可以扩展系统的读性能，尤其在读多写少的场景中。
简化数据备份：从服务器可以作为数据的热备份，简化了数据备份和恢复操作。

缺点：

一致性问题：由于复制是异步的，可能会出现短暂的数据不一致性（主服务器和从服务器之间的数据延迟）。
延迟问题：从服务器的数据同步存在一定的延迟，尤其在高写入量的场景中，这种延迟可能会加剧。
无法分担写操作：写操作仍然需要通过主服务器来处理，因此主服务器的写入能力可能成为瓶颈。

主从复制的应用场景

读写分离：

主从复制允许将写操作定向到主服务器，而将读操作分散到多个从服务器上，从而实现读写分离，缓解主服务器的读压力。

数据备份：

从服务器保存着主服务器的数据副本，可以作为数据备份。当主服务器出现故障时，从服务器的数据可以用来恢复。

高可用性：

主从复制是 Redis 高可用性架构（如 Redis Sentinel 和 Redis Cluster）的基础。通过监控和自动故障转移，可以在主服务器故障时快速切换到从服务器。

Redis 的主从复制机制通过数据同步和读写分离，增强了系统的可用性和扩展性。它是 Redis 实现高可用性和读性能扩展的基础，也是构建复杂 Redis 集群的重要组件。在使用主从复制时，需要权衡数据一致性和系统性能之间的关系，并根据具体业务需求进行优化和配置。