高可用架构：主备/主主/多活架构

可视化演示

对比主备、主主与多活三种高可用架构的复制拓扑、故障切换与RPO/RTO取舍，理解不同场景下的选型思路，可切换三种模式。

高可用核心指标：先把评星标准定下来

做高可用之前，先要回答一个基础问题：“高到什么程度才算够用？”这就像餐厅想评米其林星级，评审员看两条硬指标：一是遇到火灾后要停业多久才能重新开张，二是重新开张后，已经点过但还没上桌的菜单还能不能保住。落在技术上，第一条叫 RTO（恢复时间目标），衡量从故障发生到服务恢复所花的时间；第二条叫 RPO（恢复点目标），衡量故障发生后最多允许丢失多少已写入的数据。

这两个指标像一把尺子，量出了后厨团队的“救场能力”。RTO=0 意味着永不中断，RPO=0 意味着一个字节都不丢。真实世界里它们都做不到绝对零，所以要允许“可容忍的损失”。数据丢失量可以用一个简单公式估算：

可用性等级则是另一个通行标尺，它描述系统在一年中正常服务的时间占比：

这几个数字让“评星标准”变得可量化：4 个 9 是大型互联网公司的及格线，5 个 9 就需要多活架构和自动切换支撑了。

主备架构：一位主厨，一位待命副厨

主备架构像一家餐厅配了两位厨师：主厨掌勺出菜，副厨不碰炒锅，只在一旁备菜、洗料、熟悉菜谱，保证随时能接班。主厨手一滑切了手指，副厨需要几分钟穿上围裙上场——这“几分钟”就是 RTO，而副厨之前备好的那批菜料就是 RPO，从副厨上一次备料到主厨倒下的这段时间里没来得及准备的菜，就损失掉了。

工程上，主节点接收全部读写流量，备节点通过单向复制持续同步主节点的数据。两者之间靠心跳检测维持联系：主节点每隔几秒向备节点发一个“我还活着”的信号，备节点连续几次收不到，就判定主节点故障。此时进入 DNS 切换流程——把域名解析从主节点 IP 换成备节点 IP，引导新流量到备机接管。整个切换时间可拆解为三段：

主备架构的最大优点是简单可靠、设计直观，最大缺点是备机平时不承接流量，服务器资源白白闲置；同时主备切换存在秒级到分钟级的停机窗口。它适合业务对成本敏感、能容忍短暂中断的场景，比如内部管理系统、中小网站的后端数据库。

主主架构：两个灶台同时炒菜

要不要试试让两位主厨同时掌勺？这就是主主架构的设想：两家灶台都通电，都能独立出菜，后厨效率理论上翻倍。但问题来了——当两位主厨同时要做“红烧肉”，一个放糖一个放盐时，到底听谁的？在技术世界这叫写冲突：两个节点同时对同一条数据做修改，双向复制时互相覆盖，最终数据变成“谁同步晚谁赢”的混乱状态。

为了解决冲突，常见策略有时间戳后写覆盖（最后写入者胜）、CRDT 结构化合并（把修改合并成无冲突的数据结构），以及更工程化的用户分片——按用户 ID 哈希取模，让同一个用户的写请求永远落到同一个节点。分片让“两个主厨各管一摊菜”，从根源上避免抢烤箱：

主主架构适合写流量可以被明确拆分的场景，比如按地域、租户或用户维度分片，能有效利用两个节点的资源。但如果业务存在大量无法分片的全局数据，写冲突会变成频繁事故，让系统复杂度飙升。

多活架构：直接开连锁分店

多活架构是把后厨从一家店变成多家连锁分店：每家店都能独立接客、独立做菜，顾客就近进店，不用等远程调度。分店之间通过“总店菜谱”（数据异步复制）保持最终一致，某一分店停电了，顾客走两步去隔壁分店即可，服务不中断。

多活架构的核心理念是多副本同时对外服务，配合全局流量调度（如 GSLB）把用户按地域或负载分发到不同节点。由于副本间是异步复制，各节点的数据存在短暂不一致：

当节点数量多、业务单元化时，还会引入单元化部署设计：把用户按 ID 划分成若干个“单元”，每个单元的数据和流量在自身闭环，跨单元交互降到最低。多活架构提供最高的可用性，但代价是最终一致性、复杂的流量调度和较高的网络成本。

架构选型决策：看客单价选模式

