Redis 的主从架构和哨兵机制

Redis 的主从架构和哨兵机制是实现高可用的核心方案，能够有效应对节点故障、保证数据可靠性和服务连续性。以下从两者的架构细节、工作原理及高可用保障机制展开详细说明：

一、Redis 主从架构（Master-Slave）

主从架构是 Redis 最基础的高可用方案，通过数据复制实现「一主多从」的部署模式，核心目标是数据备份和读写分离。

1. 架构组成

• 主节点（Master）：
  • 唯一的写入节点，负责处理所有写操作（SET、HSET 等）。
  • 会将写操作记录到「复制积压缓冲区」（replication backlog buffer），供从节点同步数据。
• 从节点（Slave）：
  • 只读节点，不能处理写操作（默认配置，可通过 slave-read-only no 关闭只读，但不推荐）。
  • 通过复制主节点的数据，保持与主节点的数据一致性。
  • 可横向扩展多个从节点，分担主节点的读压力（如查询操作）。

2. 数据复制原理（同步流程）

主从数据同步分为「全量复制」和「增量复制」两种方式，流程如下：

• 初始同步（全量复制）：
  1. 从节点启动后，发送 PSYNC ? -1 命令给主节点（首次同步时无偏移量）。
  2. 主节点收到命令后，执行 bgsave 生成 RDB 快照，并记录此过程中产生的写操作到「复制缓冲区」。
  3. 主节点发送 RDB 快照给从节点，从节点接收后清空本地数据，加载 RDB 恢复数据。
  4. 主节点将 RDB 生成期间的写操作（复制缓冲区中的数据）发送给从节点，从节点执行这些操作，完成数据同步。
• 增量复制：
  • 全量复制完成后，主节点每执行一次写操作，会将操作同步到从节点（通过 TCP 连接持续发送）。
  • 从节点会记录自己的「复制偏移量」（已同步的数据位置），主节点也会记录每个从节点的偏移量。
  • 若从节点因网络波动断开连接，重连后会发送 PSYNC <master-runid> <offset> 命令，主节点通过偏移量判断是否需要增量同步（若偏移量在复制积压缓冲区中，则发送增量数据；否则触发全量复制）。

3. 主从架构的高可用特性

• 数据冗余：从节点备份主节点数据，避免单点故障导致数据丢失。
• 读写分离：读操作分散到从节点，提升整体读性能（主节点专注写操作）。
• 故障转移基础：为主节点故障后的哨兵机制提供「候选从节点」（从节点可晋升为主节点）。

4. 局限性

• 主节点单点风险：主节点故障后，无法自动恢复写操作（需手动将从节点晋升为主节点）。
• 全量复制成本高：首次同步或偏移量失效时，RDB 传输占用带宽，主节点 bgsave 消耗 CPU 和内存。

二、哨兵机制（Sentinel）

哨兵机制是在主从架构基础上实现自动故障转移的组件，解决主节点单点故障问题，核心功能是监控、选主、通知。

1. 架构组成

• 哨兵节点（Sentinel）：
  • 独立的进程（非 Redis 服务），通常部署 3 个或以上（奇数个，避免脑裂）。
  • 负责监控主从节点的健康状态、判断主节点是否故障、自动选主并切换。
• 主从节点：与主从架构中的节点角色一致，哨兵不存储数据，仅通过命令（如 PING、INFO）监控它们。

2. 核心功能

• 监控（Monitoring）：
  • 哨兵通过定期发送 PING 命令检测主从节点是否存活（默认每 1 秒一次）。
  • 若节点在 down-after-milliseconds 时间内（默认 30000 毫秒，即 30 秒）未回复有效响应（如 PONG），哨兵会标记该节点为「主观下线（SDOWN）」。
• 判断客观下线（ODOWN）：
  • 当哨兵认为主节点主观下线后，会向其他哨兵发送「是否认为主节点下线」的询问。
  • 若超过 quorum（配置的投票阈值，如 3 个哨兵中至少 2 个同意），则标记主节点为「客观下线（ODOWN）」，触发故障转移。
• 自动故障转移（Failover）：
  1. 选主（从节点晋升）：从所有健康的从节点中选出一个作为新主节点，选主规则如下：
     • 排除网络连接不稳定的从节点（down-after-milliseconds 内无法通信）。
     • 优先选择「复制偏移量最大」的从节点（数据最新）。
     • 若偏移量相同，选择「运行 ID 最小」的从节点（稳定性优先）。
  2. 主从切换：
     • 哨兵向选中的从节点发送 SLAVEOF no one 命令，使其晋升为主节点。
     • 哨兵向其他从节点发送 SLAVEOF <新主节点 IP> <端口> 命令，让它们从新主节点同步数据。
     • 哨兵更新自身配置，记录新主节点信息，并通过「发布订阅」机制（sentinel:hello 频道）通知客户端新主节点地址。
