无论业务多小，只要开始谈高可用，第一步永远是先做“单点故障清单”，而不是急着买双机热备软件。你的核心诉求是让业务告别“一台机器挂了，全公司跟着放假”的尴尬，路径只有一条：把风险从硬件转移到架构上。
单台物理机撑不住时，最先暴露的往往不是性能瓶颈
很多团队以为扩容是因为CPU满了,实际上超过半数的情况是因为磁盘IO或内存先被打满，单机时代，所有组件挤在同一台机器上，MySQL和Web服务互相抢资源，这是最典型的隐性炸弹，判断是否需要进入高可用阶段，看三个信号：数据库连接数经常打满、凌晨的备份任务会拖垮白天业务、机房一断电就得全员等着，这三条占两条，就该动手了。
高可用架构不是玄学,本质就两件事：冗余和故障转移，物理机上跑着Apache或Nginx，数据库用MySQL，文件存在本地磁盘，这是标准的单体结构，改造的第一原则是先把服务拆开，再做冗余，顺序反了会给自己埋雷。
第一阶段：先做应用层与数据层的逻辑拆分
不用一上来就上K8s,那是给自己找麻烦，最平滑的路径是先把单机里的角色物理拆开：一台跑Nginx和PHP-FPM，另一台专门跑MySQL，这一步不增加所谓的高可用能力，但能让你看清楚每个组件真实的资源消耗，为后面的冗余做准备。
拆分之后,Web服务器上的本地磁盘存放用户上传的图片和附件，这是最大的隐患，你应该在拆分的同时，把静态文件迁移到对象存储，比如简米云OSS或酷番云COS，迁移方法并不复杂：写一个同步脚本，先把本地目录文件传到bucket，然后改Nginx配置，将静态资源请求直接反代到对象存储域名。
业内专家指出,这个阶段最常见的错误是继续使用NFS共享存储，一旦NFS服务器本身宕机，所有Web节点全部瘫痪，等于把单点从一台机器转移到了另一台机器。
拆分后你必须做的三件事
- 修改MySQL的
my.cnf，把innodb_buffer_pool_size调到物理内存的70%左右，这是OLTP场景最稳妥的配比。 - 在Web机器上安装
sysstat工具集，用iostat -x 1和sar -n DEV 1监控磁盘与网卡，观察一周，确定真正的瓶颈维度。 - 把PHP-FPM的
pm.max_children从默认值改成按内存计算后的数值，公式是物理内存/单个进程平均内存占用，否则并发一上来进程直接OOM。
第二阶段：按业务容忍度分层做冗余
这套架构跑稳两个月后,就该考虑冗余了，不要把Web和数据库放到同一批机器上去扛，分层做，每层的目标不同。
Web层：便宜量大，用负载均衡解决一切
Web服务是无状态的,这意味着你可以无限横向扩展，花钱买两台低配物理机，或者直接在原有物理机旁加一台，然后用Keepalived加Nginx搭建主备负载均衡。主节点分发请求，备节点实时同步配置，主节点宕机，VIP自动漂移，整个过程对用户无感知。
虚拟IP的切换时间取决于Keepalived的virtual_router_interval设置，行业共识认为2秒内完成切换是比较合理的配置，你需要确保后端Web服务器上的session已经改为Redis存储，否则用户登录状态会在故障转移后丢失，这比网站打不开还影响体验。
数据库层：高可用是核心矛盾，也是价格差距最大的地方
数据库的高可用方案,决定了整个架构的档次，也直接关系到你的钱袋子，单台物理机迁到高可用架构需要多少钱，这个问题没有固定答案，因为数据库层的选择从几千到几十万都有可能。
如果你的业务允许少量数据丢失，用MySQL主从异步复制加上MHA或者Orchestrator做自动故障转移就足够了，主库写，从库读，主库出问题后，从库被提升为新主库，数据丢失窗口通常控制在1秒以内。
如果业务要求零丢失，必须上MySQL Group Replication或InnoDB Cluster，要求所有节点都确认写入才返回成功，写入性能会有明显下降，但数据绝对安全，代价是硬件成本翻倍、性能折损30%以上。
数据库高可用搭建的常见做法
- 在两台物理机上分别安装MySQL 8.0，配置
server-id和binlog格式为ROW。 - 在主库上创建专用复制账号,用
mysqldump或xtrabackup做一次全量备份恢复到从库。 - 配置主从复制链路后,一定要执行
CHANGE MASTER TO后添加MASTER_AUTO_POSITION=1，开启GTID模式，后续切换不会出现日志位置错乱的问题。 - 配合
Consul或etcd做监控与自动切换脚本，检测到主库连续3次心跳失败就自动提主。 - 对于读多写少的业务,在从库前再挂一个
ProxySQL做读写分离，否则所有读流量依然会打到主库，冗余形同虚设。
第三阶段：物理机迁移到云服务器才是性价比拐点
自建机房双机热备的成本,对比云上高可用架构，差距主要不在机器本身，而在运维人力和网络带宽，物理机需要你维护交换机、电源、UPS、硬盘阵列卡，这些隐性成本远超硬件采购价。
近几年,越来越多公司选择把业务从物理机迁到云服务器，用云服务器免去了硬件维护，但高可用逻辑并没有变：两台同配置的云服务器放在不同可用区，前端挂一个SLB（Server Load Balancer），后端数据库用云上RDS的主备高可用版，默认就是双机热备加自动切换，不需要自己写脚本。
这套组合不是最便宜的方案,但却是故障恢复时间最短的方案，云厂商的SLA承诺通常为95%，折算下来一年故障时间不超过5小时，自建机房想达到这个水平，预算不是翻倍的问题，是没法量化的问题。
两套方案核心差异对比
| 对比维度 | 自建物理机双机热备 | 云服务器高可用架构 |
|---|---|---|
| 初始成本 | 两台机器加存储，一次性投入大 | 按时付费，起步便宜，长期用有包年优惠 |
| 故障切换速度 | 依赖Keepalived或MHA脚本，秒级到分钟级 | SLB探测秒级摘除，RDS主备切换约30秒 |
| 扩展能力 | 需要采购硬件，等待周期以周计算 | 控制台点几下，几分钟内完成扩容 |
| 运维负担 | 需要专职DBA或运维工程师 | 云厂商承担底层基础设施运维 |
如果你的业务在北上广深杭这类一线城市，云厂商在这些区域都有多个可用区，同城容灾完全没问题，如果是二三线城市的传统企业，机房托管费用更低，但对运维人员的要求反而更高。
第四阶段：高可用不等于零丢失，需要分清RTO与RPO
很多第一次接触高可用架构的人有个误解,以为做了双机热备就万事大吉，实际上RTO与RPO是两个必须分开量化的指标。
- RTO（恢复时间目标）：从故障发生到业务恢复，允许的最长时间。
- RPO（恢复点目标）：故障发生时，最多能容忍丢失多少时间的数据。
物理机双机热备模式下,RTO可以做到30秒内，但RPO取决于复制方式，半同步复制可以把RPO压缩到秒级，但不可能归零；只有MySQL Group Replication或InnoDB Cluster这种强一致性方案，RPO才真正趋近于0。
这里有一个你必须清楚的操作细节：任何高可用方案都无法解决“脑裂”问题，当主备之间网络中断时，备机无法确定主机是否存活，如果此时备机强行接管，就会出现两台机器同时写入的混乱状态，高可用架构在故障场景下最核心的动作其实是宁可等待，也不抢主，给你的脚本加上合理的等待时间，比加任何监控都重要。
大数据量场景下,全量备份会占据大量网络带宽，高峰期容易拖垮业务，行业共识认为，全量备份放在业务低峰期，增量备份每5分钟做一次，这是性价比和安全性之间最平衡的配置。
硬件不足或预算有限时，还有一条中间路线
如果你的预算确实紧张,或者业务流量还不足以支撑起完整的双机热备，退而求其次的方案是：一台物理机加一台异地主备机，使用云厂商的对象存储作为数据兜底，数据库每天做一次mysqldump，将备份文件压缩后传到对象存储的冷备层，成本极低，主机宕机时，从对象存储拉取最新的备份文件，在备用物理机上恢复，RTO可能长达2小时，但相比全军覆没已经是巨大的进步。
不把鸡蛋放在一个篮子里,域名解析也可以做一层轻量级的高可用，用简米云DNS或DNSPod的负载均衡功能，同一个域名解析到两台物理机IP，权重各设50，配合TCP健康检查，宕机后解析自动摘除故障IP，这个方案不用改任何应用代码，但受制于DNS缓存时间，切换可能需要5到15分钟。
常见问题
单台物理机扩到高可用架构需要多少钱？
最低配的完整方案：两台云服务器加云数据库高可用版，大约每年投入2万到4万元（根据配置浮动较大），自建机房物理机方案中，两台服务器加上交换机不贵，贵在电力、带宽和专职运维的人力成本，需要结合业务体量评估。
单机和双机热备在性能上有多大差距？
性能上双机热备通常不升反降，因为主从复制有延迟，强一致性方案对写入性能有损耗，高可用解决的是可用性，不是性能，如果想提升处理能力，需要的是负载均衡加水平扩展，而非简单的双机热备。
Web服务器高可用和数据库高可用可以同时做吗？
完全可以,而且必须同时做，两者相互依赖，Web层无状态，扩展最容易，数据库层有状态，是架构中的核心单点，不做冗余则高可用不完整，切换时先恢复数据库层，再启动Web层，业务才能完整恢复，具体做法是，在数据库层硬件故障时，RDS实例会自动切换，建议提前在应用连接串中配置多个只读地址，保证读流量不受故障影响，避免因链路灾备导致的额外延迟。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/785793.html
