" />
文章

Redis 多节点模式详解

Posted recently Updated recently
By Administrator
17~22 min read

以下是一篇将「Redis三种模式（主从、哨兵、Cluster）在多节点部署、故障与恢复流程、数据一致性、网络分区等问题」综合整理的详细说明文章，涵盖从基础概念到典型故障场景以及常见的解决思路。

Redis 多节点模式详解

Redis 在实际生产环境中常用的多节点部署模式主要包括：

  1. 主从模式（Master-Slave）
  2. 哨兵模式（Sentinel）
  3. 集群模式（Cluster）

这些模式在处理故障、保障高可用、实现数据同步时各具特点。本文将详细介绍这三种模式的工作机制、故障场景下的处理流程、数据一致性策略，以及网络分区（特别是跨机房部署）可能带来的问题与应对方案。

一、主从模式（Master-Slave）

1.1 基本概念

  • Master：负责写操作，也可以提供读操作。
  • Slave：通过与 Master 的复制（Replication）保持数据同步，通常只提供读操作（也可配置为读写，但不推荐）。

1.2 故障场景

  1. Slave 故障
    - 只要 Master 存活，写操作依然可用；剩余的其他 Slave 也可继续读。
    - 当故障 Slave 恢复后，会通过全量或部分复制从 Master 拉取缺失数据，然后恢复一致。
  2. Master 故障
    - 如果没有自动化机制（如 Sentinel），需要手动地将某个 Slave 升级为新的 Master；在此过程中写服务会不可用。
    - 原 Master 恢复后，一般要改为 Slave 并向新的 Master 同步数据，否则易产生冲突。

1.3 数据一致性与丢失

  • Redis 原生主从复制是异步的：Master 写入后立刻返回客户端，不等待 Slave 同步完成。如果 Master 在写请求尚未同步给 Slave 时宕机，可能丢失这部分数据。
  • 可以开启 AOF（Append Only File）或者 RDB（快照）持久化来减少丢失风险，但若在内存写完、还没同步就宕机，依旧可能产生丢失。

1.4 如何提高高可用

  • 手动切换耗时且易出错，生产环境往往不会只靠纯主从模式。
  • 可以通过 Redis Sentinel 或其他高可用管理系统，来实现自动故障转移，减少人为干预时间。

二、哨兵模式（Sentinel）

2.1 Sentinel 的作用

  • 监控：哨兵进程会持续监控 Master 和所有 Slave 的存活状态。
  • 自动故障转移：当哨兵判定 Master 宕机时，会选举某个 Slave 升级为新 Master，通知其他 Slave 也去同步这个新的 Master。
  • 通知：通过发布订阅或其他接口向外部系统发送警报和通知。

2.2 故障场景及恢复

  1. Master 故障
    - Sentinel 投票决定将某个 Slave 升为新的 Master，其余 Slave 统一改为复制该新 Master。
    - 故障转移一般需要多个哨兵（满足 quorum）达成一致后触发，减少误判。
  2. Slave 故障
    - 不影响写操作；该 Slave 恢复后会自动跟 Master 对齐数据。
  3. 原 Master 恢复
    - 一般会被降级为 Slave，并向当前的新 Master 发起复制拉取。可能是部分复制（PSYNC）也可能是全量复制。如果原 Master 在宕机期间产生了写落后，就会通过这次复制进行“数据合并”。

2.3 数据一致性与潜在风险

  • 仍是基于异步复制；在 Master 未完成同步就宕机时，可能丢失少量写操作。
  • 若在极端网络分区情况下，Sentinel 可能发生脑裂（Split-Brain）——多数派哨兵和少数派哨兵分别认定“自己的 Master”是活的，从而出现两个 Master 并行写的严重冲突。一旦网络恢复，这两方 Master 的数据差异需手动解决。

2.4 生产环境建议

  • 部署奇数个哨兵，并确保 Master/Slave 与哨兵之间有可靠网络，最大程度避免一分为二。
  • 在多机房场景下，将大多数哨兵放在核心机房（或能够保证网络稳定的机房），减少网络分区导致的双主概率。

三、集群模式（Cluster）

3.1 集群模式简介

  • Redis Cluster 将 16384 个哈希槽（slots） 分片分配给各个 Master，每个 Master 负责一部分槽及其数据。
  • 每个 Master 通常也有若干 Slave，用来承载副本并在 Master 故障时自动接管。

3.2 三节点集群的最小示例

  • 在最简的 3 节点集群 中，往往只有 3 个 Master（各分配一部分槽），没有从节点；数据分散在 3 台机器上。
  • 若其中一个 Master 宕机，该部分槽会暂时不可用，集群可能仍能对外提供部分可读写服务（但丢失了 1/3 的数据分片）。

生产环境更常见的是 6 个节点：3 Master + 3 Slave，保证每个 Master 有至少一个可用副本，故障转移更加平滑。

3.3 故障场景与恢复

  1. 某 Master 宕机
    - 如果有 Slave，集群通过投票（超过半数 Master 同意）让其从节点升级为新的 Master；
    - 如果没有 Slave，则对应槽暂时不可读写，直到该 Master 恢复或者做手动 reshard。
  2. 原 Master 恢复
    - 如果已经有新的 Master，原 Master 会被降级为从节点（Slave），并向新 Master 发起复制，拿到缺失数据。
    - 若是 3 台纯 Master 场景，则不存在谁同步谁的问题——每个节点只负责自己那部分槽的数据即可。如果本地数据还在，恢复后自动载入；若丢失，需要手动修复或重新分配槽。

