摘要
Active-Active 与 Active-Passive 是数据库高可用设计的两种根本性架构。本文系统解析两者的工作机制、核心取舍与故障切换代价，并给出基于 RTO/RPO 的决策框架。Active-Passive 以单写入者简化一致性，代价是切换期间的可用性缺口；Active-Active 消除晋升步骤、实现更低 RTO，但需处理并发写入冲突。
当数据库服务突然中断，用户请求大面积报错，业务指标断崖式下跌，而值班工程师只能盯着监控屏幕上迟迟未能完成的故障切换流程。六个月前的架构选型，此刻正决定这是一场分钟级恢复的小波动，还是一次小时级瘫痪的重大事故。
Active-Active 与 Active-Passive 是应对数据库高可用需求的两种根本不同的技术路线。本文将系统梳理两种架构的工作机制、核心取舍，并重点解析 Redis 在 Active-Active 场景下的工程实现。
一、高可用的本质：从”几个9″到 RTO/RPO
高可用（High Availability）并非一个抽象概念，其本质是通过冗余设计、备用设备与故障切换机制，确保数据库在部分组件失效时仍能持续对外提供服务。业界通常以”9″的个数来量化可用性等级，而每增加一个”9″，工程成本呈指数级上升。
| 可用性等级 | 年最大停机时间 | 月最大停机时间 |
| 99%（两个9） | 约 87.6 小时 | 约 7.2 小时 |
| 99.9%（三个9） | 约 8.76 小时 | 约 43.8 分钟 |
| 99.99%（四个9） | 约 52.6 分钟 | 约 4.4 分钟 |
| 99.999%（五个9） | 约 5.26 分钟 | 约 26 秒 |
需要清醒认识的是：从 99.99% 提升到 99.999% 的工程投入，远大于从 99% 提升到 99.9%。不存在 universally correct 的可用性等级，只有与业务损失模型相匹配的经济最优解。
两个指标定义了故障恢复的具体形态：恢复时间目标（RTO） 指系统中断至业务不可承受的最大时长；恢复点目标（RPO） 指故障后可接受的数据丢失量，即最后一次成功持久化的时间点。
RTO 与 RPO 直接受复制架构制约。同步复制可将 RPO 压降至接近零，但会以写入延迟为代价；异步复制降低了延迟，却在故障瞬间产生等于复制滞后时长的 RPO 缺口。这一底层权衡，使得 Active-Active 与 Active-Passive 的选型绝非简单的技术偏好问题。
二、Active-Active 架构：消除单点与写入冲突的博弈
将 RTO 压向零的一个直接思路，是彻底消除主从切换步骤。Active-Active 架构下，多个节点同时在线运行，每个节点均具备读写能力，不存在单一主节点。当任一节点故障时，流量可直接由其余健康节点承接，无需等待备用节点晋升。该架构在部分文献中亦被称为多主（Multi-Master）或双向复制（Bi-directional Replication）架构。
其收益在故障场景下最为显著：所有节点本就处于活动状态，流量切换无需经过晋升流程，因此设计良好的 Active-Active 部署通常能够达到远低于 Active-Passive 的 RTO。
并发写入的处理
Active-Active 架构必须解决的核心问题是并发写入冲突。当多个节点同时接受写请求时，同一记录可能在不同节点被并行修改，若缺乏消解策略，反向序处理将导致各节点数据状态不一致。
业界已形成两类成熟的冲突消解策略。Last Writer Wins（LWW） 最为简洁：以时间戳最新的操作作为最终状态。该策略适用于部分场景，但在两次更新均承载有效业务信息时会造成数据丢失。Conflict-free Replicated Data Types（CRDTs） 则更为鲁棒：通过构造天然满足交换律的操作集合，使得同一批更新无论以何种顺序应用，最终均收敛至一致状态，无需在应用层介入冲突仲裁。
三、Active-Passive 架构：简单性背后的故障切换代价
Active-Passive 采取与 Active-Active 截然相反的设计哲学。这是传统高可用的经典范式：单一主节点承担全部写入，副本节点处于待命状态；主节点故障时，某一副本被提升为新的主节点。该模式在部分语境下亦称为主从（Active-Standby）或 Primary-Replica 架构。
其优势在于简洁性。单写入者设计天然规避了并发冲突，一致性模型直观且易于推理。
故障演练的可操作性
Active-Passive 架构的故障切换路径固定（一次晋升操作加一次流量重路由），团队可以将其脚本化、定期演练，并在合规审计中提供明确的恢复规程，不确定性相对较低。
故障切换并非瞬时完成
简洁性的代价是切换期间的可用性窗口。据生产环境实践反馈，计划内切换配合请求缓冲可在 10 秒内完成；非计划故障切换通常耗时 30 秒以内，应用层在此期间将感知到错误响应。
更为隐蔽的风险在于待命节点可能无法在关键时刻承担生产负载。2012 年 GitHub 的一次事故中，高负载主节点触发自动切换，但晋升后的次级节点缓存处于冷态，无法消化生产流量，集群最终被迫回切。该待命节点此前从未在生产负载下得到验证。
故障切换机制本身亦可能成为故障源。同一报告指出，某次协议缺陷导致美东区域约 2.5% 的多可用区数据库未能成功执行故障切换。百分比虽小，但对命中该缺陷的团队而言即为完全中断。
四、核心差异与选型决策框架
基于上述故障模式，架构选型应回归一致性需求、地理分布特征与停机容忍度三个维度。
| 维度 | Active-Passive | Active-Active |
| 写入节点 | 仅主节点 | 多节点具备写入能力 |
| 故障切换机制 | 心跳检测 → 晋升 → 重路由 | 部分设计下直接重路由，无需晋升 |
| RTO | 优化良好的热备系统可达秒级；通常分钟级 | 设计良好的部署显著更低，已消除晋升步骤 |
| RPO（异步复制） | 取决于复制滞后（秒至分钟级） | 部分设计良好的部署可接近零，取决于复制模型与网络条件 |
| 写入冲突 | 设计上不存在 | 需显式消解策略 |
| 一致性模型 | 单写入者设计；一致性取决于复制与读取路径 | 最终一致性或强最终一致性 |
| 写入扩展性 | 仅垂直扩展 | 视工作负载、冲突模式与实现而定，可水平扩展 |
| 备用节点利用率 | 正常状态下空闲 | 全节点承载流量 |
| 资源成本 | 为保险支付闲置容量；主节点未跑满时单请求成本较低 | 全节点持续服役，前期投入更高，但规模扩大后单请求成本更优 |
| 运维复杂度 | 较低 | 较高（冲突消解、拓扑设计） |
一个简化的决策框架如下：
- RTO 与 RPO 要求极为严苛：若无法接受主从切换的等待时间，Active-Active 值得重点评估。
- 秒级至分钟级 RTO 可接受：Active-Passive 通常足够，前提是备用节点为热备状态且定期演练。
- 用户集中于单一地域：单写入者一致性往往使 Active-Passive 更具吸引力。
- 用户全球分布：Active-Active 可降低跨区域写入延迟。
- 预算受限、负载中等：Active-Passive 在单主节点即可覆盖典型负载时更具成本效益。
需要强调的是，两种架构并非互斥。生产环境中常见的混合模式是：跨区域采用 Active-Active 保障全球可用性，而每个区域内部采用 Active-Passive 实现本地高可用。
五、Redis Active-Active 的技术实现：CRDT 与强最终一致性
当 Active-Active 成为架构选型的结论，具体实现方案仍需谨慎评估。Redis 在 Redis Software 与 Redis Cloud（不含 Redis 开源版）中提供的 Active-Active Geo Distribution 功能，底层基于 Conflict-free Replicated Database（CRDB）构建。一个全局数据库横跨多个集群，每个集群承载一个 CRDB 实例，所有写入通过双向网状复制同步至其余实例。
其实现差异集中体现在冲突消解层。Redis 并未对所有数据类型统一套用 LWW，而是将每种支持的数据类型映射至专用的 CRDT，并基于数据类型的业务语义设计消解规则：
- 计数器（Counters）：采用满足交换律的自增操作，天然无冲突，来自两个区域的并发增量均会被计入。
- 集合（Sets）：采用 add-wins 语义，并发添加操作优先于并发删除操作。
- 哈希（Hashes）：对不同字段的更新独立消解，不同区域并发修改哈希的不同字段不会产生冲突。
在适用上述内置消解规则的场景下，CRDT 层直接在数据引擎内部完成冲突仲裁，显著降低了应用层需要承载的冲突处理逻辑。
Redis Active-Active 基于 Strong Eventual Consistency（SEC，强最终一致性） 运行：一旦所有副本接收到同一组更新，无需共识协议即可收敛至相同状态。对于特定键需要顺序保证的工作负载，Redis 亦提供因果一致性（Causal Consistency）作为可选特性，但启用后将带来额外的网络与内存开销。
在本地操作延迟方面，在典型条件下，各区域内的读写延迟均可保持在亚毫秒级。
六、常见问题
Q：Active-Active 与 Active-Passive 的根本区别是什么？
A：Active-Active 同时运行多个具备写入能力的节点；Active-Passive 则将写入集中于单一主节点，备用节点处于待命状态。
Q：哪种架构切换更快？
A：设计良好的 Active-Active 部署通常能实现更低的 RTO，因为流量可直接重路由而无需晋升备用节点。Active-Passive 的恢复通常耗时数秒至数分钟，取决于故障切换设计。
Q：Active-Active 是否必然引入冲突消解？
A：若多节点同时接受写入，冲突消解策略不可或缺。常见方案包括 LWW 与 CRDT。
Q：两种架构能否共存？
A：可以。生产环境中常见的模式是：跨区域采用 Active-Active，各区域内部采用 Active-Passive。
Q：哪种更具成本效益？
A：取决于负载特征。Active-Passive 在单主即可覆盖典型负载时往往更省成本，因为备用节点仅作为保险。Active-Active 在规模扩大后通常单请求成本更优，因为所有付费节点均处于服役状态。
Q：何时 Active-Passive 更为合适？
A：当单写入者一致性最为关键、用户集中于单一区域、且短暂切换中断可接受时，Active-Passive 通常是更优解。
Redis Active-Active 能否完全消除应用层冲突逻辑？
A：并非对所有工作负载均可。Redis 能够在支持的数据类型范围内减少应用层冲突处理，但跨对象事务与不支持的模式仍需要应用层关注 CRDT 的边界条件。
结语
架构选型的核心在于识别业务无法承受的损失类型。Active-Passive 以简洁性与单写入者模型为卖点，代价是故障切换期间的短暂可用性缺口。Active-Active 则面向低 RTO、全容量利用与区域本地写入延迟等需求设计。
若短暂的切换中断在业务可接受范围内，且用户集中于单一区域，Active-Passive 是务实的选择。若用户全球分布、可用性目标指向五个9、或希望彻底规避主从晋升流程，Active-Active 则应进入评估清单。
Redis 将 Active-Active 的实现建立在数据类型级别的 CRDT 之上，使得多数团队原本需要在应用层处理的冲突消解逻辑，下沉至数据引擎内部执行。这一设计取向，与那些无法容忍停机与数据丢失的实时业务负载高度契合。
如需验证 Active-Active Geo Distribution 在自身工作负载下的表现，可通过 itbigtec 官方渠道申请试用，或联系我们的架构团队进行高可用方案咨询。
