如何解决和预防 Nginx+Keepalived 中会出现的脑裂现象？

Nginx+Keepalived 的脑裂问题如何处理/预防？

①先复习一下 Keepalived

• Keepalived 是一款强大的辅助工具，主要提供故障切换和健康检查功能，实现高可用的性能需求
• 原理是采用 VRRP（虚拟路由冗余协议）热备份协议，以软件的形式来实现 Linux 服务器的多机热备功能，最初是针对 LVS 设计的
• VRRP 是针对路由器的一种备份解决方案，由多台路由器组成一个热备组，通过共同的虚拟 IP 对外提供服务，每个热备组内在同一时刻，只有一台 Master 提供服务，其他的路由器（Backup）处于冗余状态，唯一需要做的就是监听 Master 是否出现故障，取而代之（优先级决定接替的顺序），继承虚拟 IP 地址，又称之为漂移
• Keepalived 是一种基于 VRRP 协议的热备方式，能很好的完成服务器之间的故障切换，解决了单点故障的问题，每台热备组可以有多台服务器，最常用的还是双机热备（根据虚拟 IP 的漂移来实现），可适用于各种应用服务

---

②脑裂现象是什么意思？

脑裂现象出现于高可用架构之中

• 通过前面的小复习，大家都知道了，在一个高可用的集群内，Keepalived 内的节点通过监听对方的存活状态，若有 Master 宕机，则等待已久的备胎就会上位
• 但是如果出现了网络故障问题，比如你网线被我拔了，给你戒网瘾，这时，节点之间就会突然都监听不到 Master 的存活状态，且互相也失去联系，这会导致什么结果？
• 当然了，我们最亲爱的防火墙也有可能导致这种情况的出现~
• 这样，在高可用的机制下，节点就会争相顶替对方，即，导致原来被一个节点访问的资源会被多个节点同时访问，这个过程持续下去，又没有别的机制来协调与控制，就会有很大几率导致当前存在的数据出现不完整性（这里我还突然想到了 mysql 的事务特性）
• 且，对外提供的服务也必然会出现异常！

---

③如何预防这种现象？

• 既然在这个高可用集群之中有一定几率会出现脑裂现象，那么，最直接能想到的就是通过第三方手段来预防这种现象
• 比如，在两个节点之间出现分歧，开始互相争抢要上位的时候，这时若有一个第三方仲裁性质的机制，就能够决定到底最终听谁的
• 这个第三者，其实很简单，就是我们万能的 Shell 脚本，下面简单提供一下撰写思路

1.在负载均衡节点中写一个 while 循环脚本，每轮循环 ping 网关，累积连续失败的次数，当失败次数达到一定次数则运行 systemctl stop keepalived 关闭服务
2.如果发现又能够 ping 通了，再来重启服务
3.不忘在脚本的开头加上脚本是否已经运行的逻辑判断
4.最终将其加入到 crontab 周期计划性任务里面定时执行!

盖亚！！！！