主备、双活、多活有什么区别？

简化版

主备通常只有主站点承接写流量，备用站点同步数据并在故障后接管；双活让两个站点同时承载业务；多活把同样能力扩展到三个及以上故障域。越“活”并不天然越可用：并发写冲突、数据路由、网络分区和回切复杂度都会上升，选择应由 RPO、RTO、延迟、数据一致性和成本共同决定。

主备控制面和写路径最简单，故障前备用容量利用率低，切换时间取决于检测、数据追平、提升和流量迁移。双活常按用户、租户或地域把写主归属固定在一个站点，另一站承载自己的分区；若允许同一数据跨站并发写，就必须有共识或冲突解决机制。

多活还要求全局流量调度、故障域隔离、跨地域数据复制、容量冗余和可逆回切。不能只看“有几个机房”，而要回答每份数据谁能写、站点失联时哪一侧继续、恢复后如何对账。真正验收依靠故障演练下的 RPO/RTO，而不是架构名称。

主备是一主工作、一备待命；双活是两个站点同时对外；多活是三个以上站点同时承担生产流量。这里的“活”必须落实到真实业务流量，只有健康检查但不承载请求的站点仍是备用。读流量双活、写流量单主也应明确称为“读双活、写主备”。

记忆钩子：先问“谁在接流量”，再问“谁有写权”，不要被“双活”两个字跳过数据语义。

正常：Client -> Primary -> async/sync replication -> Standby
故障：检测 -> fencing 旧主 -> 追平/选新主 -> 切流 -> 验证

主备的关键不是启动备用进程，而是先剥夺旧主写权。网络分区时若旧主仍写、新备也接管，就会形成脑裂。备用站点还要定期承接演练流量，否则配置漂移和容量不足只会在事故时暴露。

最常见方案是按 userId/tenantId/region 固定主归属，每个数据分区只有一个写站点，另一个站点可读副本或承载其他分区。若 A、B 都能修改同一账户，必须使用跨站共识、全局锁或可证明的合并规则；跨地域 RTT 会直接进入写延迟。

异步主备复制落后 3 秒，主站永久损坏时 RPO 最坏约 3 秒；检测 20 秒、提升 40 秒、DNS/流量收敛 60 秒，则 RTO 至少约 120 秒。改成同步跨站复制可压低 RPO，却可能给每次写增加一到多个广域 RTT。

双活如果站内写、本地响应、异步跨站，正常延迟好，但站点失效后仍面临复制缺口。架构名无法消除 CAP 取舍，只是把取舍放在不同路径上。

两个站点各跑 50% 流量且资源利用率 70%，任一站故障后剩余站点需要瞬间承担 100%，理论利用率可能升到 140%，所谓双活会立刻二次故障。要按 N-1 容量规划，或预先设计非核心降级与快速扩容。

多活同样要按目标故障域计算剩余容量。三站各承担 1/3，失去一站后其余两站各接近 1/2；缓存冷启动、连接数和下游容量也必须一起验算。

站点恢复后不能立即把流量切回。先核对日志水位、修复缺失或冲突数据、预热缓存，再用 1%、5%、20% 阶梯回流。切换期间生成的新数据必须有明确回补方向，旧站点不能凭旧快照覆盖新主数据。

监控包括复制 lag、站点流量、写归属违规、冲突数、fencing 状态、容量余量和切换阶段。每次演练需记录实际 RPO/RTO，并把失败步骤回写 Runbook。

主备、双活、多活要沿“流量、写权、复制、容量、切回”比较：谁接请求、同一数据由谁写、复制缺口多大、失去故障域后是否扛得住、恢复后怎样安全回流。名称只是拓扑标签，实际 RPO/RTO 和演练结果才是高可用证据。

面试作答时可先给出拓扑定义，再主动补一句“活跃站点数量不等于数据写主数量”，这能避免把服务双活误说成数据库多主。