4、双机热备架构：主备切换机制、心跳检测原理、共享存储与镜像存储方案对比
双机热备，说白了就是给SCADA系统找个「影子兄弟」。
一台干活，一台待命。主节点挂了，备用节点立刻顶上。我见过不少项目，客户觉得双机热备是浪费钱，结果一次控制器宕机，整条产线停了三个小时。嗯，从那以后，再没人跟我提「单机够用」这种话了。
4.1 主备切换机制：不是简单的「拔插头」
很多人以为主备切换就是「主节点断电，备用节点启动」。其实没那么简单。真正的切换机制，要解决三个核心问题：
- 谁来决策切换？ 是主节点自己说「我不行了」，还是备用节点发现主节点没动静了？
- 切换条件是什么？ 是CPU过载？网络中断？还是磁盘写不进去了？
- 切换后怎么恢复？ 主节点修好了，是自动切回去，还是手动干预？
我个人习惯把切换机制分成三种模式：
| 模式 | 触发方式 | 典型场景 | 我踩过的坑 |
|---|---|---|---|
| 手动切换 | 运维人员操作 | 计划性维护、系统升级 | 有一次忘了切回主节点，备用节点跑了三天才发现 |
| 自动切换 | 心跳丢失 + 超时 | 突发故障、网络中断 | 超时设得太短，网络抖动就切了 |
| 半自动切换 | 系统检测到故障，但需人工确认 | 关键工艺段、不允许误切换 | 这个最稳，但考验值班人员的反应速度 |
你想想看，如果一条化工产线正在反应釜升温阶段，突然因为网络延迟触发了切换，备用节点还没来得及同步温度数据……后果是什么？所以，切换机制一定要跟工艺风险挂钩。
核心原则：切换不是越快越好，而是「该切的时候必须切，不该切的时候坚决不切」。
4.2 心跳检测原理：别让「假死」骗了你
心跳检测，就是主备节点之间互相「报平安」。我见过最原始的方式——两个PLC之间拉一根硬线，每隔100ms发一个脉冲。后来慢慢演变成网络心跳、应用层心跳。
这里有个关键点：心跳丢失 ≠ 节点故障。
我曾经在一个项目中遇到过：主节点CPU负载冲到95%，但心跳线程优先级太低，发不出心跳包。备用节点一看，心跳丢了，立刻切换。结果呢？两个节点同时在线，数据写乱了。这就是典型的「假死」问题。
解决思路其实不复杂：
- 多维度心跳： 不光看网络通不通，还要看CPU利用率、内存占用、关键进程是否存活。
- 心跳超时分级： 一级超时（比如100ms）只告警，不切换；二级超时（比如500ms）才触发切换。
- 仲裁机制： 引入第三方仲裁节点，避免「脑裂」——就是两个节点都以为自己是主节点。
我的小技巧：心跳检测的周期不要固定。我习惯用「动态心跳」——正常时100ms一次，负载高时自动延长到200ms。这样既保证实时性，又不会在高峰期雪上加霜。
4.3 共享存储 vs 镜像存储：两种思路，两种代价
双机热备最头疼的问题就是数据怎么同步。说白了，主节点写进去的数据，备用节点必须也能读到。目前主流方案就两个：共享存储和镜像存储。
4.3.1 共享存储方案
共享存储，就是主备节点共用一块磁盘阵列。主节点写数据，备用节点直接读同一块盘。
优点很明显：
- 数据一致性天然保证——大家读的是同一份数据
- 切换速度快——备用节点不需要同步数据，直接接管
- 管理简单——就一套存储，不用考虑数据同步问题
缺点也致命：
- 单点故障： 存储挂了，两个节点都完蛋。我见过一个项目，存储控制器坏了，双机热备变成了双机冷备——全废了。
- 成本高： 企业级磁盘阵列、光纤交换机，一套下来几十万很正常。
- 距离限制： 共享存储通常要求主备节点在同一个机房，距离不能超过几百米。
注意：共享存储方案中，一定要用集群文件系统（比如OCFS2、GFS2），否则两个节点同时写同一块盘，数据就乱套了。我早期吃过这个亏，两个节点同时写历史数据库，结果文件索引全坏了。
4.3.2 镜像存储方案
镜像存储，就是主备节点各自有独立的存储，通过网络实时同步数据。
优点：
- 高可用性： 任何一个节点的存储坏了，另一个节点还能正常工作
- 地理容灾： 主节点在北京，备用节点在上海，只要网络带宽够，就能做镜像
- 成本可控： 不需要昂贵的共享存储设备，普通服务器硬盘就行
缺点：
- 数据延迟： 同步需要时间，极端情况下可能丢数据。我测过，千兆网络下，同步1MB数据大约需要10-20ms。
- 一致性难保证： 如果主节点在同步完成前就挂了，备用节点上的数据就是「旧版本」。
- 带宽占用： 实时同步会吃掉大量网络带宽，尤其是历史数据量大的时候。
4.3.3 怎么选？我给你个参考
| 对比维度 | 共享存储 | 镜像存储 |
|---|---|---|
| 数据一致性 | ★★★★★ | ★★★★ |
| 切换速度 | ★★★★★ | ★★★★ |
| 容灾能力 | ★★ | ★★★★★ |
| 成本 | 高 | 中 |
| 维护复杂度 | 低 | 高 |
| 适用场景 | 同机房、对数据一致性要求极高 | 异地容灾、预算有限 |
我个人建议：关键工艺段用共享存储，非关键段用镜像存储。如果预算充足，可以两者结合——共享存储做主备切换，镜像存储做异地备份。
避坑指南：我曾经在一个项目中，客户坚持用镜像存储做实时数据库同步。结果历史数据量太大，网络带宽撑不住，同步延迟从几秒变成了几分钟。最后不得不改成「增量同步 + 定时全量同步」的混合模式。所以，选方案之前，一定要先算清楚数据量和带宽。
4.4 一个实际案例：某水厂SCADA双机热备改造
去年我参与了一个水厂的项目。原来的单机SCADA系统，控制器坏了三次，每次都要停水两小时。客户受不了了，要求上双机热备。
我们最终选的是：
- 切换机制： 半自动切换。系统检测到故障后，先发告警给值班人员，30秒内无人确认才自动切换。
- 心跳检测： 多维度心跳，包括网络、CPU、关键进程。超时设为500ms，避免网络抖动误切。
- 存储方案： 共享存储（双控制器磁盘阵列）+ 镜像存储（每天凌晨全量同步到异地）。
改造完成后，半年内发生了两次自动切换，每次切换时间不超过5秒。客户很满意，说「终于不用半夜爬起来手动切了」。
嗯，这就是双机热备的价值——不是让你永远不出故障，而是出了故障，系统还能自己扛住。