先说一个我亲身经历过的夜晚。凌晨两点监控突然报警主库进程退出了。按理说我们已经部署了主从复制只需把流量切到从库就能继续跑但实际切换花了二十多分钟——应用层还在反复重连旧VIPSession全堆在本地内存里从库的Binlog位点比主库少了几千条还有两个定时任务直接在两边实例上同时跑了起来。那一刻我才真正意识到高可用从来不是一个单点工具能解决的问题而是一整套协同设计的结果无状态化让每个节点可以被替换水平扩展让流量可以被分散故障转移让意外发生时不至于全线崩溃。这三件事缺了任何一件剩下两件都会在关键时刻大打折扣。这篇文章不聊虚的就从一个实际做基础架构的视角把这三件事拆开揉碎讲讲为什么要协同设计、每一步应该怎么落地、以及我在实际踩坑过程中总结出来的经验和教训。无论你是刚接手高可用改造的运维新人还是正在设计微服务架构的后端开发这篇内容应该都能给你一些可以直接抄作业的思路。1. 高可用到底在解决什么问题1.1 故障清单远比你想的多一说高可用很多人第一反应就是“多搞几台机器”。这个方向没错但太模糊了。你得先搞清楚你的系统到底会在什么场景下出问题所有的高可用手段本质上都是在回答一个问题某个节点不可用的时候系统还能不能继续对外提供服务。故障的类型远比你想的多。最常见的当然是进程挂掉比如MySQL突然OOM、Java进程被系统杀掉这种属于软件层面最轻微的故障重启往往就能恢复。再往上还有机器宕机、磁盘损坏、机房断电等硬件故障这种恢复周期就不是几分钟的事了。还有一种非常容易被忽略的故障是网络分区主库和从库之间的网络通了但延迟极高应用和数据库之间的连接频繁超时这种故障从应用侧看像是数据库挂了但从数据库侧看一切正常。另外数据损坏也是高可用里最棘手的问题可能是误删数据、错误的UPDATE语句也可能是存储引擎层面的文件损坏这种故障往往需要靠备份和日志才能恢复。不同性质的故障要求你采取不同的应对策略。比如进程级别的故障适合用探活和自动拉起来解决机器级别的故障则需要故障转移机制网络分区需要的是脑裂防护而数据损坏则完全依赖备份恢复和日志审计。很多团队只对“进程挂掉”这种场景做了自动化等到机器宕机的时候才发现自己的高可用方案根本没有覆盖到这种场景。1.2 可用性不是一个数字而是一套预期管理很多人喜欢用“99.9%”或“99.99%”来定义自己的高可用目标但说实话这个数字如果只是贴在PPT上没有任何意义。你得把它换算成具体的业务影响。一年365天里99.9%的可用性意味着允许宕机约8.76小时听起来还行但如果是99.99%一年只能宕机52.56分钟。也就是说如果你没有一个故障转移能在分钟级完成的方案那几个“9”纯粹是自欺欺人。我在实际工作中更倾向于把可用性问题拆成两个维度来理解一是恢复时间目标也就是从故障发生到服务恢复需要多久这决定了你的切换机制要多快二是数据丢失容忍度也就是故障发生时能够接受丢失多少数据这决定了你的数据同步策略是异步、半同步还是强同步。这两个指标直接决定了你的架构选型。如果业务能接受丢数据那异步复制加快速切换就够了如果一分钱数据都不能丢那就必须上强同步方案比如MySQL的半同步复制或者SQL Server的Always On同步提交。很多高可用方案失败不是技术没做好而是在设计之初就没把这两个预期真正定清楚导致切换的时候才发现“数据对不上”。2. 无状态化让每台机器都成为可替换的零件2.1 有状态与无状态的边界我常用一个比喻来理解无状态化有状态的服务就像学校里指定座位的考试你只能在自己的座位上答题换一个座位就什么都找不到了无状态的服务就像公共澡堂你只需要拿个号牌进去出来的时候用自己的号牌取回物品至于你刚才待的是哪个柜子、哪个淋浴位根本不重要。具体到技术上有状态和无状态的边界其实很清晰。无状态的服务任何请求发到任何一台实例上处理结果都是一样的有状态的服务则依赖某种本地数据比如Session、本地文件、内存缓存、定时任务状态等。最容易踩坑的恰恰是那些看起来人畜无害的“本地状态”。我接手过一个项目应用层完全没有分布式Session的管理所有的用户登录态都存在每台机器的本地内存里负载均衡器配置了轮询算法。前半年一切正常直到有一次发布时滚动重启大量用户突然被登出这才暴露了问题用户上次请求落在A机器这次请求落在B机器B机器上没有对应的Session自然就把用户踢下线了。所以无状态化的核心逻辑很简单把那些依赖单机内存或磁盘的“状态”尽量往外部存储迁移让应用实例本身保持“干净”。一台实例随时可以被销毁、被替换、被扩容而不会影响整个系统的可用性。2.2 常见的无状态化改造手段Session外置是无状态化最经典的一步。做法是把Session从应用本地内存里迁到Redis这类集中式存储中应用启动时从Redis读取Session请求结束时再写回去。要注意的是你引入的Redis本身也是一个有状态的组件它同样需要考虑高可用——至少要做到主从加哨兵避免Redis一挂所有Session都没了反而引入了新的单点。如果不想维护Redis也可以考虑用JWT这类无状态Token把用户信息直接放进Token里应用侧不需要存储任何会话状态。但JWT有一个被很多人忽略的坑服务端没有办法主动让一个已经签发的Token失效。你设置15分钟过期那用户被踢了之后最长还要等15分钟才能真正失效。实际项目中通常需要引入Token黑名单或短期刷新机制否则注销功能很难做。本地文件和无状态化也是一对矛盾。应用在本地磁盘写日志、传图片、生成临时文件这些都是缺乏全局视角的做法。上传的文件应该收口到对象存储日志应该直接输出到统一采集平台临时文件处理完就该清理。如果一定要在本地写文件至少要做到“过期即删”并且不能假设某台机器上的文件其他机器能访问到。定时任务是最容易被忽略的无状态化盲区。很多人以为定时任务跑在单台实例上没问题结果一旦做了水平扩展任务就会在每台机器上同时执行轻则重复发送通知重则产生脏数据。解决方案是引入分布式锁只用一把锁控制同一时刻只有一个实例真正执行任务其他实例保持待命状态。我见过很多团队在任务执行侧写了一大堆幂等逻辑却没想到在最上面加一个分布式锁更简单。2.3 数据库不是无状态的但它可以“可替换”这里有个常见的思想包袱应用层可以做无状态化但数据库本身明明是有状态的而且是最核心的状态怎么能做到无状态答案是数据库确实做不到无状态但我们可以通过复制技术让每一台数据库节点都变成“可替换”的。MySQL主从复制就是最典型的例子。一个主库负责写一个或多个从库负责读数据通过Binlog异步或半同步地同步到从库。当主库故障时从库虽然可能在数据上有少量延迟但它拥有整个数据集的完整副本可以随时顶替主库对外服务。从业务角度看只要把流量从旧主库切到新主库数据库在逻辑上依然是那个“唯一的数据库”只是物理载体换了一台机器。同理SQL Server的Always On可用性组也是这个思路通过日志流同步将主副本的数据同步到各个辅助副本每个副本都保存着完整的数据集。故障发生时可用性组会把主角色自动转移到另一台副本上对应用的连接使用的是同一个虚拟网络名称应用层甚至感知不到底层切换的发生。这就是“物理有状态、逻辑可替换”的精髓。3. 水平扩展先摊平流量再打散压力3.1 无状态层的扩展是最划算的一旦你完成了无状态化改造水平扩展就会变得非常顺理成章。因为实例本身不带状态你随时可以加机器、减机器只需要确保流量被合理地分发到每一台实例上就行。流量分发最常用的是四层负载均衡和七层负载均衡。如果你工作在传输层可以根据IP和端口转发流量性能高但拿不到HTTP层的信息七层负载均衡可以读取路径、Header、Cookie等数据实现更精细的路由。实际项目中往往是两者搭配外层LVS做四层转发内层Nginx做七层代理。但这里我要提一个反向的教训无状态化改造完成之后水平扩展的一个隐藏瓶颈往往会出现在连接层。很多数据库和中间件对连接数有硬性上限比如MySQL的max_connections默认只有151现在有些版本更高应用实例从5台扩展到50台每台建立50个连接数据库的连接数很快就爆了。所以做水平扩展时一定要同步规划连接池的收敛策略比如使用Proxy层统一收敛数据库连接应用只连接Proxy而不是直连数据库。这样才能保证业务实例随便扩数据库的连接压力不会跟着线性增长。3.2 有状态层怎么扩展读写分离与分片无状态层扩展相对容易真正的复杂度在数据层。数据层扩展的第一级是读写分离把读流量引导到从库上去主库只管写。这一步的实现成本很低只需要在代码里区分数据源或在中间件层做读写路由。但读写分离有一个绕不开的痛点主从延迟。如果你的业务允许读到“稍微旧一点”的数据那主从延迟是可以接受的但有些场景——比如用户刚下了单立刻去查订单详情——如果读到的还是旧状态体验就会变得非常糟糕。常见的解决方案是“写后读一致性”即刚执行过写请求的会话在一定时间内强制走主库读或者通过缓存把最新数据短期保留。当数据量再往上走读写分离就不够用了你还需要做数据分片。分片就是把数据按照某种规则分散到多个数据库实例上每个实例只负责一部分数据。分片键的选择非常关键如果选了性别这种枚举值很少的字段做分片键会导致数据分配严重不均一亿条用户数据男女各半落到两个库上还算平衡但如果是按地区分片而某个地区占了80%的数据热点问题会直接击穿集群。更稳妥的方案是用用户ID或订单号这类高基数字段进行哈希取模分片并配合一致性哈希来应对扩容时的数据迁移。3.3 缓存层高可用架构里的缓冲带谈到水平扩展缓存层是绕不开的。我在高可用架构里特别喜欢把Redis放在数据库前面当“缓冲带”它的作用不仅仅是加速更重要的是削峰。数据库QPS上限可能只有几千而Redis单实例可以扛到十万级。高峰期的大量读请求如果全部打到MySQL上数据库即使没挂也会因为连接堆积导致主从复制延迟变大最终把故障面扩大。有了缓存层热数据全部在内存里兜住数据库的读压力骤降整个系统的抗压能力会提升一个量级。但缓存层也会引入新的高可用问题。Redis本身如果宕机大量请求会穿透到数据库瞬间打垮后端。所以生产环境至少要做Redis主从加哨兵或者直接上Redis Cluster。更重要的是做缓存降级策略当Redis出现大面积故障时业务侧要主动熔断直接走数据库而不是在Redis超时上反复重试把数据库也拖垮。这个“缓存穿透保护”的思路比单纯堆Redis实例更关键。4. 故障转移让故障看起来像没发生4.1 故障转移的三段式发现、切换、恢复故障转移不是“一键切换”那么简单它是三个阶段的连贯动作。第一阶段是发现故障系统需要通过某种机制感知到节点不可用第二阶段是切换把流量和角色从故障节点转移到健康节点第三阶段是恢复把原故障节点的数据补齐让它可以重新加入集群。每一阶段都有各自的坑我一个个说。发现阶段最怕两件事漏报和误报。漏报意味着故障已经发生但监控没触发服务一直黑着直到用户投诉才发现大事不妙误报则是把健康节点误判为故障触发了不必要的切换。所以故障发现必须做“多重确认”不能探测一次失败就立刻判定故障应该连续探测三次以上并且在两个不同维度上同时失败才触发切换比如TCP层连不上同时主从复制心跳也停了。切换阶段要关注的是流量切换和角色切换的先后顺序。拿MySQL主从切换举例必须先提升一个从库为新主库再更新应用侧的连接指向最后把VIP或域名解析漂移到新主库上。顺序反了应用连接被切走了但新主库还没准备好同样会造成服务中断。恢复阶段则是最容易被忽略的旧主库起来之后必须作为新主库的从库重新接入并同步期间缺失的数据绝不能让它稀里糊涂地重新变回主库。4.2 探活机制依赖心跳更要依赖业务探活是故障转移的第一道工序。常见的探活方式包括ICMP Ping、TCP端口探测、HTTP健康检查以及应用层心跳。对于MySQL来说最基础的探活就是mysqladmin ping但只说一句“服务在”是不够的你还需要确认它真的能处理查询。所以更合理的方式是执行一个轻量的SELECT 1甚至检查主从复制的线程状态。我遇到过一种情况MySQL进程还活着TCP端口也通但磁盘满了事务完全无法提交。如果只用mysqladmin ping探测得到的结论是“存活”可实际上整个数据库已经处于半死不活的状态。这里我给一个实用的探活脚本思路放在crontab里每10秒跑一次#!/bin/bash MYSQL_HOST127.0.0.1 MYSQL_USERmonitor MYSQL_PASSmonitor_pass mysql -h${MYSQL_HOST} -u${MYSQL_USER} -p${MYSQL_PASS} -e select 1 /dev/null 21 if [ $? -ne 0 ]; then echo mysql health check failed exit 1 fi # 检查主从是否卡住 SLAVE_STATUS$(mysql -h${MYSQL_HOST} -u${MYSQL_USER} -p${MYSQL_PASS} -e show slave status\G 2/dev/null | grep -E Slave_IO_Running|Slave_SQL_Running) echo $SLAVE_STATUS | grep -q Yes || exit 1关键在于把“进程活着”和“功能正常”区分开探活逻辑必须能够反映业务真正的健康状态。此外探活频率也要控制好探测太频繁会增加系统负担太稀疏又会拖延故障发现时间实践中10秒到30秒是一个比较合理的区间。4.3 选主与脑裂最容易翻车的环节当集群里有多个节点可以被提升为主节点时就必须面临“选主”的问题。选主算法的核心目标是让所有节点对“谁是主”达成一致经典的做法是使用Paxos或Raft这类共识算法。MySQL 8.0的Group Replication和InnoDB Cluster就是基于这类协议实现的它们能在大多数节点存活的情况下自动选出新主。对于传统的主从复制架构选主往往靠外部工具来协调比如MHA或Orchestrator。选主过程最怕的情况是脑裂网络分区导致集群被切成两部分两边各自认为自己是“可用的大多数”于是分别选出了不同的主节点。此时如果两边的Master同时接受写入数据的一致性就被彻底破坏了而且很难在事后自动修复。防止脑裂的通用思路是引入仲裁机制比如控制节点的数量只有票数过半的节点组才能选主或者使用仲裁盘一个节点只有在能够锁定仲裁盘时才有资格当选主对于VIP漂移方案还要配合严格的fencing机制在新主接管之前强制将旧主的网络、服务禁用掉。我在生产环境中见过的最典型的脑裂事故是keepalived配置里没有用组播而是让两个节点都配了同一个VIP结果节点间的心跳断了之后两台机器同时把VIP绑定到自己网卡上。交换机上的ARP表在两个MAC地址之间疯狂抖动大量请求被导去错误的节点。这种问题在架构上做防护比事后处理更有效——主备节点之间一定要有仲裁机制并且要配置nopreempt之类的参数避免异常抢占。4.4 从MySQL到SQL Server两类主流的故障转移方案前面大篇幅讲的是MySQL场景但热词里提到了SQL Server我也单独说几句。SQL Server的高可用方案以Always On可用性组为代表它和MySQL主从复制在思路上有相似之处但也有明显的差异。Always On可以配置同步提交模式也就是说主副本必须等到至少一个辅助副本确认日志已持久化事务才会提交。这相当于把MySQL半同步复制里的“至少一个从库确认”变成了产品级的标准能力数据丢失的概率被降到了很低。Always On的自动故障转移有一个硬性前提可用性组必须配置了辅助副本并且启用了同步提交同时还要有仲裁见证节点。缺少任何一个条件数据库引擎都会拒绝自动转移宁可继续服务也不盲目切换。这一点非常值得MySQL生态学习——别为了追求切换速度牺牲数据一致性。我实际维护过几套Always On最大的体会是它的监听器机制很省心应用只需要连接虚拟网络名称故障转移后监听器自动更新IP应用谈不上什么感知。但它的局限也很明显只支持到可用性组粒度如果业务没有做分库大集群下面的切换粒度会比较粗。5. 三件事的协同设计一份可落地的参考架构5.1 一条完整的请求链路无状态化、水平扩展、故障转移这三件事单独拎出来每一项都能讲半天但它们只有组合在一起才能形成真正的高可用。我直接用一条请求链路来说明它们如何协同。假设用户通过浏览器访问你的站点首先经过DNS解析DNS背后是负载均衡器的VIP。如果SLB本身做了主备部署当主负载均衡器故障时备用节点通过VRRP协议抢占VIP这是一层故障转移。流量到达应用集群之后任一台无状态应用实例都可以处理请求。这里体现的是水平扩展的价值10台实例扛不住就加到20台每台实例都是可替换的。应用处理过程中需要读取用户状态Session数据在Redis里于是Redis就必须是高可用的Redis哨兵集群监测主节点故障并自动提升从节点这是第二层故障转移。应用需要查询数据库时连接池通过读写分离中间件或Proxy读取数据常规查询走从库写操作走主库。从库副本可以随时扩展这是数据层的水平扩展。最后MySQL主从复制和MHA/Orchestrator构成了数据库层的故障转移当主库故障时自动提升一个新主库并且切换VIP漂移同时把应用的数据源指向新主库。整条链路里每个环节都有冗余、有探活、有切换才能做到某个节点故障时其他部分照常运转。5.2 主库故障时的完整动作序列我把一次MySQL主库宕机到恢复的完整动作序列整理成一张清单这张清单也是我实际运维过程中逐步打磨出来的可以直接作为你设计切换流程的参考。阶段动作关键点发现监控连续三次探测失败触发告警不要用单次失败做决策确认检查从库的Relay Log和主库的Binlog位点确认数据差距评估丢数风险预检检查新主库的复制线程是否健康不健康的节点不能参与选主切换提升从库为新的主库关闭只读模式必要时补收旧主的Binlog后半段流量切换把VIP漂移到新主库或更新应用的连接配置先角色切换后流量切换旧主恢复旧主库上线后以从库身份重新加入到新主用GTID自动找位点避免人工设置错位校验验证数据一致性检查复制延迟归零确认业务请求正常切换完成这里重点说两个容易翻车的细节。第一如果在异步复制模式下旧主库宕机前最后几条事务还没传到从库那切换后这些数据就丢失了。你要么接受这个事实要么在切换前做日志补偿把旧主库的Binlog尾部尽量追平。第二切换完流量之后一定要回收旧主库的写权限。旧主库恢复后如果它还保留着原来的VIP并且没有意识到自己已经不是主节点就可能出现双主写入造成数据不一致。所以“旧主降级为从库”这个动作必须自动执行而不是等人手动处理。5.3 同城双活与两地三中心的取舍再往上走一层很多业务已经开始做同城双活甚至两地三中心了。同城双活就是把应用集群和数据库集群分别部署在两个机房两个机房间的网络延迟一般在1毫秒以内可以做到数据库层实时同步。理论上任意一个机房挂掉另一个机房可以完全接管全部流量这就是机房级别的故障转移。但有两个现实问题必须面对。第一是机房间网络中断的风险一旦网络分区两个机房都可能认为对方故障从而各自启动故障转移最终出现双主写。解决的办法还是那一套引入仲裁节点而且仲裁节点最好放在第三个机房或者使用云厂商提供的跨区域仲裁服务。第二是数据层双活对同步链路的要求极高同城双活下MySQL通常要配置双主加半同步复制SQL Server则用Always On的多副本同步提交。如果主备之间的链路延迟超过几毫秒每个写请求都会被拖慢这时就要权衡是牺牲性能换取绝对可用性还是接受小概率的数据丢失来保证更低的延迟。6. 故障转移的常见问题与排查实录6.1 转移失败的第一嫌疑探活误判我调试过很多次故障转移失败的问题总结下来第一嫌疑永远是探活逻辑本身。最常见的是探活的判定条件设置得太宽比如只检查端口连通性导致进程“半死”时没有被及时发现或者反过来探活条件太苛刻比如依赖某个只在极少数情况下才执行的SQL语句造成大量误报系统频繁触发无意义的切换。让我印象最深的一个案例是某次主库其实没有故障只是监控账号用的密码过期了导致探活脚本开始报错。连续几次误报之后触发了自动切换流程生产环境在完全没有必要的情况下做了一次主从切换。由于切换脚本里没有做足够的延迟检查切换后从库立刻承担了主库压力几分钟后的确因为自身延迟太大而拖垮了业务。整个事故的根因恰恰是探活机制本身出了问题。所以探活配置一定要避免“单一信息源”至少同时使用TCP连接和SQL查询两个维度并且在做切换决策前确认故障是真实存在的。6.2 主从延迟引发的数据丢失异步复制最大的软肋是主从延迟。延迟如果只是几百毫秒大多数业务都能接受但一旦主库在高峰期短时写入量暴涨——比如秒杀、结算场景——延迟可能会飙升到分钟级。这时候如果发生主库宕机这些延迟期间的数据就全部无法同步到从库业务会直接丢失几分钟的数据。预防方案就是把复制模式从异步升级为半同步MySQL半同步复制虽然会略微增加事务提交的响应时间但主库会等待至少一个从库收到Binlog后才会向客户端确认提交成功这就能把丢数据的窗口压缩到接近于零。SQL Server的Always On同步提交也是同样的设计理念。值得注意的是“半同步”不只是在数据库配置里改一个参数它要求你的应用连接本身也具备重试和幂等能力。一旦半同步因为从库ACK超时而退化为异步应用侧的请求其实并没有真正提交成功但客户端并不知道因此要有超时重试的机制去兜底。我见过太多团队把半同步打开之后就卸下了所有防备结果一次从库故障导致半同步降级数据还是丢了而他们完全没有感知。6.3 脑裂的兜底方案前面多次提到脑裂这里再补充一个实战中非常有效的兜底方案切换流程里强制加入“fencing”步骤。在数据库主从切换场景中保新主的手段往往就是“把旧主的写权限剥夺掉”。比如MHA切换脚本里会执行masterha_master_switch并借助SSH登录旧主把它设为只读而更保险的做法是从硬件层面把旧主的网络隔离掉或通过带外管理系统直接断电。如果你觉得断电太重至少要做到任何节点只有在确认自己拿到“锁”之后才有资格成为主库拿不到锁就自动降级。对于keepalived这类基于VRRP的场景防脑裂的主要手段是仲裁节点并且要开启nopreempt配合优先级策略。我见过一个比较稳妥的组合两个数据库节点通过keepalived共享一个VIP同时引入一台独立的仲裁机当主备之间的心跳断开时双方每次都去仲裁机注册状态只有注册成功的节点才能拥有VIP。这样即使两个节点都活着也不至于同时对外提供写服务。6.4 一份故障转移排查速查清单结合我自己处理的案例我把故障转移排查的要点整理成一份速查清单日常巡检或故障复盘时可以直接对照着看。探活脚本是否同时覆盖了进程、端口、SQL执行三个层面探活失败次数阈值设的是多少连续几次失败才触发切换主从复制链路是否有延迟监控延迟峰值是多少有没有告警切换时是否先提升了从库角色再更新连接指向旧主恢复后是否会自动降级为从库并重新追平数据有没有双主写保护机制如写权限检查、VIP仲裁半同步复制是否启用如果启用降级条件是什么应用层是否具备重试、幂等能力切换期间是否会报大量错误有没有定期演练切换演练时切换时长是多少最后一条“定期演练”往往是最容易被忽视的。很多团队的切换脚本写得看起来很完善但半年没执行过一次。真到故障发生时才发现脚本里有一处硬编码的IP早就过期了或者SSH免密钥失效了。所以每季度至少做一次主从切换演练并且把切换时长控制在分钟级这对生产系统的可靠性提升非常明显。7. 写在最后我的几点实操经验文章讲到这里三件事的协同逻辑已经比较完整了。最后再分享一点我个人在实际操作中的体会。无状态化是最难推动的一件事因为它涉及的是“思维方式的转变”而不是“装一个工具”。很多团队的应用代码运行了好几年代码里到处是本地缓存、本地文件、线程局部变量要真正把状态全部外置需要投入大量的重构工作而且短期看不到收益。我的建议是不要指望一步到位可以先挑最容易出问题的点下手先做Session外置再做定时任务收敛然后是本地文件归口。每改动一步高可用能力都会上一个台阶。故障转移方案的选择永远是在性能和一致性之间做权衡。如果你一开始就追求“绝不丢数据”就要接受切换时的延迟和架构复杂度如果你的业务允许微小数据丢失优先选择简单方案至少比一个复杂但没人能维护的方案靠谱得多。这里我想强调一点高可用系统最大的敌人不是故障本身而是你过于自信地认为自己不需要演练。我个人的经验是每半年做一次全链路故障演练人为制造一次“主库宕机”观察系统能不能自动完成发现、切换、恢复的全流程。只有真正演练过你才知道自己的高可用设计是纸面文章还是能打的实战能力。这也就是我文章开头所说的——高可用不是某一项技术而是一整套协同设计。把无状态化、水平扩展、故障转移放在一起反复推演你总能在系统真正出问题之前发现那些藏在角落里的盲区。
高可用架构核心：无状态化、水平扩展与故障转移协同设计
先说一个我亲身经历过的夜晚。凌晨两点监控突然报警主库进程退出了。按理说我们已经部署了主从复制只需把流量切到从库就能继续跑但实际切换花了二十多分钟——应用层还在反复重连旧VIPSession全堆在本地内存里从库的Binlog位点比主库少了几千条还有两个定时任务直接在两边实例上同时跑了起来。那一刻我才真正意识到高可用从来不是一个单点工具能解决的问题而是一整套协同设计的结果无状态化让每个节点可以被替换水平扩展让流量可以被分散故障转移让意外发生时不至于全线崩溃。这三件事缺了任何一件剩下两件都会在关键时刻大打折扣。这篇文章不聊虚的就从一个实际做基础架构的视角把这三件事拆开揉碎讲讲为什么要协同设计、每一步应该怎么落地、以及我在实际踩坑过程中总结出来的经验和教训。无论你是刚接手高可用改造的运维新人还是正在设计微服务架构的后端开发这篇内容应该都能给你一些可以直接抄作业的思路。1. 高可用到底在解决什么问题1.1 故障清单远比你想的多一说高可用很多人第一反应就是“多搞几台机器”。这个方向没错但太模糊了。你得先搞清楚你的系统到底会在什么场景下出问题所有的高可用手段本质上都是在回答一个问题某个节点不可用的时候系统还能不能继续对外提供服务。故障的类型远比你想的多。最常见的当然是进程挂掉比如MySQL突然OOM、Java进程被系统杀掉这种属于软件层面最轻微的故障重启往往就能恢复。再往上还有机器宕机、磁盘损坏、机房断电等硬件故障这种恢复周期就不是几分钟的事了。还有一种非常容易被忽略的故障是网络分区主库和从库之间的网络通了但延迟极高应用和数据库之间的连接频繁超时这种故障从应用侧看像是数据库挂了但从数据库侧看一切正常。另外数据损坏也是高可用里最棘手的问题可能是误删数据、错误的UPDATE语句也可能是存储引擎层面的文件损坏这种故障往往需要靠备份和日志才能恢复。不同性质的故障要求你采取不同的应对策略。比如进程级别的故障适合用探活和自动拉起来解决机器级别的故障则需要故障转移机制网络分区需要的是脑裂防护而数据损坏则完全依赖备份恢复和日志审计。很多团队只对“进程挂掉”这种场景做了自动化等到机器宕机的时候才发现自己的高可用方案根本没有覆盖到这种场景。1.2 可用性不是一个数字而是一套预期管理很多人喜欢用“99.9%”或“99.99%”来定义自己的高可用目标但说实话这个数字如果只是贴在PPT上没有任何意义。你得把它换算成具体的业务影响。一年365天里99.9%的可用性意味着允许宕机约8.76小时听起来还行但如果是99.99%一年只能宕机52.56分钟。也就是说如果你没有一个故障转移能在分钟级完成的方案那几个“9”纯粹是自欺欺人。我在实际工作中更倾向于把可用性问题拆成两个维度来理解一是恢复时间目标也就是从故障发生到服务恢复需要多久这决定了你的切换机制要多快二是数据丢失容忍度也就是故障发生时能够接受丢失多少数据这决定了你的数据同步策略是异步、半同步还是强同步。这两个指标直接决定了你的架构选型。如果业务能接受丢数据那异步复制加快速切换就够了如果一分钱数据都不能丢那就必须上强同步方案比如MySQL的半同步复制或者SQL Server的Always On同步提交。很多高可用方案失败不是技术没做好而是在设计之初就没把这两个预期真正定清楚导致切换的时候才发现“数据对不上”。2. 无状态化让每台机器都成为可替换的零件2.1 有状态与无状态的边界我常用一个比喻来理解无状态化有状态的服务就像学校里指定座位的考试你只能在自己的座位上答题换一个座位就什么都找不到了无状态的服务就像公共澡堂你只需要拿个号牌进去出来的时候用自己的号牌取回物品至于你刚才待的是哪个柜子、哪个淋浴位根本不重要。具体到技术上有状态和无状态的边界其实很清晰。无状态的服务任何请求发到任何一台实例上处理结果都是一样的有状态的服务则依赖某种本地数据比如Session、本地文件、内存缓存、定时任务状态等。最容易踩坑的恰恰是那些看起来人畜无害的“本地状态”。我接手过一个项目应用层完全没有分布式Session的管理所有的用户登录态都存在每台机器的本地内存里负载均衡器配置了轮询算法。前半年一切正常直到有一次发布时滚动重启大量用户突然被登出这才暴露了问题用户上次请求落在A机器这次请求落在B机器B机器上没有对应的Session自然就把用户踢下线了。所以无状态化的核心逻辑很简单把那些依赖单机内存或磁盘的“状态”尽量往外部存储迁移让应用实例本身保持“干净”。一台实例随时可以被销毁、被替换、被扩容而不会影响整个系统的可用性。2.2 常见的无状态化改造手段Session外置是无状态化最经典的一步。做法是把Session从应用本地内存里迁到Redis这类集中式存储中应用启动时从Redis读取Session请求结束时再写回去。要注意的是你引入的Redis本身也是一个有状态的组件它同样需要考虑高可用——至少要做到主从加哨兵避免Redis一挂所有Session都没了反而引入了新的单点。如果不想维护Redis也可以考虑用JWT这类无状态Token把用户信息直接放进Token里应用侧不需要存储任何会话状态。但JWT有一个被很多人忽略的坑服务端没有办法主动让一个已经签发的Token失效。你设置15分钟过期那用户被踢了之后最长还要等15分钟才能真正失效。实际项目中通常需要引入Token黑名单或短期刷新机制否则注销功能很难做。本地文件和无状态化也是一对矛盾。应用在本地磁盘写日志、传图片、生成临时文件这些都是缺乏全局视角的做法。上传的文件应该收口到对象存储日志应该直接输出到统一采集平台临时文件处理完就该清理。如果一定要在本地写文件至少要做到“过期即删”并且不能假设某台机器上的文件其他机器能访问到。定时任务是最容易被忽略的无状态化盲区。很多人以为定时任务跑在单台实例上没问题结果一旦做了水平扩展任务就会在每台机器上同时执行轻则重复发送通知重则产生脏数据。解决方案是引入分布式锁只用一把锁控制同一时刻只有一个实例真正执行任务其他实例保持待命状态。我见过很多团队在任务执行侧写了一大堆幂等逻辑却没想到在最上面加一个分布式锁更简单。2.3 数据库不是无状态的但它可以“可替换”这里有个常见的思想包袱应用层可以做无状态化但数据库本身明明是有状态的而且是最核心的状态怎么能做到无状态答案是数据库确实做不到无状态但我们可以通过复制技术让每一台数据库节点都变成“可替换”的。MySQL主从复制就是最典型的例子。一个主库负责写一个或多个从库负责读数据通过Binlog异步或半同步地同步到从库。当主库故障时从库虽然可能在数据上有少量延迟但它拥有整个数据集的完整副本可以随时顶替主库对外服务。从业务角度看只要把流量从旧主库切到新主库数据库在逻辑上依然是那个“唯一的数据库”只是物理载体换了一台机器。同理SQL Server的Always On可用性组也是这个思路通过日志流同步将主副本的数据同步到各个辅助副本每个副本都保存着完整的数据集。故障发生时可用性组会把主角色自动转移到另一台副本上对应用的连接使用的是同一个虚拟网络名称应用层甚至感知不到底层切换的发生。这就是“物理有状态、逻辑可替换”的精髓。3. 水平扩展先摊平流量再打散压力3.1 无状态层的扩展是最划算的一旦你完成了无状态化改造水平扩展就会变得非常顺理成章。因为实例本身不带状态你随时可以加机器、减机器只需要确保流量被合理地分发到每一台实例上就行。流量分发最常用的是四层负载均衡和七层负载均衡。如果你工作在传输层可以根据IP和端口转发流量性能高但拿不到HTTP层的信息七层负载均衡可以读取路径、Header、Cookie等数据实现更精细的路由。实际项目中往往是两者搭配外层LVS做四层转发内层Nginx做七层代理。但这里我要提一个反向的教训无状态化改造完成之后水平扩展的一个隐藏瓶颈往往会出现在连接层。很多数据库和中间件对连接数有硬性上限比如MySQL的max_connections默认只有151现在有些版本更高应用实例从5台扩展到50台每台建立50个连接数据库的连接数很快就爆了。所以做水平扩展时一定要同步规划连接池的收敛策略比如使用Proxy层统一收敛数据库连接应用只连接Proxy而不是直连数据库。这样才能保证业务实例随便扩数据库的连接压力不会跟着线性增长。3.2 有状态层怎么扩展读写分离与分片无状态层扩展相对容易真正的复杂度在数据层。数据层扩展的第一级是读写分离把读流量引导到从库上去主库只管写。这一步的实现成本很低只需要在代码里区分数据源或在中间件层做读写路由。但读写分离有一个绕不开的痛点主从延迟。如果你的业务允许读到“稍微旧一点”的数据那主从延迟是可以接受的但有些场景——比如用户刚下了单立刻去查订单详情——如果读到的还是旧状态体验就会变得非常糟糕。常见的解决方案是“写后读一致性”即刚执行过写请求的会话在一定时间内强制走主库读或者通过缓存把最新数据短期保留。当数据量再往上走读写分离就不够用了你还需要做数据分片。分片就是把数据按照某种规则分散到多个数据库实例上每个实例只负责一部分数据。分片键的选择非常关键如果选了性别这种枚举值很少的字段做分片键会导致数据分配严重不均一亿条用户数据男女各半落到两个库上还算平衡但如果是按地区分片而某个地区占了80%的数据热点问题会直接击穿集群。更稳妥的方案是用用户ID或订单号这类高基数字段进行哈希取模分片并配合一致性哈希来应对扩容时的数据迁移。3.3 缓存层高可用架构里的缓冲带谈到水平扩展缓存层是绕不开的。我在高可用架构里特别喜欢把Redis放在数据库前面当“缓冲带”它的作用不仅仅是加速更重要的是削峰。数据库QPS上限可能只有几千而Redis单实例可以扛到十万级。高峰期的大量读请求如果全部打到MySQL上数据库即使没挂也会因为连接堆积导致主从复制延迟变大最终把故障面扩大。有了缓存层热数据全部在内存里兜住数据库的读压力骤降整个系统的抗压能力会提升一个量级。但缓存层也会引入新的高可用问题。Redis本身如果宕机大量请求会穿透到数据库瞬间打垮后端。所以生产环境至少要做Redis主从加哨兵或者直接上Redis Cluster。更重要的是做缓存降级策略当Redis出现大面积故障时业务侧要主动熔断直接走数据库而不是在Redis超时上反复重试把数据库也拖垮。这个“缓存穿透保护”的思路比单纯堆Redis实例更关键。4. 故障转移让故障看起来像没发生4.1 故障转移的三段式发现、切换、恢复故障转移不是“一键切换”那么简单它是三个阶段的连贯动作。第一阶段是发现故障系统需要通过某种机制感知到节点不可用第二阶段是切换把流量和角色从故障节点转移到健康节点第三阶段是恢复把原故障节点的数据补齐让它可以重新加入集群。每一阶段都有各自的坑我一个个说。发现阶段最怕两件事漏报和误报。漏报意味着故障已经发生但监控没触发服务一直黑着直到用户投诉才发现大事不妙误报则是把健康节点误判为故障触发了不必要的切换。所以故障发现必须做“多重确认”不能探测一次失败就立刻判定故障应该连续探测三次以上并且在两个不同维度上同时失败才触发切换比如TCP层连不上同时主从复制心跳也停了。切换阶段要关注的是流量切换和角色切换的先后顺序。拿MySQL主从切换举例必须先提升一个从库为新主库再更新应用侧的连接指向最后把VIP或域名解析漂移到新主库上。顺序反了应用连接被切走了但新主库还没准备好同样会造成服务中断。恢复阶段则是最容易被忽略的旧主库起来之后必须作为新主库的从库重新接入并同步期间缺失的数据绝不能让它稀里糊涂地重新变回主库。4.2 探活机制依赖心跳更要依赖业务探活是故障转移的第一道工序。常见的探活方式包括ICMP Ping、TCP端口探测、HTTP健康检查以及应用层心跳。对于MySQL来说最基础的探活就是mysqladmin ping但只说一句“服务在”是不够的你还需要确认它真的能处理查询。所以更合理的方式是执行一个轻量的SELECT 1甚至检查主从复制的线程状态。我遇到过一种情况MySQL进程还活着TCP端口也通但磁盘满了事务完全无法提交。如果只用mysqladmin ping探测得到的结论是“存活”可实际上整个数据库已经处于半死不活的状态。这里我给一个实用的探活脚本思路放在crontab里每10秒跑一次#!/bin/bash MYSQL_HOST127.0.0.1 MYSQL_USERmonitor MYSQL_PASSmonitor_pass mysql -h${MYSQL_HOST} -u${MYSQL_USER} -p${MYSQL_PASS} -e select 1 /dev/null 21 if [ $? -ne 0 ]; then echo mysql health check failed exit 1 fi # 检查主从是否卡住 SLAVE_STATUS$(mysql -h${MYSQL_HOST} -u${MYSQL_USER} -p${MYSQL_PASS} -e show slave status\G 2/dev/null | grep -E Slave_IO_Running|Slave_SQL_Running) echo $SLAVE_STATUS | grep -q Yes || exit 1关键在于把“进程活着”和“功能正常”区分开探活逻辑必须能够反映业务真正的健康状态。此外探活频率也要控制好探测太频繁会增加系统负担太稀疏又会拖延故障发现时间实践中10秒到30秒是一个比较合理的区间。4.3 选主与脑裂最容易翻车的环节当集群里有多个节点可以被提升为主节点时就必须面临“选主”的问题。选主算法的核心目标是让所有节点对“谁是主”达成一致经典的做法是使用Paxos或Raft这类共识算法。MySQL 8.0的Group Replication和InnoDB Cluster就是基于这类协议实现的它们能在大多数节点存活的情况下自动选出新主。对于传统的主从复制架构选主往往靠外部工具来协调比如MHA或Orchestrator。选主过程最怕的情况是脑裂网络分区导致集群被切成两部分两边各自认为自己是“可用的大多数”于是分别选出了不同的主节点。此时如果两边的Master同时接受写入数据的一致性就被彻底破坏了而且很难在事后自动修复。防止脑裂的通用思路是引入仲裁机制比如控制节点的数量只有票数过半的节点组才能选主或者使用仲裁盘一个节点只有在能够锁定仲裁盘时才有资格当选主对于VIP漂移方案还要配合严格的fencing机制在新主接管之前强制将旧主的网络、服务禁用掉。我在生产环境中见过的最典型的脑裂事故是keepalived配置里没有用组播而是让两个节点都配了同一个VIP结果节点间的心跳断了之后两台机器同时把VIP绑定到自己网卡上。交换机上的ARP表在两个MAC地址之间疯狂抖动大量请求被导去错误的节点。这种问题在架构上做防护比事后处理更有效——主备节点之间一定要有仲裁机制并且要配置nopreempt之类的参数避免异常抢占。4.4 从MySQL到SQL Server两类主流的故障转移方案前面大篇幅讲的是MySQL场景但热词里提到了SQL Server我也单独说几句。SQL Server的高可用方案以Always On可用性组为代表它和MySQL主从复制在思路上有相似之处但也有明显的差异。Always On可以配置同步提交模式也就是说主副本必须等到至少一个辅助副本确认日志已持久化事务才会提交。这相当于把MySQL半同步复制里的“至少一个从库确认”变成了产品级的标准能力数据丢失的概率被降到了很低。Always On的自动故障转移有一个硬性前提可用性组必须配置了辅助副本并且启用了同步提交同时还要有仲裁见证节点。缺少任何一个条件数据库引擎都会拒绝自动转移宁可继续服务也不盲目切换。这一点非常值得MySQL生态学习——别为了追求切换速度牺牲数据一致性。我实际维护过几套Always On最大的体会是它的监听器机制很省心应用只需要连接虚拟网络名称故障转移后监听器自动更新IP应用谈不上什么感知。但它的局限也很明显只支持到可用性组粒度如果业务没有做分库大集群下面的切换粒度会比较粗。5. 三件事的协同设计一份可落地的参考架构5.1 一条完整的请求链路无状态化、水平扩展、故障转移这三件事单独拎出来每一项都能讲半天但它们只有组合在一起才能形成真正的高可用。我直接用一条请求链路来说明它们如何协同。假设用户通过浏览器访问你的站点首先经过DNS解析DNS背后是负载均衡器的VIP。如果SLB本身做了主备部署当主负载均衡器故障时备用节点通过VRRP协议抢占VIP这是一层故障转移。流量到达应用集群之后任一台无状态应用实例都可以处理请求。这里体现的是水平扩展的价值10台实例扛不住就加到20台每台实例都是可替换的。应用处理过程中需要读取用户状态Session数据在Redis里于是Redis就必须是高可用的Redis哨兵集群监测主节点故障并自动提升从节点这是第二层故障转移。应用需要查询数据库时连接池通过读写分离中间件或Proxy读取数据常规查询走从库写操作走主库。从库副本可以随时扩展这是数据层的水平扩展。最后MySQL主从复制和MHA/Orchestrator构成了数据库层的故障转移当主库故障时自动提升一个新主库并且切换VIP漂移同时把应用的数据源指向新主库。整条链路里每个环节都有冗余、有探活、有切换才能做到某个节点故障时其他部分照常运转。5.2 主库故障时的完整动作序列我把一次MySQL主库宕机到恢复的完整动作序列整理成一张清单这张清单也是我实际运维过程中逐步打磨出来的可以直接作为你设计切换流程的参考。阶段动作关键点发现监控连续三次探测失败触发告警不要用单次失败做决策确认检查从库的Relay Log和主库的Binlog位点确认数据差距评估丢数风险预检检查新主库的复制线程是否健康不健康的节点不能参与选主切换提升从库为新的主库关闭只读模式必要时补收旧主的Binlog后半段流量切换把VIP漂移到新主库或更新应用的连接配置先角色切换后流量切换旧主恢复旧主库上线后以从库身份重新加入到新主用GTID自动找位点避免人工设置错位校验验证数据一致性检查复制延迟归零确认业务请求正常切换完成这里重点说两个容易翻车的细节。第一如果在异步复制模式下旧主库宕机前最后几条事务还没传到从库那切换后这些数据就丢失了。你要么接受这个事实要么在切换前做日志补偿把旧主库的Binlog尾部尽量追平。第二切换完流量之后一定要回收旧主库的写权限。旧主库恢复后如果它还保留着原来的VIP并且没有意识到自己已经不是主节点就可能出现双主写入造成数据不一致。所以“旧主降级为从库”这个动作必须自动执行而不是等人手动处理。5.3 同城双活与两地三中心的取舍再往上走一层很多业务已经开始做同城双活甚至两地三中心了。同城双活就是把应用集群和数据库集群分别部署在两个机房两个机房间的网络延迟一般在1毫秒以内可以做到数据库层实时同步。理论上任意一个机房挂掉另一个机房可以完全接管全部流量这就是机房级别的故障转移。但有两个现实问题必须面对。第一是机房间网络中断的风险一旦网络分区两个机房都可能认为对方故障从而各自启动故障转移最终出现双主写。解决的办法还是那一套引入仲裁节点而且仲裁节点最好放在第三个机房或者使用云厂商提供的跨区域仲裁服务。第二是数据层双活对同步链路的要求极高同城双活下MySQL通常要配置双主加半同步复制SQL Server则用Always On的多副本同步提交。如果主备之间的链路延迟超过几毫秒每个写请求都会被拖慢这时就要权衡是牺牲性能换取绝对可用性还是接受小概率的数据丢失来保证更低的延迟。6. 故障转移的常见问题与排查实录6.1 转移失败的第一嫌疑探活误判我调试过很多次故障转移失败的问题总结下来第一嫌疑永远是探活逻辑本身。最常见的是探活的判定条件设置得太宽比如只检查端口连通性导致进程“半死”时没有被及时发现或者反过来探活条件太苛刻比如依赖某个只在极少数情况下才执行的SQL语句造成大量误报系统频繁触发无意义的切换。让我印象最深的一个案例是某次主库其实没有故障只是监控账号用的密码过期了导致探活脚本开始报错。连续几次误报之后触发了自动切换流程生产环境在完全没有必要的情况下做了一次主从切换。由于切换脚本里没有做足够的延迟检查切换后从库立刻承担了主库压力几分钟后的确因为自身延迟太大而拖垮了业务。整个事故的根因恰恰是探活机制本身出了问题。所以探活配置一定要避免“单一信息源”至少同时使用TCP连接和SQL查询两个维度并且在做切换决策前确认故障是真实存在的。6.2 主从延迟引发的数据丢失异步复制最大的软肋是主从延迟。延迟如果只是几百毫秒大多数业务都能接受但一旦主库在高峰期短时写入量暴涨——比如秒杀、结算场景——延迟可能会飙升到分钟级。这时候如果发生主库宕机这些延迟期间的数据就全部无法同步到从库业务会直接丢失几分钟的数据。预防方案就是把复制模式从异步升级为半同步MySQL半同步复制虽然会略微增加事务提交的响应时间但主库会等待至少一个从库收到Binlog后才会向客户端确认提交成功这就能把丢数据的窗口压缩到接近于零。SQL Server的Always On同步提交也是同样的设计理念。值得注意的是“半同步”不只是在数据库配置里改一个参数它要求你的应用连接本身也具备重试和幂等能力。一旦半同步因为从库ACK超时而退化为异步应用侧的请求其实并没有真正提交成功但客户端并不知道因此要有超时重试的机制去兜底。我见过太多团队把半同步打开之后就卸下了所有防备结果一次从库故障导致半同步降级数据还是丢了而他们完全没有感知。6.3 脑裂的兜底方案前面多次提到脑裂这里再补充一个实战中非常有效的兜底方案切换流程里强制加入“fencing”步骤。在数据库主从切换场景中保新主的手段往往就是“把旧主的写权限剥夺掉”。比如MHA切换脚本里会执行masterha_master_switch并借助SSH登录旧主把它设为只读而更保险的做法是从硬件层面把旧主的网络隔离掉或通过带外管理系统直接断电。如果你觉得断电太重至少要做到任何节点只有在确认自己拿到“锁”之后才有资格成为主库拿不到锁就自动降级。对于keepalived这类基于VRRP的场景防脑裂的主要手段是仲裁节点并且要开启nopreempt配合优先级策略。我见过一个比较稳妥的组合两个数据库节点通过keepalived共享一个VIP同时引入一台独立的仲裁机当主备之间的心跳断开时双方每次都去仲裁机注册状态只有注册成功的节点才能拥有VIP。这样即使两个节点都活着也不至于同时对外提供写服务。6.4 一份故障转移排查速查清单结合我自己处理的案例我把故障转移排查的要点整理成一份速查清单日常巡检或故障复盘时可以直接对照着看。探活脚本是否同时覆盖了进程、端口、SQL执行三个层面探活失败次数阈值设的是多少连续几次失败才触发切换主从复制链路是否有延迟监控延迟峰值是多少有没有告警切换时是否先提升了从库角色再更新连接指向旧主恢复后是否会自动降级为从库并重新追平数据有没有双主写保护机制如写权限检查、VIP仲裁半同步复制是否启用如果启用降级条件是什么应用层是否具备重试、幂等能力切换期间是否会报大量错误有没有定期演练切换演练时切换时长是多少最后一条“定期演练”往往是最容易被忽视的。很多团队的切换脚本写得看起来很完善但半年没执行过一次。真到故障发生时才发现脚本里有一处硬编码的IP早就过期了或者SSH免密钥失效了。所以每季度至少做一次主从切换演练并且把切换时长控制在分钟级这对生产系统的可靠性提升非常明显。7. 写在最后我的几点实操经验文章讲到这里三件事的协同逻辑已经比较完整了。最后再分享一点我个人在实际操作中的体会。无状态化是最难推动的一件事因为它涉及的是“思维方式的转变”而不是“装一个工具”。很多团队的应用代码运行了好几年代码里到处是本地缓存、本地文件、线程局部变量要真正把状态全部外置需要投入大量的重构工作而且短期看不到收益。我的建议是不要指望一步到位可以先挑最容易出问题的点下手先做Session外置再做定时任务收敛然后是本地文件归口。每改动一步高可用能力都会上一个台阶。故障转移方案的选择永远是在性能和一致性之间做权衡。如果你一开始就追求“绝不丢数据”就要接受切换时的延迟和架构复杂度如果你的业务允许微小数据丢失优先选择简单方案至少比一个复杂但没人能维护的方案靠谱得多。这里我想强调一点高可用系统最大的敌人不是故障本身而是你过于自信地认为自己不需要演练。我个人的经验是每半年做一次全链路故障演练人为制造一次“主库宕机”观察系统能不能自动完成发现、切换、恢复的全流程。只有真正演练过你才知道自己的高可用设计是纸面文章还是能打的实战能力。这也就是我文章开头所说的——高可用不是某一项技术而是一整套协同设计。把无状态化、水平扩展、故障转移放在一起反复推演你总能在系统真正出问题之前发现那些藏在角落里的盲区。
