我信了高可用，系统却崩了，这破玩意儿到底怎么用？

我干了几年后端，天天听人讲高可用。以前觉得，高可用嘛，多搞几台服务器，出问题自动切换就行了。但真遇到线上故障，才发现自己太天真了。

高可用这词听着挺唬人，说白了就是承认系统会挂，然后想办法在它挂的时候让业务别断。不是让你保证不宕机，而是让你在宕机的时候还能让用户感觉不到。

冗余是基础，但冗余不是越多越好。两台机器确实比一台强，但加十台就带来一堆新问题，比如数据同步慢了，网络开销大了，搞不好还容易出乱子。冗余得有层次，服务器、链路、数据、机房，每个层面都得考虑。

自动故障转移才是高可用的灵魂。你不可能每次故障都人工去切，那黄花菜都凉了。关键是要有第三方工具来做心跳检测，不光看死没死，还得看响应快不快。比如一个节点慢得像蜗牛，你还当它是健康的，那所有请求都堵在那，整个系统就废了。

接入层最常见的就是Nginx或者LVS做主备，配合Keepalived做IP漂移。这样前端用户的请求不会因为一台机器挂了就断掉。但要注意健康检查脚本不能只检查返回200，还得检查响应时间，避免慢节点拖累全局。

微服务那一套，本质上就是服务之间互相发现，谁挂了就自动踢掉。注册中心像ZK或者Nacos，服务提供者注册进去，消费者从那里拿健康列表。注册中心本身也得高可用，不然它自己挂了，整个系统就瞎了。

中间件这块最复杂。Redis要么主从加哨兵，要么Cluster。主从哨兵解决单点问题，但哨兵切换的时候会有短暂不可用，而且主从之间数据同步可能有延迟，丢数据是难免的。Cluster能扛更大压力，但跨分片操作很麻烦，一旦分片调整，数据迁移也很头疼。

ES和Kafka都是分片架构，主分片负责写，副本分片负责读或者备份。节点挂了，系统会自动把分片挪到别的节点上。但这个过程里，数据一致性会受影响，有些数据可能暂时查不到。

存储层是最后一道防线，MySQL主从复制加Keepalived是最常见的方案。但异步复制会丢数据，半同步复制好一点，但性能有损失。真遇到主库挂了，从库切换上去，那几秒内的数据可能就没了。所以关键业务还得做更复杂的多节点复制。

高可用不只是技术，还有流程。事前要做压测，要搞混沌工程，主动往系统里塞故障，看看它能不能自己恢复。事中要有熔断限流，保护核心链路不被冲垮，还要有降级方案，比如把非核心功能关掉，不让用户看到错误页面。事后要复盘，不追究谁的责任，只找根因，然后改进。

说白了，高可用就是一场永无止境的打怪升级。你以为搞定了，下次又有新问题。但这就是工程，承认失败，然后想办法让失败的影响降到最低。最终目标就是让用户该干嘛干嘛，系统崩了也感觉不到。这才叫真高可用。