Redis 主从复制原理学习总结 - 运维笔记

在现代分布式系统中，Redis 作为高性能的内存数据库被广泛应用。为了提高系统的可用性、数据冗余以及分担读压力等，Redis 的主从复制机制发挥着重要作用。本文将深入探讨 Redis 主从复制的原理，并结合运维实践分享相关经验。

目录#

  1. Redis 主从复制概述
  2. 主从复制原理详细剖析
    • 建立连接阶段
    • 数据同步阶段
    • 命令传播阶段
  3. 常见实践
    • 配置主从复制
    • 监控主从状态
  4. 最佳实践
    • 合理规划主从架构
    • 处理主从切换
  5. 示例用法
    • 简单主从复制示例
  6. 总结
  7. 参考文献

1. Redis 主从复制概述#

Redis 主从复制是一种数据复制机制，一个主节点（Master）可以有多个从节点（Slave）。主节点负责处理写操作，然后将写操作同步给从节点，从节点主要用于读操作。这样可以提高系统的读性能（多个从节点分担读压力），同时提供数据冗余，当主节点出现故障时，可通过一定方式（如手动切换或借助 Sentinel 等工具自动切换）让从节点升级为主节点继续提供服务。

2. 主从复制原理详细剖析#

2.1 建立连接阶段#

  • 从节点配置：从节点通过配置文件（如 slaveof <master_ip> <master_port>）或者命令（SLAVEOF <master_ip> <master_port>）指定主节点的 IP 和端口。
  • 三次握手：从节点与主节点建立 socket 连接，进行类似 TCP 的三次握手过程，确保网络连接正常。

2.2 数据同步阶段#

  • 全量同步（初次同步）
    • 主节点收到从节点的同步请求后，执行 bgsave 命令生成 RDB 文件（Redis 数据库的持久化快照文件）。
    • 主节点将 RDB 文件发送给从节点，从节点接收并加载 RDB 文件到自己的内存中，此时从节点的数据与主节点在执行 bgsave 那一刻的数据一致。
    • 在发送 RDB 文件过程中，主节点会将新收到的写命令存储在缓冲区（Replication Buffer）。
  • 部分同步（断线重连后）
    • 当从节点与主节点的连接断开又重新连接时，如果主节点的复制偏移量（Replication Offset，用于标识主从复制的数据同步进度）和从节点记录的复制偏移量差距不大（在一定的复制积压缓冲区范围内），主节点会将缓冲区中从节点断开期间的写命令发送给从节点，从节点执行这些命令来完成数据同步，而无需重新进行全量同步。

2.3 命令传播阶段#

  • 主节点处理客户端的写命令后，会将写命令发送给从节点（通过异步方式），从节点接收并执行这些写命令，从而保证主从节点数据的一致性。

3. 常见实践#

3.1 配置主从复制#

  • 配置文件方式：
    • 在从节点的 redis.conf 配置文件中添加 slaveof <master_ip> <master_port>。例如，如果主节点 IP 是 192.168.1.100，端口是 6379，则配置 slaveof 192.168.1.100 6379。
    • 还可以配置一些其他参数，如 repl-backlog-size（复制积压缓冲区大小，影响部分同步能否成功）等。
  • 命令方式：
    • 启动 Redis 客户端连接到从节点，执行 SLAVEOF 192.168.1.100 6379 命令来动态设置主节点。

3.2 监控主从状态#

  • 查看主从信息：
    • 在主节点执行 info replication 命令，可以查看主节点的复制信息，如 connected_slaves（连接的从节点数量）、master_repl_offset（主节点复制偏移量）等。
    • 在从节点执行 info replication 命令，可查看 master_host（主节点 IP）、master_port（主节点端口）、slave_repl_offset（从节点复制偏移量）等信息，通过对比主从节点的复制偏移量可以判断数据同步是否正常。
  • 使用监控工具：
    • 可以借助 Redis 自带的 redis-cli 结合脚本定时获取主从状态信息进行分析，也可以使用一些第三方监控工具（如 Prometheus + Grafana 搭配 Redis 监控插件）来实时监控主从复制的各项指标（如网络延迟、数据同步延迟等）。

4. 最佳实践#

4.1 合理规划主从架构#

  • 根据业务读负载规划从节点数量：如果业务读操作非常频繁，可适当增加从节点数量来分担读压力，但也要注意从节点过多可能会增加主节点的同步负担（网络带宽、CPU 等资源消耗）。
  • 主从节点部署位置：尽量将主从节点部署在不同的物理机或虚拟机上，避免因同一硬件故障导致主从节点都不可用。同时，考虑网络延迟，尽量让主从节点在同一个局域网内。

4.2 处理主从切换#

  • 手动切换：
    • 当主节点故障时，需要人工干预。先确认主节点确实无法恢复，然后在一个从节点上执行 SLAVEOF no one 命令将其提升为主节点，其他从节点重新配置指向新的主节点。
  • 借助 Sentinel 自动切换：
    • Redis Sentinel 是 Redis 的高可用性解决方案。配置 Sentinel 后，它会监控主从节点状态。当主节点故障时，Sentinel 会自动选举一个从节点升级为主节点，并通知其他从节点重新配置。例如，配置 Sentinel 时需要在 sentinel.conf 中指定 sentinel monitor <master_name> <master_ip> <master_port> <quorum>（quorum 表示判断主节点客观下线需要的 Sentinel 节点数量）等相关参数。

5. 示例用法#

5.1 简单主从复制示例#

  • 环境准备：
    • 假设有两台服务器，服务器 A（IP：192.168.1.100）部署主节点 Redis，服务器 B（IP：192.168.1.101）部署从节点 Redis。
  • 主节点配置（服务器 A 的 redis.conf）：
    • 保持默认配置（主要开启 bind 0.0.0.0 允许其他节点连接等基本配置）。
  • 从节点配置（服务器 B 的 redis.conf）：
    • 添加 slaveof 192.168.1.100 6379。
  • 启动验证：
    • 分别启动主从节点 Redis。
    • 在主节点执行 set key1 value1 命令设置一个键值对。
    • 在从节点执行 get key1 命令，正常情况下会获取到 value1，说明主从复制数据同步成功。

6. 总结#

Redis 主从复制是实现 Redis 高可用性和高性能读操作的重要机制。通过理解其原理（建立连接、数据同步、命令传播），掌握常见实践（配置、监控）和最佳实践（架构规划、切换处理），并结合示例用法，运维人员可以更好地管理 Redis 主从复制架构，保障系统的稳定运行。在实际应用中，要根据业务需求和系统资源合理配置和维护主从复制，同时关注新技术（如 Redis Cluster 等）的发展，不断优化系统架构。

7. 参考文献#

2026-03