Keepalived + VIP 高可用架构设计与实践详解：实现 Nginx 入口层的高可用

一、背景与目标

在大型网站或企业系统中，“高可用性（High Availability, HA）”是衡量系统稳定性的关键指标之一。任何一个节点故障都不应影响整体服务的可达性。

问题背景举例：

• Tomcat 部署了集群（后端高可用）
• Redis 配置了主从 + Sentinel（缓存高可用）
• 数据库使用了主备或分库分表（存储高可用）
• 但入口 Nginx 只有一个……

Nginx 宕机 = 全站瘫痪

为了解决这个“最顶层的单点问题”，我们引入：

Keepalived + VIP 架构：实现 Nginx 入口层的高可用

二、架构原理

2.1 什么是 Keepalived？

• Keepalived 是一个运行于 Linux 平台的高可用服务组件。
• 利用 VRRP 协议（虚拟路由冗余协议） 在主备节点间漂移 IP 地址（VIP）。
• 可结合健康检查脚本实现服务层探测。

2.2 什么是 VIP？

• VIP（Virtual IP）：不属于某台服务器的真实 IP。
• 它在主机之间漂移，由 Keepalived 管理。
• 客户端只访问 VIP，永远感知不到背后是哪一台服务器处理请求。

三、Keepalived + VIP 架构工作机制详解

3.1 主备模型说明

                 +------------------+
                 |     客户端       |
                 +------------------+
                          |
                          v
                    [ 虚拟IP: VIP ]
                          |
               -------------------------
              |                         |
        +-------------+         +-------------+
        | Master 节点 |         | Backup 节点 |
        |   持有 VIP  |         |   待命状态  |
        +-------------+         +-------------+
              |                          |
      心跳同步 | <------ VRRP --------> | 心跳同步
              |                          |

• Master 节点：拥有 VIP，对外提供服务。
• Backup 节点：等待状态，定期发送/接收 VRRP 心跳。
• VIP 自动漂移：Master 挂了 → Backup 无心跳 → 自动接管 VIP。

3.2 VIP 漂移原理（VRRP）

• 每个节点都有一个 优先级（priority）
• Keepalived 周期性发送 VRRP 心跳广告（advert_int 时间间隔）
• Backup 节点若超过一定时间未收到主节点的 VRRP 广播，就认为主已失效，触发 VIP 漂移。

四、实际部署步骤

4.1 安装 Keepalived（CentOS 为例）

yum install -y keepalived

4.2 配置文件路径

/etc/keepalived/keepalived.conf

4.3 主节点配置（示例）

vrrp_instance VI_1 {
    state MASTER
    interface ens33                # 网卡名（用 ifconfig 查看）
    virtual_router_id 51          # 同一个 VRRP 实例编号，主备必须一致
    priority 100                  # 优先级（Master 优先级 > Backup）
    advert_int 1                  # 心跳间隔（秒）

    authentication {
        auth_type PASS
        auth_pass 123456
    }

    virtual_ipaddress {
        192.168.1.100              # 虚拟 IP
    }
}

4.4 备节点配置（与主基本一致）

state BACKUP
priority 90

确保 virtual_router_id 和 auth_pass 完全一致！

五、Keepalived 健康检查机制

问题：Keepalived 是活的，但服务（如 Nginx）挂了怎么办？

解决方案：编写健康检查脚本

5.1 脚本内容 /etc/keepalived/check_nginx.sh

#!/bin/bash

# 方式一：判断端口（不依赖 curl）
if ! ss -lntp | grep ':80' > /dev/null; then
    pkill keepalived
fi

# 方式二：通过 curl 检查 HTTP 状态码
# curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1 | grep -q "200" || pkill keepalived

5.2 引入脚本配置

vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2         # 每 2 秒检测一次
    weight -20         # 若失败则降低优先级
}

vrrp_instance VI_1 {
    ...
    track_script {
        check_nginx
    }
}

六、互为主备 + 双 VIP 架构（资源最大化）

在默认主备模式下，Backup 节点处于“吃干饭”状态。为提高资源利用率，可采用：

6.1 双 VIP + 互为主备设计

6.2 DNS 轮询实现双活负载

将 www.example.com 同时解析到 VIP1 和 VIP2：

www.example.com → 192.168.1.100
www.example.com → 192.168.1.101

用户请求将随机访问其中一台，实现简单的DNS 负载均衡。

七、防止抢占与频繁漂移

7.1 抢占问题

默认情况下：

• Master 宕机 → Backup 接管 VIP
• Master 恢复后 → 会重新抢回 VIP

缺点： VIP 再次漂移，可能造成短暂闪断或状态错乱

7.2 解决方案：禁用抢占

nopreempt

加在 vrrp_instance 内，代表：

即使原 Master 恢复，也不再抢回 VIP，直到 Backup 也失效。

八、脑裂（Split Brain）问题详解

8.1 什么是脑裂？

两台主机同时认为对方已宕机，并同时接管 VIP，变成双主。

8.2 导致原因

• VRRP 心跳包丢失（网络中断、心跳端口异常）
• 配置错误（相同优先级、误抢占）
• 杀死 keepalived 进程未释放 VIP

8.3 后果

• 双节点抢占 VIP，客户端请求乱序
• 数据不一致、丢失、服务不稳定

8.4 防护策略

九、典型故障场景模拟

十、总结与最佳实践