双机热备简单来讲，就是两台服务器互相监测状态，一台故障之后另一台自动接管，业务不会直接中断。这套方案用来解决单点故障，硬件损坏、系统崩溃、网线断开这类情况没办法彻底杜绝，但依靠双机热备，终端用户基本感知不到故障发生。核心思路就是冗余部署，额外准备一套备用系统，平时闲置待命，一旦出现异常就接手业务。
市面上主流有三种实现方式，主备、互备、双机双工，名称看着相近，实际运行逻辑差别很大。
主备模式理解门槛最低。两台服务器，一台作为主机对外提供服务，备机不承接业务流量，依靠心跳链路持续和主机通信。心跳链路可以用网线直连，也能依托现有网络，持续检测对方是否正常运行。主机一旦失去响应，备机就判定主机故障，启动接管流程，把虚拟IP迁移到自身，挂载共享存储并启动对应服务。对外访问的IP地址保持不变，业务持续可用，只是后台服务切换到另一台机器。这种模式部署简单，配置工作量小，备机不参与业务运算，不会和主机争抢资源。但资源利用率偏低，备机长期闲置，硬件投入没法充分利用。还有一个风险点，切换过程中如果主机没有完全停止运行，两台机器同时挂载共享存储，会造成数据损坏。所以主备部署一般需要搭配仲裁机制，或是采用STONITH强制断电方案，确认主机彻底停止工作之后，备机才执行接管。
互备模式可以充分利用两台服务器的硬件资源。每台机器各自运行独立业务，比如一台承载Web服务，另一台运行数据库。两台服务器互相监控，A服务器宕机，B服务器接手A的应用；B服务器故障，A服务器也会接管B的业务。对比主备模式，硬件资源利用率更高，不会出现单台服务器长期闲置的情况。但配置复杂度会上升，每台服务器都预留足够硬件余量，保证可以同时承载两套业务。同时需要梳理清楚应用之间的依赖关系，Web服务切换之后，数据库连接能否同步迁移，这些细节处理不到位，切换操作没有实际意义。互备更适合应用耦合度低、能够独立切换的场景。
双机双工，也常被叫做集群模式，和前面两种方案有明显区别。两台服务器同时运行同一套应用，共同对外提供服务。用户请求会分发到两台服务器，一般会在前端部署负载均衡器做流量分配。优势在于整体性能更强，两台设备都持续处理业务，不存在资源浪费。单台服务器故障，剩下的机器直接承接全部流量，切换过程用户几乎没有感知，因为服务本身没有中断。但落地难度最高，应用本身需要支持集群部署，数据要实时同步，会话状态要么共享要么复制，不然用户第一次请求访问A节点，下次请求落到B节点，登录状态就会丢失。数据库场景的实现难度更大，双机同时读写数据库，锁机制与数据一致性问题需要提前处理，处理不当反而会造成性能下降。
无论选用哪一种模式，都离不开几个基础组件。心跳网络必不可少，用来检测对端服务器状态，心跳链路中断，整套热备机制就失效。共享存储也很常用，主备和互备场景大多要求两台服务器访问同一份数据集，切换完成之后数据不能丢失。虚拟IP或者浮动IP，用来保证切换之后对外访问地址不变，用户不需要修改任何配置。仲裁机制用来规避脑裂问题，也就是心跳断开之后，两台服务器都判定对方故障，争抢资源。脑裂带来的后果很严重，两台机器同时写入共享存储，数据大概率直接损坏。解决方式可以部署冗余心跳线路，或者使用仲裁盘、ping网关的方式判定服务归属。
双机热备并不是万能方案。业务切换存在耗时，几秒到几分钟都有可能，取决于应用启动速度和数据恢复流程。数据一致性依靠共享存储或者数据复制技术保障，如果采用异步复制，切换阶段可能丢失末尾少量数据。如果应用本身不支持热备架构，强行做切换反而引入更多故障。实际部署的时候，先评估业务能够容忍的中断时长，再挑选合适的模式，不要盲目选用双机双工。