• 配置中心：哨兵会实时更新主从节点的配置信息，客户端可通过哨兵获取当前主节点地址（无需硬编码主节点 IP）。

3. 哨兵的高可用保障

• 哨兵集群容错：
  • 哨兵节点本身也可能故障，因此需部署多个哨兵（推荐 3 个），通过「投票机制」避免单哨兵误判。
  • 若哨兵集群中超过半数节点故障，将无法执行故障转移（因此需保证哨兵节点的可用性）。
• 脑裂防护：
  • 主节点因网络分区暂时与哨兵隔离，但仍在处理客户端写操作，此时若哨兵选举新主节点，会导致「双主」问题（数据不一致）。
  • 解决方案：通过配置 min-replicas-to-write <num> 和 min-replicas-max-lag <seconds>，要求主节点必须有至少 num 个从节点在 seconds 内正常同步，否则拒绝写操作，避免脑裂时的数据混乱。

三、主从 + 哨兵的整体高可用流程

1. 正常运行：主节点处理写操作，从节点同步数据并分担读操作，哨兵实时监控所有节点。
2. 主节点故障：
   • 哨兵检测到主节点主观下线，通过投票确认客观下线。
   • 哨兵从健康从节点中选举新主节点，执行主从切换。
3. 故障恢复：
   • 原主节点修复后，哨兵会将其降级为新主节点的从节点，从新主节点同步数据。
   • 客户端通过哨兵获取新主节点地址，继续正常读写。

四、关键配置参数（高可用优化）

五、总结

• 主从架构通过数据复制实现读写分离和数据备份，但无法自动处理主节点故障。
• 哨兵机制在主从基础上实现自动故障转移，通过监控、选主、切换确保服务连续性，是 Redis 高可用的核心方案。
• 实际部署中，需结合两者并合理配置参数（如哨兵数量、复制缓冲区大小、脑裂防护），才能最大化高可用效果。

在 Redis 哨兵（Sentinel）机制中，新增从节点后，哨兵会自动识别到，但需要满足一定的配置条件，具体细节如下：

1. 自动识别的核心机制：哨兵的“监控与发现”能力

哨兵的核心功能之一是监控 Redis 主从节点的状态，其自动发现新从节点的逻辑基于以下两点：

• 从节点与主节点的关联关系：新从节点启动时，会通过 slaveof <master-ip> <master-port> 命令（或配置文件中的 replicaof 配置）与主节点建立复制关系。主节点会记录所有与之相连的从节点信息。
• 哨兵对主节点的定期探测：哨兵会定期（默认每 10 秒）向主节点发送 INFO replication 命令，该命令的返回结果中包含主节点当前所有从节点的 IP、端口等信息。哨兵通过解析该结果，即可发现新加入的从节点。

2. 关键前提：从节点需能被哨兵访问

哨兵要成功识别新从节点，需确保从节点的网络对哨兵可见：

• 从节点的 bind 配置不能限制哨兵的 IP 访问（建议生产环境中避免绑定过严格的 IP，或明确允许哨兵节点的 IP）。
• 从节点的端口（默认 6379）需在防火墙中开放，允许哨兵节点的连接。
• 若从节点设置了密码（requirepass），需在哨兵配置中通过 sentinel auth-pass <master-name> <password> 配置对应密码，否则哨兵无法与从节点建立通信。

3. 识别后的操作：哨兵对新从节点的处理

当哨兵通过 INFO replication 发现新从节点后，会自动执行以下操作：

• 添加到监控列表：将新从节点纳入哨兵的监控范围，开始定期向其发送心跳检测（PING 命令，默认每 1 秒一次）。
• 同步状态信息：哨兵之间会通过“发布-订阅”机制（在 __sentinel__:hello 频道）共享新从节点的信息，确保所有哨兵实例都能感知到该从节点的存在。
• 参与故障转移：若后续主节点故障，新从节点会被纳入故障转移的候选节点列表，哨兵可能会将其选举为新主节点（取决于优先级、复制进度等条件）。

4. 特殊场景：从节点作为“二级从节点”的识别

如果新增的从节点是“二级从节点”（即它以另一个从节点为复制源，slaveof <slave-ip> <slave-port>），哨兵仍能识别它，但会将其归类为“从节点的从节点”。此时：

• 哨兵仍通过主节点的 INFO replication 发现它（因为二级从节点的信息会被其上级从节点同步到主节点）。
• 在故障转移时，二级从节点通常不会被优先选为新主节点（除非其复制进度与主节点接近且优先级较高），但哨兵会确保它在新主节点产生后，自动切换复制源为新主节点。

总结

只要新从节点正确连接到主节点且网络可达，哨兵会通过定期探测主节点的复制信息自动识别它，无需手动配置哨兵与新从节点的关联。这一机制保证了 Redis 主从架构的扩展性——新增从节点时，无需重启哨兵或修改哨兵配置，即可无缝融入高可用体系。