一、高可用架构概述

什么是高可用

高可用，说白了就是系统能不间断提供服务的能力。

我见过不少刚入行的朋友，一听到「高可用」就想到集群、想到多副本。其实没那么复杂。你想想看，一个系统如果动不动就挂，用户访问不了，那还谈什么业务？

我个人习惯把高可用拆成两个维度来看：

• 容错能力——部分组件挂了，系统还能跑
• 恢复能力——真挂了，能多快恢复

我在项目中遇到过一种情况：某交易系统每天凌晨做数据清算，单点跑一个脚本，脚本挂了整个清算就停了。这就是典型的「可用性黑洞」——你以为系统在跑，其实一个脆弱环节就能拖垮全局。

交易系统的可用性指标

聊可用性，绕不开那几个「9」。我直接给你看一张表：

可用性级别	年停机时间	典型场景
99%（2个9）	87.6小时	内部管理系统
99.9%（3个9）	8.76小时	普通电商
99.99%（4个9）	52.56分钟	金融交易系统
99.999%（5个9）	5.26分钟	核心支付清算

交易系统一般要求 99.99% 以上。为什么？

我举个例子。假设一个交易所每天交易额 100 亿，停机 1 小时，损失就是 4 亿多。这还不算用户信任的流失。所以金融行业对可用性的要求，从来不是「差不多就行」。

计算可用性时，我建议你遵循一个原则：用户能感知到的故障，才算故障。后端内部的重试、降级，只要用户没感知，可以不算。但一旦用户看到报错、超时，那就是实打实的可用性问题。

CAP理论与BASE理论

这两个理论，是做分布式系统绕不开的基石。我尽量用大白话讲清楚。

CAP 理论

CAP 说的是：一个分布式系统，在一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance） 这三者中，最多只能同时满足两个。

你可能会问：「为什么不能三个都要？」

原因很简单。网络是不可靠的，分区一定会发生。一旦网络断了，你面临一个选择：

• 要么保证数据一致，但拒绝写入（牺牲可用性）
• 要么允许写入，但数据可能不一致（牺牲一致性）

交易系统怎么选？

我个人习惯是：核心链路选 CP，非核心链路选 AP。

比如订单撮合，必须强一致，不能出现一笔钱花两次的情况。但行情推送，稍微延迟几毫秒问题不大，可以接受最终一致。

BASE 理论

BASE 是 CAP 在工程实践中的延伸。它包含三层意思：

• Basically Available（基本可用）——系统出问题时，允许降级，但核心功能还在
• Soft State（软状态）——允许数据中间状态存在，不要求时刻一致
• Eventually Consistent（最终一致）——经过一段时间后，数据会达成一致

我在设计交易系统的账户模块时，就用到了 BASE。用户充值后，余额不会立即更新到所有节点，但会在几秒内最终一致。这期间用户看到的可能是旧余额，但不会看到负数。

高可用架构设计原则

理论讲完了，咱们聊聊实战中怎么落地。我总结了四条原则，每条都是踩过坑换来的。

1. 冗余无单点

任何组件都要有备份。服务器、网络、磁盘、甚至机房，都要考虑冗余。

我曾经遇到一个案例：某系统做了数据库主从，但主库挂了才发现，从库的配置比主库低一档，根本扛不住流量。这就是「伪冗余」——有备份，但备份用不了。

2. 故障隔离

一个模块出问题，不能拖垮整个系统。常见的做法是：

• 线程池隔离（不同业务用不同线程池）
• 资源隔离（核心业务和非核心业务分机器部署）
• 熔断降级（下游挂了，上游主动切断，避免雪崩）

嗯，这里要注意。隔离不是越细越好。我见过一个团队，把每个接口都单独部署一个服务，结果运维成本暴涨，故障率反而更高了。适度隔离，才是正解。

3. 快速恢复

系统一定会出问题，关键是多快能恢复。我常用的手段：

• 自动化运维（故障自动发现、自动切换）
• 灰度发布（新版本先上少量机器，有问题能快速回滚）
• 预案演练（定期模拟故障，验证恢复流程）

说白了，恢复速度比不出故障更重要。你想想看，一个系统一年出 10 次故障，每次恢复 5 分钟；另一个系统一年出 1 次故障，但恢复要 2 小时。哪个可用性更高？显然是前者。

4. 可观测性

没有监控，高可用就是空谈。你需要知道：

• 系统当前的状态（CPU、内存、QPS）
• 请求的链路追踪（哪个环节慢了）
• 日志的聚合分析（故障根因是什么）

我习惯在项目初期就把监控体系搭好，而不是等上线后再补。因为补监控的成本，往往是初期搭建的 3 倍以上。

本章知识体系

下面这张图，把本章的核心逻辑串起来了：

这张图把本章的核心脉络理清了。从可用性指标出发，到理论支撑（CAP/BASE），再到落地原则，最后回到交易系统的具体实践。你顺着这个思路往下学，就不会迷路。

---