凌晨两点半手机在床头柜上疯狂震动。值班同事的声音有点发虚“主库挂了从库没顶上现在只读页面全在报错。”我一边套外套一边问“半同步复制配了没”“配了。”“自动切换脚本呢”“切了但是新主库的数据少了一截。”那一瞬间我就知道这个晚上不是修一个故障而是给过去几年欠下的架构债还一次利息。后来我把这套踩坑经历、方案选型逻辑和现网验证手段整理过很多次发现真正决定高可用架构成败的从来不是某个开源组件选得有多时髦而是你有没有把“可用性目标、单点消除、切换一致性、故障恢复”这条链路想透。这篇文章就围绕高可用架构设计这个核心把我这些年做 MySQL 高可用、Kubernetes 集群、SQL Server 同步、以及最近在问数智能体这类 AI 应用里做稳定性设计的经验一次讲清楚。适合正在做业务稳定性保障、架构设计、或者刚接手高可用改造的同学参考内容尽量说人话重点放在“为什么这么做”和“实操时怎么避坑”。1. 高可用架构设计先想清楚可用性目标怎么定架构师的第一份作业很多人拿到“做高可用”这个需求第一反应是翻开源项目文档看看 MHA 怎么配、etcd 要几台机器。我的建议是先停一下把笔拿起来算一笔账。高可用架构设计的第一步不是画拓扑图而是定目标这个目标直接决定了你要花多少钱、买多少机器、引入多少复杂度。1.1 不要一上来就画拓扑图先算账可用性指标怎么定可用性最常见的度量是“几个九”公式是可用性 正常运行时间 / 总时间。99% 对应一年约 87.6 小时的停机窗口99.9% 是 8.76 小时99.99% 是 52.6 分钟99.999% 只有 5.26 分钟。你可以简单记一个数每增加一个九全年可容忍的故障时间就缩小大约 10 倍。定目标不能拍脑袋。我做过一个电商后台系统业务方张口就要 99.99%我问他你一年的营收受这个系统的影响是多少如果凌晨三点数据库不可用十分钟对业务的实际损失是什么系统研发团队只有 4 个人有没有人会半夜起来处理故障问完之后他把目标调到了 99.9%。这不是降低标准而是让投入产出比变得理性。高可用从来不是越贵越好而是匹配业务容忍度和团队运维能力。还有一个容易忽略的指标——恢复时间目标RTO和恢复点目标RPO。RTO 是故障后多久恢复业务RPO 是允许丢多少数据。这两个指标直接决定了你的技术选型RPO 接近零就必须做同步复制或者强一致方案RTO 要求分钟级就必须有自动切换能力而不是等人去手动执行命令。以 MySQL 高可用为例如果 RTO 要求 30 秒内但你用的是手工切换脚本几乎不可能达标如果 RPO 要求零丢失异步复制和半同步复制就要谨慎评估因为半同步在最坏情况下也有丢失窗口。1.2 高可用不是所有层都做双活优先解决“最关键路径”很多刚做架构的同学容易陷入一个误区每个组件都想搞双活每个节点都想做成对等的。结果就是架构图异常漂亮实际运维时发现组件之间的数据一致性、冲突处理、拆分逻辑复杂得让人崩溃。正确做法是找关键路径。怎么找关键路径画一张从用户请求到最终数据落盘的依赖图标出每条链路上哪些是单点哪些是无状态可水平扩展的。无状态服务比如 Web 前端、API 网关相对好办加节点、加负载均衡就可以有状态服务数据库、缓存、消息队列才是真正的高可用难点因为它们的“状态”没法简单地复制一份就完事。我看到华为企业数据架构设计方法里有一个思路很值得参考先理清楚核心数据资产和它们之间的关系再决定哪些数据需要做高可靠保障哪些数据允许暂时不可用。这套方法虽然是企业数据治理视角但它的“分层分级”思想完全可以迁移到高可用设计不是所有数据都值得做同等级别的保护优先保障核心业务数据链路次要数据甚至可以接受短暂降级。比如日志数据、埋点数据丢了可以补但订单数据、支付状态绝对不能丢这就是分层分级的意义。2. 基础设施层高可用从Rocky Linux 9到Kubernetes集群目标定完了关键路径也画出来了下一步就是底层基础设施的高可用。这一层是承载一切的底座但它往往最容易被忽视。我最近在基于 Rocky Linux 9 和 Docker 环境搭 Kubernetes 高可用集群时就发现很多看起来和“业务无直接关系”的底层细节才是故障时能不能快速恢复的关键。2.1 操作系统的“隐形成本”为什么选Rocky Linux 9很多人以为高可用架构只跟软件架构有关其实操作系统这一层非常关键。我之所以在新的集群环境里选 Rocky Linux 9一个重要原因是它和 RHEL 完全二进制兼容稳定性、安全更新、生态支持都有保障。对于需要长期运行的集群节点来说操作系统本身能不能稳定滚动更新比某个应用层的特性重要得多。但真正踩坑的是系统层配置。高可用集群对操作系统有几项隐藏要求不提前处理等故障发生就晚了。第一是时间同步集群节点之间时钟偏移超过一定阈值会导致心跳误判、证书校验失败、数据库复制异常。我通常用 chrony 配置内网时间源并在部署脚本里加一个开机自检确保所有节点时钟偏差在 50ms 以内。第二是内核参数比如 Kubernetes 节点需要调整 fs.file-max、net.ipv4.ip_forward、net.bridge.bridge-nf-call-iptables 等参数否则节点网络和容器通信会出现诡异问题。第三是防火墙和 SELinux这两个经常被安装文档忽略但恰恰是它们让 keepalived 的 VIP 漂移不生效或者让 K8s 的 kube-proxy 规则失效。2.2 基于Docker的Kubernetes高可用集群搭建控制面是关键Kubernetes 的高可用核心在控制面。很多人以为把所有组件都多副本部署一遍就是高可用实际上一半以上的线上故障都出在 etcd 和 API Server 的协调上。etcd 是高可用集群的“大脑”它内部用 Raft 协议保证一致性要求奇数个节点比如 3 个或 5 个。为什么是奇数因为 Raft 的容错能力是“最多容忍一半以下的节点故障”3 个节点容忍 1 个故障5 个节点容忍 2 个故障。偶数节点看似多一台实际上容错能力没有提升反而增加了同步开销。这一点在设计 K8s 高可用集群时特别重要。如果是基于容器方式部署集群组件——也就是你说的“基于 docker 的 kubernetes 高可用集群安装”——还需要注意一个点不要把 etcd 和 kube-apiserver 放在同一台机器上就算高可用你必须保证它们分散在不同物理节点并且通过 VIP 或者负载均衡器对外提供服务。常用做法是前面挂一层 keepalived nginx或者 haproxy把 6443 端口代理到多个 API Server 上。keepalived 负责 VIP 的漂移nginx 负责请求分发和健康检查。这个方案很成熟但一定要在部署时把健康检查的探测路径写对nginx 要探测 kube-apiserver 的 /healthz 接口而不是简单地探测 TCP 端口。探活路径错了就会出现“节点活着但服务不可用VIP 却切不过去”的问题。还有证书问题。用 kubeadm 或纯手工方式部署时API Server 的证书 SAN 要提前把所有可能的访问地址都加进去包括 VIP、各节点 IP、域名。证书 SAN 少一个等 VIP 漂移之后客户端就可能因证书校验失败而连不上这个坑非常隐蔽。以我的经验最好在初始化集群之前就把规划好的 VIP、每个节点的 IP、未来的负载均衡域名全部列出来一次性写进证书配置里。后期再改证书虽然可行但涉及分发、滚动重启操作风险明显增加。3. 数据层高可用MySQL和SQL Server的高可用实战数据层是高可用架构里最硬核的部分。无状态服务挂了可以随时拉起新副本但数据库如果丢了数据或者主从切换出了岔子那就是商业事故。这一块我会重点讲一下 MySQL 高可用的几种路径和 SQL Server 高可用同步的实践经验因为这两个是我在真实环境里用得最多、也最容易被问到的。3.1 MySQL高可用主从复制之外还要会选方案MySQL 高可用的基础是主从复制原理并不复杂主库把变更写入 binlog从库通过 IO 线程拉取 binlog 写入本地 relay log再由 SQL 线程回放。但基础复制有两个痛点一是延迟二是数据丢失。异步复制下主库提交成功但 binlog 还没来得及传给从库此时主库宕机这部分数据就永久丢失了。解决数据丢失的常用手段是半同步复制semisync replication。它要求主库在提交事务时至少要等一个从库确认收到了 binlog才向客户端返回成功。这样主库宕机时从库最多只丢失极少量的、处于最后确认状态的事务。但很多人在配半同步时忽略了一个细节半同步是“退化式”的如果所有从库都确认超时主库会自动退化成异步复制避免主库不可写。这个机制是为了可用性但也意味着在网络抖动时你以为数据是安全的实际上已经退化成了异步。所以我会在监控里专门加一条实时监测半同步复制是否处于正常状态一旦退化为异步立刻告警。说到方案选型我把常见 MySQL 高可用方案拉了一个对比表方便你根据自己的场景做判断方案切换方式数据一致性复杂度适用场景手工主从切换人工执行取决于复制配置低可接受较长 RTO 的测试或边缘业务MHA自动选主、自动切换基本保证依赖半同步中传统主从复制架构的经典选择MGR / InnoDB Cluster组复制多主或单主强一致性需配置中高对数据一致性要求高的新场景Orchestrator自动检测、自动切换依赖复制配置中大规模 MySQL 实例的拓扑管理MHA 曾经是很多公司的标配但它有个问题切换时需要一个管理节点来做协调管理节点本身又是一个单点。而且 MHA 依赖 SSH 免密登录和 binary log 补偿切换过程中如果主库已经不可达需要从从库找差异日志来补流程比较复杂。相比之下MySQL 官方推出的 InnoDB Cluster基于 MGR更像一个完整的解决方案它自带了 MySQL Router对应用层屏蔽了主从角色变化但要求你的表必须是 InnoDB而且对网络延迟比较敏感。如果跨机房部署 MGR建议先做小流量验证别一上来就全量切过去。实操上有几个经验值得写下来。一是无论选哪个方案都要开启 GTID全局事务标识符它能大幅简化主从切换时的位点匹配不然切换时去找 binlog 文件名和 position 会非常痛苦。二是路由层要实现“读写分离 自动感知主库”例如用 MySQL Router 或者应用层框架里的动态数据源主库故障切换后只读流量自动打到新主库避免应用重启才能恢复。三是切换后一定要检查从库的 SQL 线程是否正常特别是当从库有过复制中断积压了大量 relay log 时新主库可能带着延迟对外服务这种“切换成功但数据落后”的状态比直接故障还危险。3.2 SQL Server高可用同步Always On 可用性组的配置要点SQL Server 的高可用方案里生产环境用得最多的就是 Always On 可用性组。很多人把它和故障转移集群Failover Cluster Instance FCI搞混。FCI 是实例级的多台机器共享一份存储某个节点挂了另一台接管同一个数据库文件而 Always On 可用性组是数据库级的每台机器有自己的副本通过日志实时同步。这个区别决定了它们适合不同的场景FCI 不解决存储单点问题但应用感知最简单Always On 可以在副本上做只读路由充分利用硬件资源。Always On 里最核心的是同步模式选择。同步提交模式下主副本提交事务时要等待至少一个辅助副本确认日志落盘因此不会丢数据但对网络延迟敏感主库性能受制于最慢的那个副本。异步提交模式性能好但可能丢数据适合容灾和报表场景。生产环境我一般建议同机房的两个副本用同步提交用于自动故障转移异地的灾备副本用异步提交不参与自动故障转移。这样既保证了关键场景的 RPO 接近零又不会因为跨地域的高延迟拖垮主库性能。配置同步模式时还有一个容易踩的坑自动故障转移的前提是“主副本和辅助副本都处于同步提交模式并且健康状态同步正常”。如果你的辅助副本因为某种原因变成了“未同步”状态那自动故障转移实际上就失效了但你在界面上不一定能第一时间发现。所以监控里除了看可用性组是否“Healthy”还要看每个副本的同步状态是否是“Synchronized”。另外可用性组监听器Listener的配置一定不要漏应用应该连接监听器的虚拟网络名称而不是直接连某个实例的 IP。否则主副本切换后你的应用就要改配置重启。还有一个被很多人忽略的点见证服务器witness和仲裁。数据库级别的自动故障转移虽然不像 FCI 那样以 Windows 集群仲裁为基础但如果你在 Windows Server 故障转移集群上搭建 Always On那么集群仲裁仍然存在。如果仲裁配置不当比如没有见证磁盘或见证共享集群节点之间发生网络分区时可能会因为“脑裂”导致两边都想接管服务。我的建议是生产环境一定要在第三方位置如独立的云服务器或另一机房的机器配置文件共享见证或云见证并仔细测试两台主节点之间的网络断开的场景观察故障转移行为和业务的影响时间。4. 应用层与业务场景问数智能体架构中的高可用设计最近一年“问数智能体”这类 AI 应用越来越多很多企业会把自然语言查询能力接到自己的数据平台上让业务人员直接问“上个月华东区的退货率是多少”就能拿到报表。这类系统有一个有趣的地方它的高可用设计和传统 CRUD 系统很不一样因为它在原有数据链路上又引入了大模型调用、NL2SQL 生成、语义理解这些新环节每一环都是新的故障点。4.1 新型应用场景从传统后端到AI智能体传统的高可用设计核心是处理“流量突增、节点故障、数据一致性”这些问题。但问数智能体这类系统高可用要额外考虑“模型服务不可用”和“生成结果本身不稳定”这两个变量。模型服务比如大模型 API不像你自己的 MySQL 集群你没法完全控制它的可用性。如果上游模型接口超时或者限流你的智能体如果只是简单等待那用户感知到的就是“服务卡死”如果设置了很短的超时那用户又可能会出现“问一半就报错”的糟糕体验。更麻烦的是模型生成的 SQL 是不可预测的。同一个问题用户今天问和明天问生成的 SQL 可能不一样换一个说法得到的查询条件、聚合逻辑也可能不一样。这会导致一种新的“故障”用户手上的报表数据前后对不上信任感崩塌。所以在设计问数智能体的高可用架构时不光要保证系统不挂还要保证“在模型不稳定时系统的输出仍然可控”。4.2 智能体高可用的核心设计降级、缓存、限流、重试我在实际设计这类系统时核心思路是把大模型作为“增强组件”而不是“单点依赖”。一句话如果模型挂了系统要能退化成规则模式而不是完全不可用。具体做法有四个要点。第一是降级链设计。当模型服务异常或者超时时系统自动切换到预设的模板 SQL 或者规则引擎来回答常见问题。例如把所有高频查询销售报表、库存汇总等提前用人工规则映射成一个配置化的查询模板用户提问先经过一个轻量的关键词意图识别能匹配上就直接执行模板 SQL匹配不上再调用大模型。这样模型完全不可用时高频问题依然能回答保证了大部分业务场景的可用性。第二是结果缓存。大模型有很强的“输入相似性”同一个公司内部用户问来问去其实就那么几十个问题模式。可以用语义向量做相似度检索命中缓存的直接返回历史结果。这既降低了模型调用成本又让系统响应变快还保证同样的问题答案完全一致避免了“今日答案和昨日不同”的信任问题。缓存失效策略要仔细设计数据有更新时要主动清理相关缓存。第三是限流和熔断。大模型 API 的限流往往比数据库严格得多而且按 token 计费一个排查错误的死循环可能烧掉一大笔钱。我会在智能体网关层做两层保护一层是面向用户的全局限流比如每个用户每分钟最多 10 次模型调用另一层是针对上游模型 API 的熔断连续失败超过阈值就快速失败走降级逻辑。同时设置超时时间一般大模型调用的超时控制在一个合理的秒级范围宁可让用户拿到降级结果也不能让用户无限等待。第四是状态和会话管理。问数智能体通常是有状态的用户会在这个问题上追问“那华南区呢”“那上个月呢”这要求系统保存上下文。如果仅靠内存保存会话状态服务重启就会丢上下文用户感知到的就是“突然失忆”。生产环境要把会话状态存到 Redis 这类外部存储里并且把会话状态同步纳入高可用保障范围Redis 本身也要做主从和自动故障转移。同时智能体后面的任务执行比如生成 SQL 后要跑一个复杂的离线查询往往是异步的我会把它投递到消息队列由 worker 去执行这样即使用户请求服务重启异步任务也不会丢最多重新消费一次。5. 故障排查与实战经验高可用不是设计出来的是演练出来的不管你的架构图画得多漂亮高可用设计最终要回答一个问题故障真的发生时你的团队有没有能力快速恢复这一章我整理了这些年积累的隐患清单和验证手段希望能帮你少走弯路。5.1 常被忽视的隐患清单有几个隐患平时不声不响一到关键时刻就跳出来坑你。把这些点整理成一个速查表供你对照检查风险点典型表现预防手段心跳网络抖动节点偶发“假死”触发不必要的切换心跳网络与业务网络隔离合理设置超时和重试次数时钟偏移证书校验失败、复制日志时间戳错乱chrony 内网时间同步监控时钟偏差磁盘空间不足binlog 无法写入、从库回放卡住磁盘使用率告警日志自动清理复制延迟积压主从切换后新主数据落后监控 Seconds_Behind_Source / 同步延迟指标证书过期组件之间 TLS 握手失败证书到期自动告警提前续期备份仅备份不验证恢复演练时发现备份不可用定期做恢复演练像真实故障一样恢复数据变更不做预演上线配置错误直接导致集群异常变更前在预发环境完整执行一遍这里有两点值得重点展开。第一个是“心跳网络抖动引发脑裂”的问题。无论你是用 keepalived 做 VIP 漂移还是用 etcd 做选主都要防止网络分区时出现“双主”或“双节点同时认为自己是主”的脑裂情况。应对思路是仲裁机制K8s 里 etcd 靠多数派仲裁Keepalived 靠优先级和组播域MySQL 高可用方案里一般靠管理节点的判定和 fencing。但仲裁机制本身也可能成为单点或盲区所以一定要把仲裁节点放在一个独立于普通节点的地方并且定期模拟网络分区场景来验证不会脑裂。第二个是“备份可用性和恢复速度”的问题。很多团队都有备份但从未真正测过恢复流程。等你需要恢复时才发现备份文件损坏、备份时间点落后太多、恢复步骤没人会操作。我建议每个季度做一次“备份恢复演练”就好比消防演习真到着火的时候才能有条不紊。恢复演练不只是 DBA 的事要把应用的启动顺序、流量切换都一起测一遍测完把结果记录成一份文档下次再快速参考。5.2 高可用架构的验证与演练混沌工程与恢复SOP高可用架构设计完成之后下一步就是验证。我强烈建议引入混沌工程Chaos Engineering的思路用主动制造故障的方式验证你的系统是否真的能扛住。不是说你一定要上全套 Chaos Mesh 或者 Litmus 这类平台哪怕手动做故障注入也有效果。你可以选择一个业务低峰期定期做以下操作直接 kill -9 主数据库的进程观察 MHA 或 MGR 是否按预期切换把 Kubernetes 某个节点直接关机观察 Pod 是否重新调度到其他节点断开两个机房之间的网络链接观察跨机房同步是否中断、能否恢复。做这些演练时最重要的不是“故障被解决了”而是发现预案里没有覆盖到的场景。比如我遇到过一次演练时把主库 kill 掉切换脚本成功把流量切到了新主库但发现消息队列里的一个消费者连的还是旧主库的地址导致下游业务写数据失败。这个问题在架构图上完全看不出来只有真实演练才能暴露。所以我会建议每做一次演练都要把发现的问题追加到待办清单里作为下次架构改进的输入。另外一定要有恢复 SOP标准操作流程。故障发生时人往往处于慌乱状态如果没有一份明确的 Runbook操作人员可能在“要不要切换”“从哪里找文档”上浪费大量时间。我发现最好用的结构是第一步先做什么比如先摘流量、先启动告警升级第二步看哪些监控指标第三步如果 A 方案不行B 方案是什么第四步恢复后要检查哪些指标才能确认“真正恢复”而不是只是表面恢复了。把这些流程写成 Markdown 放在团队 Wiki 里并让每个值班成员都实际走一遍确保紧急情况下知道到哪里找、怎么做。最后再分享一个我自己的习惯每次做高可用切换之后无论切换成功还是失败我都会要求团队写一份事后复盘重点不是追责而是理清“系统在哪一个瞬间发生了什么”“我们当时看到了什么信息”“我们做了什么决定”。把这个时间线整理出来你会发现一个有趣的现象很多时候故障持续时间极短但因为没有人能快速定位信息导致恢复动作迟迟没有执行。所以我会优先保证监控指标和日志信息在故障时是“能快速被找到的”而不是把精力全花在优化某个组件的切换耗时上。这套思路无论是传统的 MySQL 高可用、Kubernetes 集群、SQL Server 同步还是新兴的问数智能体架构都一样适用先想清楚目标和关键路径再逐层消除单点、做好切换一致性最后用演练验证并完善恢复流程。架构设计没有终点每一次故障都是一次重新理解系统的机会。