压箱底Redis面试集 -17.Redis 主从复制的实现原理是什么?

Redis 的主从复制原理主要包含以下几个关键方面：

一、架构基础

Redis 支持主从复制架构，其中一个实例作为主节点（Master），负责处理写操作，其他实例作为从节点（Slave），负责复制主节点的数据并处理读操作。

二、主从复制的实现过程

1. 建立连接与请求同步从节点通过配置项获取主节点的 IP 和端口后建立连接。连接成功后，从节点向主节点发送包含 runID 和 offset 的 PSYNC 命令请求数据同步。首次同步时 runID 为 ?（因为还不知道主库实例 ID），offset 为 -1（表示全量复制）。主节点收到命令后创建专门的复制后台线程，并记录从节点的 offset 参数，开始准备进行 RDB 同步。
2. RDB 同步主节点执行 bgsave 命令，通过 fork 出一个子进程来遍历自身数据集并生成一个 RDB 文件。在这个过程中，主节点的主进程不会被阻塞，依然可以对外提供服务并接收数据写入缓冲区。从节点接收到 RDB 文件后，会清空自身数据，然后加载这个文件，将自己的数据集替换成与主节点相同的数据集。
3. 命令同步由于全量复制耗时较长，在这个期间主节点依旧会有新的数据写入。因此在完成 RDB 同步后，主节点需要将这部分新增数据发送给从节点，以确保从节点的数据集与主节点保持一致。
4. 增量同步（完成全量复制后的后续同步方式）命令传播：全量复制完成后，主从服务器之间会保持一个 TCP 连接，主节点将自己的写操作通过这个连接发送给从节点，从节点执行这些写操作，实现基于长连接的命令传播，以保持数据的一致性。虽然增量复制的数据是异步复制的，但通过持续记录写操作，主从服务器之间的数据最终会达到一致状态。网络断开后的数据同步：当网络出现抖动或故障导致连接断开时，主节点上新的写命令将无法同步到从节点。从 Redis 2.8 开始，从节点支持增量同步，在网络恢复后，从节点会携带之前主节点返回的 runid 和复制的偏移量 offset，发送 psync runid offset 命令给主节点请求数据同步。主节点收到命令后，核查 runid 和 offset，确认无误后响应 continue 命令，并将网络断开期间的写命令发送给从节点，从节点接收并执行这些命令。增量复制的关键机制：主节点在执行写操作时，会将这些命令记录在 repl_backlog_buffer（复制积压缓冲区）里面，并使用 master_repl_offset 记录写入的位置偏移量。从节点在执行同步的写命令后，也会用 slave_repl_offset 记录写入的位置偏移量。正常情况下，从节点会和主节点的偏移量保持一致。但当网络断开后，主节点继续写入，从节点的偏移量停止更新，此时 master_repl_offset 会大于 slave_repl_offset。repl_backlog_buffer 是一个环形缓冲区，如果缓冲区已满（例如超过一定设定值），会从头覆盖前面的内容。所以当网络恢复后，主节点只需将 master_repl_offset 和 slave_repl_offset 之间的内容同步给从节点即可。需要注意的是，主节点的积压缓冲区默认为 1M，如果从节点网络断开太久，缓冲区之前的内容被覆盖，那么就只能重新进行全量同步了。

三、读写分离的必要性与实现方式

1. 防止并发问题由于数据是从主节点单向复制到从节点的，如果主从节点都能写入数据，那么数据一致性将难以保证。采用加锁的方式会引发分布式一致性问题，并且在高频并发场景下还会导致写入效率降低和吞吐量大幅下降等问题，对于追求高效的 Redis 来说不是一个好的方案。而采用最终一致性方式又可能导致主从库数据不一致，影响用户体验。因此，为了权衡数据并发和用户体验，规定只在主节点上写入数据，从节点上读取数据。
2. 易于扩展大多数使用 Redis 的业务都是读多写少的场景，根据业务量的规模可以方便地扩展从节点的数量，实现弹性扩展。同时，读写分离还能实现数据备份和负载均衡，提高系统的可靠性和性能。
3. 高可用保障Redis 可以手动切换主从节点，实现故障隔离和恢复。这样，无论主节点还是从节点宕机，其他节点依然可以保证服务的正常运行。

上一篇：Redis面试-16.redis中pipeline有什么好处，为什么要用 pipeline？

下一篇：压箱底Redis面试集 -18.Redis 中如何实现分布式锁？