核心概念解析：心跳机制、虚拟IP、资源组、故障切换、回切与脑裂
各位同学，欢迎来到双机热备架构设计的核心章节。说实话，很多运维干了三五年，对这几个概念还是模棱两可。我见过不少线上事故，说白了就是没搞懂这些基础概念之间的关联。今天咱们一个一个掰开揉碎了讲。
1. 心跳机制：集群的“脉搏”
心跳机制，你可以把它想象成两个人互相喊话：“你还活着吗？”对方回答：“活着呢！”
在双机热备里，主备节点之间会通过专用链路（通常是独立的网卡或串口线）定时发送心跳报文。这个报文很小，就几个字节，但承载的意义重大——它决定了整个集群的生死存亡。
关键参数：
- 心跳间隔： 一般设为1-3秒。太短了浪费资源，太长了故障发现慢。
- 超时次数： 连续丢失3-5次心跳，就判定对方挂了。
- 心跳链路： 我建议至少两条，一条网线一条串口线，防止单点故障。
我在项目中遇到过一件事：某次机房网络波动，心跳包丢了两次，但第三次又通了。结果集群没切换，但业务已经受了影响。后来我把超时次数从3次改成了5次，配合更灵敏的应用层检测，问题才解决。
我的经验： 别只用网络心跳。我曾经见过一个案例，网卡驱动bug导致心跳包能发出去但收不到，结果两台机器互相认为对方挂了，同时抢VIP。加一条串口心跳做仲裁，能有效避免这种坑。
2. 虚拟IP（VIP）：业务的“门牌号”
虚拟IP，简称VIP。它不绑定在任何物理网卡上，而是由集群软件动态管理。客户端访问服务时，永远只认这个VIP。主节点挂了，VIP自动漂移到备节点上。
你想想看，如果没有VIP，客户端得记住两台机器的IP。主挂了，手动改配置？那运维不得累死。VIP的存在，让故障切换对客户端完全透明。
VIP的漂移过程：
- 主节点发送免费ARP，告诉交换机：“这个IP现在归我了。”
- 交换机更新MAC地址表。
- 后续发往VIP的流量，全部导向新主节点。
注意： 我曾经遇到过ARP缓存导致的问题。主备切换后，部分交换机或客户端还记着旧的MAC地址，流量依然发往故障节点。解决办法是：切换时强制发送多次免费ARP，或者在交换机上开启ARP老化加速。
3. 资源组：把鸡蛋放在一个篮子里
资源组，说白了就是把一堆需要一起切换的资源打包。比如：VIP、磁盘挂载点、数据库服务、应用进程。这些资源要么都在主节点上运行，要么一起切到备节点。
为什么要这么设计？
- 原子性： 资源组内的所有资源，要么一起启动，要么一起停止。不会出现VIP过来了但数据库没起来的情况。
- 依赖关系： 比如必须先挂载磁盘，再启动数据库，最后启动应用。资源组可以定义启动顺序。
- 故障隔离： 一个资源组挂了，不影响其他资源组。
举个例子： 我维护过一个MySQL双机集群，资源组里包含：VIP（10.0.0.100）、数据盘（/dev/sdb1挂载到/data）、MySQL服务。切换时，备节点先挂载磁盘，再启动MySQL，最后绑定VIP。顺序错了，服务就起不来。
4. 故障切换（Failover）：自动接管
故障切换，就是主节点挂了，备节点自动接管所有资源的过程。整个过程应该是自动的、快速的、无人工干预的。
切换流程：
- 备节点连续丢失N次心跳，判定主节点故障。
- 备节点启动资源组内的所有资源。
- 备节点绑定VIP，发送免费ARP。
- 备节点对外提供服务。
我记得有一次，主节点内存故障导致内核panic，心跳彻底断了。备节点在3秒内检测到故障，5秒内完成了切换。业务中断时间不到10秒。这就是双机热备的价值。
避坑指南： 我曾经见过一个案例，主节点只是负载过高导致心跳延迟，但备节点误判为故障，强行切换。结果两台机器同时写同一份数据，数据全乱了。解决方案是：引入“慢启动”机制，连续超时次数设大一点，或者用加权心跳。
5. 回切（Fallback）：让一切回到原点
回切，也叫“切回”。当主节点修复后，要不要把服务切回来？这是个经典问题。
两种策略：
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 自动回切 | 主节点恢复后，自动把资源抢回来 | 主节点性能远高于备节点 |
| 手动回切 | 运维人员确认后，手动执行切换 | 业务敏感，怕自动切换造成抖动 |
我个人习惯用手动回切。为什么？因为自动回切可能引发二次故障。比如主节点只是网络闪断，恢复后数据可能还没完全同步。强行切回来，反而导致数据不一致。
注意： 回切前一定要做数据一致性检查。我曾经有一次没检查就直接回切，结果发现主节点比备节点少了1000条记录。那一次，我花了整整一个下午才把数据补回来。
6. 脑裂问题：集群的“精神分裂”
脑裂，是双机热备里最可怕的故障。简单说，就是两台机器都认为自己是主节点，同时对外提供服务。后果是什么？数据写冲突、服务混乱、甚至数据永久损坏。
脑裂的常见原因：
- 心跳链路完全中断（网线断了、交换机挂了）。
- 备节点误判主节点故障。
- 集群软件bug。
如何防止脑裂？
- 冗余心跳： 至少两条心跳链路，一条网线一条串口线。
- 仲裁机制： 引入第三方仲裁节点（比如投票机制、共享存储锁）。
- STONITH： 就是“Shoot The Other Node In The Head”。备节点在接管前，先通过远程管理卡（如IPMI、iLO）强制关闭主节点的电源。确保主节点真的死了，再接管。
真实案例： 我遇到过最严重的脑裂事故，是因为交换机一个端口坏了，导致心跳不通。两台机器同时抢VIP，结果VIP在两个节点之间来回漂移，业务彻底瘫痪。后来我加了串口心跳，并且配置了STONITH，再也没出过类似问题。
我的建议： 脑裂是设计问题，不是运维问题。在架构设计阶段，就要把防脑裂机制考虑进去。别等到出了事故再补救，那时候代价就大了。
好了，核心概念就讲到这里。这几个概念是双机热备的基石，搞懂了它们，后面的配置和调优才能得心应手。下一章，咱们聊聊常见的双机热备架构模式，以及如何根据业务场景选型。