一、高可用架构概述

1.1 到底什么是高可用？

说白了，高可用就是让系统尽量少宕机。

我以前在金融团队带项目时，客户最关心的不是功能多炫，而是“别挂”。哪怕凌晨三点，交易系统不能停。这就是高可用的核心诉求——让你的服务，在故障面前依然能对外工作。

高可用，英文叫 High Availability，缩写 HA。它的目标不是“永不故障”，而是“故障了能快速恢复”。你想想看，真正的不可能故障，那是科幻片。现实里，我们能做的是：故障发生时，用户无感知，或者感知时间极短。

我个人习惯用一句话定义：高可用 = 冗余 + 故障自动转移。缺一不可。

1.2 可用性怎么算？99.9% 到底意味着什么？

可用性的计算公式很简单：

可用性 = (总时间 - 宕机时间) / 总时间 × 100%

举个例子，一年按 365 天算，总共 8760 小时。

你看，99.9% 听起来很高了对吧？一看数字，一年还能宕机将近 9 个小时。这在很多业务场景下是致命的。我亲身经历过一次，双十一大促当天，数据库因为慢查询挂了 40 分钟，99.9% 的指标保住了，但老板差点把我叫去谈话。

1.3 常见的故障类型有哪些？

我在一线踩过的坑不少，总结下来，故障无非这四类：

• 硬件故障：硬盘挂了、网卡松了、电源烧了。最常规，也最无解。
• 软件故障：OOM、死锁、Bug 导致进程崩溃。这类最让人头疼，因为复现难。
• 网络故障：机房光缆被挖断、交换机重启、DNS 劫持。我曾经遇上过两次机房出口带宽被打满，业务全挂。
• 人为故障：手滑删库、错误配置、变更没回滚。嗯，代码里最可怕的 Bug，往往是人。

你可能会问，“人为故障”也算？算，而且占比很高。我在运维早期就干过这样的事——半夜升级内核，忘了备份，直接起不来。那一次我学会了：永远要为人的犯错留退路。

1.4 容错思想：别想着不坏，要想着坏了怎么扛

容错的本质是设计出“不怕坏”的系统。怎么理解？我习惯用三个关键词概括：

1. 冗余：关键组件不止一份，坏了有替补。比如主从数据库、多副本存储。
2. 故障隔离：一个模块崩了，别把整艘船拖下水。比如微服务架构、熔断器模式。
3. 自动恢复：系统自己发现问题，自己切换，不需要人类半夜爬起来重启。比如 Keepalived、K8s 的自动重启策略。

举个例子，我设计过一套支付网关。平时两套集群都在跑，一个在主数据中心，一个在异地。一旦主数据中心挂了，异地集群在两秒内接管流量。用户最多感到页面卡了一下，但交易不会断。这就是容错思想落地的效果。

你想想看，如果没有冗余，一旦那台数据库服务器冒烟了，你是不是得求爷爷告奶奶去找备件？如果没有故障隔离，一个模块内存泄漏，整个系统 OOM，用户全骂你。如果没有自动恢复，凌晨三点，你是不是得从被窝里爬起来手动切流量？

嗯，这些我都经历过。所以我现在做架构设计时，首先问的不是“如何让系统更稳定”，而是“如果它一定会坏，我们怎么让它坏得不那么痛”。

容错思想并不是高深的理论，它其实是工程师的一种自我修养——承认系统会出问题，然后在设计阶段就为这些“问题”准备好应急预案。

图里这六个要素就是我多年总结下来的高可用核心支柱。你仔细看，从左到右，从冗余到恢复，是一个完整的闭环。少了任何一个，系统都不算真正的“高可用”。

举个例子，有的团队只做了冗余，但没有自动切换。结果主库挂了，还得人工登录去切。如果值班人员刚好上厕所呢？这 5 分钟的宕机时间，你的 99.9% 指标可能就没了。

同样的，如果你有自动切换但没有故障检测，系统可能一直以为自己还活着，流量打到一台已经没响应的机器上。所有请求都超时。嗯，这也是我曾经踩过的坑。

所以，容错不是某一种技术的堆砌，而是一整套设计思想：冗余 + 检测 + 切换 + 恢复，缺一不可。