3.4 防止脑裂的机制

  • Redis Cluster 判断可写性的条件是：是否有超过一半的 Master 节点可以互相通信并认为对方在线。
  • 在出现网络分区时，少数派分区（Master 节点数量 < 总数一半）会自动拒绝写操作，从而避免了“多个分区各自写入”的双主冲突。
  • 因此，Redis Cluster 默认情况下能够最大程度地防止真正的 Split-Brain 所导致的“两个活跃 Master 并行写”。它采用“牺牲一部分可用性，换取数据一致性”的分布式思路。

四、网络分区（Split-Brain）问题

4.1 Sentinel 场景下的脑裂

  • 如果多个哨兵被分隔在不同分区，而每个分区都无法看到原 Master 的真实状态，或者哨兵投票无法跨分区协商，就可能出现

双主写

：

  1. 少数派分区会以为 Master 不可达，提升本分区某个 Slave 为 Master；
  2. 原 Master 可能在另一个分区照常工作；
  3. 导致两个 Master 并行接收写请求，最终产生数据冲突。

4.2 Cluster 场景下的脑裂

  • Cluster 模式通过“少数派分区自动停止写请求”来尽可能避免双主；要发生双主，需要极端配置错误或严重网络故障。
  • 一般而言，小于一半 Master 的分区会拒绝写入，大部分 Master 所在分区继续写，从而避免数据冲突。

4.3 跨机房部署建议

  1. 保证奇数个核心节点/哨兵，确保当发生网络故障时，大多数派能达成一致；
  2. 尽量使用稳定的专线或多通道冗余网络，降低大范围分区概率；
  3. 部署拓扑：保证主节点与多数哨兵或多数 Master 节点在同一个核心机房，或者在多个机房中合理分布节点数量，确保一个机房挂了也不影响多数派判断。

五、数据合并与一致性策略

5.1 主从模式下的数据同步

  • Master -> Slave 异步复制；Slave 故障恢复后向 Master 请求复制，可能执行部分或全量同步。
  • Master 故障后手动切换时，需要先把旧 Master 变成 Slave，再同步新 Master 的数据。

5.2 Sentinel 模式下的数据合并

  • 当 Master 宕机并由某 Slave 变为新 Master 后，原 Master 恢复会自动降级为 Slave，通过复制向新 Master 拉取在它宕机期间产生的增量数据，从而完成“合并”。

5.3 Cluster 模式下的数据合并

  • 如果有 Slave：Master 宕机时，Slave 升级为 Master；原 Master 恢复后成为 Slave，进行主从复制拿到缺失数据。
  • 如果没有 Slave：每个 Master 只负责自己的槽，不存在跨节点数据合并；只要恢复后依旧持有本地数据，即可继续提供那部分槽的服务，若数据丢失需手动干预。

5.4 一致性加强手段

  • AOF 持久化：在磁盘级别减少宕机丢失数据。
  • min-replicas-to-write 或 WAIT 命令：让写操作等待一定数量的 Slave 同步完成后再返回成功，减少异步带来的丢失风险（但写延迟上升）。
  • 集群层级容灾：在对数据零丢失有更高要求的场景下，可结合多机房部署及额外的外部复制手段（如外部数据库、多副本存储）来保证强一致性。

六、总结

  1. 主从（Master-Slave）模式
    - 简单易用，但需要手动切换应对 Master 故障。没有自动化容错机制，适用于数据一致性要求不高或场景简单的情况。
  2. 哨兵（Sentinel）模式
    - 在主从基础上增加自动故障转移与监控。大大提升高可用性，但仍是异步复制，并且在极端网络分区情况下会面临双主（Split-Brain）的风险。
  3. 集群（Cluster）模式
    - 分片存储 + 多 Master + 多从节点来解决数据量大与高可用问题。
    - 通过要求“半数以上 Master 存活且互通”才能继续写，较好地避免了脑裂。
    - 生产环境下通常至少 6 个节点（3 主 + 3 从）起步，以保证高可用与副本切换的能力。
  4. 网络分区
    - 对 Sentinel 模式是最危险的（可能双主写）；
    - 对 Cluster 模式影响是少数派停止写入，牺牲一部分可用性换取一致性；
    - 合理的节点数量、奇数仲裁以及可靠的跨机房网络设计，是预防大规模分区导致脑裂的关键。
  5. 数据合并与同步
    - 主要通过 Master-Slave 复制实现；节点恢复后往往要从活跃的 Master 拉取增量或全量数据，以达成最终一致性。
    - 大多数场景下，开启持久化并合理配置复制策略可以最大程度降低丢失。

结语

Redis 的三大模式（主从、哨兵、集群）在处理多节点部署和高可用时各具优缺点。

  • 主从模式适合简单场景或只需读写分离的情况。
  • 哨兵模式在主从之上提供自动化高可用，部署也相对简便，是较常用的中小规模高可用方案。
  • 集群模式适合大规模数据存储与高可用需求，天然分片，扩展性好，并通过多数派机制减少脑裂风险。

实际生产环境中，如何取舍依赖业务需求、数据规模、运维能力和网络拓扑。无论哪种模式，为了降低故障和避免数据丢失，都需要定期备份、完善监控、多节点冗余以及可靠的网络做支撑。希望本文对全面了解 Redis 多节点模式在故障处理、数据同步、脑裂问题等方面的实践有所帮助。

技术分享
License:  CC BY 4.0