选主备、主主还是多活，本质上和餐厅选址一样：开在旅游景区的网红店，停业一小时就损失上万，必须上多活；社区楼下的早餐铺，停业半天顾客也能改天再来，主备足够。选型的核心是两个轴：业务对 RTO/RPO 的容忍度，以及愿意为高可用支付的成本。

高可用没有免费午餐。主备简单但浪费一台备机，主主提升效率但引入冲突处理，多活可用性最高但要求数据最终一致。复制流量是决定成本的关键因素之一：

普遍的选型规律是：RPO=0 且 RTO 秒级 → 同城双活 + 同步复制；RPO 分钟级且 RTO 分钟级 → 主备 + 异步复制；跨地域用户就近访问 → 多活 + 最终一致。没有最好的架构，只有最匹配业务目标的组合。

工程实践复盘：消防演习不能停

再完美的架构设计，如果没有持续演练，故障来临时仍会手忙脚乱——就像餐厅消防通道画得再漂亮，不实际跑几次火灾演习，真着火时员工照样找不到灭火器。高可用的工程实践因此强调“用演练验证设计”。

混沌工程是主动注入故障（杀进程、断网、断电）来验证系统韧性；监控告警围绕可用性、延迟、同步延迟等指标实时预警；切换自动化把人工操作脚本化，避免故障时“手抖点错按钮”。多副本冗余的价值可以用并联可用性公式量化：

典型的案例复盘是某大型电商在双 11 大促前，对核心订单单元执行了随机的机房断电演练：第一次演练发现 DNS 缓存 TTL 设置过长导致切换花了 10 分钟，紧急调短 TTL 并预推 DNS 记录后，第二次演练把切换时间压缩到 40 秒。这正是“演练 → 发现问题 → 改进 → 再演练”循环的价值——高可用不是装修出来的，是反复“逼”出来的。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""高可用架构故障切换模拟器：对比主备、主主、多活在节点故障时的表现"""import random  class Node:    def __init__(self, name):        self.name = name        self.alive = True     def handle_request(self, req_id):        return self.alive  class FailoverSimulator:    def __init__(self, arch_type):        self.arch_type = arch_type        self.nodes = [Node("A"), Node("B")]        if arch_type == "multi":            self.nodes.append(Node("C"))        self.request_count = 0        self.success_count = 0        self.switch_count = 0        self.pending_switch = 0     def send_request(self, req_id):        self.request_count += 1        # 主备在切换窗口内的请求会失败        if self.arch_type == "active_standby" and self.pending_switch > 0:            self.pending_switch -= 1            return False        if self.arch_type == "active_standby":            candidates = [0] if self.nodes[0].alive else [1]        else:            candidates = [i for i, n in enumerate(self.nodes) if n.alive]        if not candidates:            return False        ok = self.nodes[random.choice(candidates)].handle_request(req_id)        if ok:            self.success_count += 1        return ok     def fail_node(self, index):        self.nodes[index].alive = False        self.switch_count += 1        # 主备需要额外切换窗口，主主/多活即时转移        if self.arch_type == "active_standby":            self.pending_switch = 3     def recover_node(self, index):        self.nodes[index].alive = True  def run_experiment(arch_type, total=200):    sim = FailoverSimulator(arch_type)    for req_id in range(total):        if req_id == 50:            sim.fail_node(0)        elif req_id == 100:            sim.recover_node(0)        elif req_id == 150 and arch_type == "multi":            sim.fail_node(2)        sim.send_request(req_id)    loss = sim.request_count - sim.success_count    print("架构: %s | 请求: %d | 成功: %d | 失败: %d | 切换: %d"          % (arch_type, sim.request_count, sim.success_count, loss, sim.switch_count))    return loss  if __name__ == "__main__":    print("=== 高可用故障切换模拟 ===\n")    for arch in ["active_standby", "active_active", "multi"]:        run_experiment(arch)    print("\n主备在切换窗口会丢请求；主主/多活故障转移更平滑。")

1. candidates = [0] if self.nodes[0].alive else [1]主备架构下，只有主节点活着才接收请求，主挂了才轮到备机。
2. if self.arch_type == "active_standby" and self.pending_switch > 0:主备切换期间请求会失败，模拟 RTO 窗口。
3. candidates = [i for i, n in enumerate(self.nodes) if n.alive]主主/多活从所有存活节点中选一个，故障转移即时生效。
4. sim.fail_node(0)在第 50 个请求时让 0 号节点宕机，触发高可用切换。

常见误区

面试题