你买了两台服务器，一台跑业务，一台闲着。有人问你为什么？你说“以防万一”。但真到了第一台挂了的时候，你发现第二台根本不会自动接管。你只能手动改IP、启动服务、祈祷数据别丢。花了20分钟，用户已经跑了。你意识到你的备用服务器只是一台昂贵的摆件。
单点故障不是你不想解决，是不知道从哪开始。
单点故障：你有一个点坏了，整个系统就坏
单点故障（SPOF）定义很简单：系统中一个部件失效，就会让整个系统无法运作。用一台服务器跑业务，这台服务器就是单点故障。它坏了，你的业务就停了。无论你后面配置多好、优化多到位，只要这个点还在，整个系统就不算高可用。
硬件：服务器主板烧了、电源坏了、网卡失效。软件：操作系统崩溃、进程挂死、内存泄漏。网络：交换机故障、网线断了、ISP线路中断。人为：误操作删了关键数据、配置错误导致服务起不来。环境：机房断电、空调失效、火灾。
高可用的两个关键指标
99.9%允许一年宕机8.76小时；99.99%允许52.6分钟；99.999%允许5.26分钟。你的业务需要几个9，取决于宕机一分钟损失多少钱。
设计高可用系统，核心是两个指标：RTO（恢复时间目标）——从故障到恢复需要多久；RPO（恢复点目标）——能容忍丢失多少数据。RTO决定你能接受多久停机，RPO决定你能接受丢多少数据。前者影响你买几台备用机器，后者决定你花多少钱做同步。
消除单点故障的四个核心手段
手段一：冗余——不要只有一个
任何一个可能坏的东西，至少准备两个。两台服务器、两条网线、两个电源。一台坏了，另一台顶上。代价是成本翻倍。但这是高可用的基础——没有冗余就没有容错。
手段二：负载均衡——把流量分散到多台
冗余只是多放了台机器，用户请求还指向固定IP，那台机器挂了用户照样访问不了。负载均衡器接收流量，分发给后端多台服务器，定期检查健康状态，自动隔离异常实例。Nginx、HAProxy和云厂商的LB都支持这个功能。这是访问层消除单点故障的方案。
手段三：故障转移——让它自己切
负载均衡解决的是接入层，如果数据库主库挂了，需要自动切换到备库。云数据库主备切换，当主实例发生故障时自动触发，切换后连接地址不变。自建环境用Keepalived实现虚拟IP漂移——主服务器挂了，VIP自动移到备机。故障转移必须够快，否则RTO无法满足。
手段四：数据同步——备机要有最新数据
只有冗余没用，备机的数据必须和主机一致。数据库层面，MySQL主从复制实现实时同步，故障时备机数据是完整的。文件层面，用rsync定时同步或分布式存储。
从单机到高可用的演进路径
第一阶段：单机——一台服务器跑所有业务，成本最低，风险最高。
第二阶段：主备——一台跑业务，一台闲着等故障。数据实时同步（数据库主从复制、文件rsync同步）。故障时手动切换（RTO取决于响应速度），或者用Keepalived自动切换。成本翻倍，可用性大幅提升。
第三阶段：双活——两台都跑业务，负载均衡分发流量。一台挂了，另一台继续服务，用户无感知。数据库一主一从，读请求可以分担到从库。这是大多数业务的最佳平衡点。
第四阶段：多活——多台服务器同时服务，跨可用区部署。一个可用区整个挂了，其他可用区继续服务。
一个真实案例
一家电商公司，数据库只有一台。某天凌晨硬盘故障，网站挂了2小时。恢复后发现丢了半小时订单数据。事后部署了云数据库主备实例，开启自动切换，RTO从2小时降到1分钟以内。数据定期备份到异地对象存储，RPO从30分钟降到5分钟以内。
最后一句
高可用听起来复杂，但核心就是解决一件事：你那个关键部件万一坏了，谁来替它干活？ 一台服务器不够就两台，两条网线不够就四条。负载均衡分发流量，Keepalived自动切换，数据实时同步。高可用不是一蹴而就的——先解决服务器单点，再解决数据库单点，最后解决机房单点。一步步来，你的系统会越来越扛揍。