基于Nginx+Keepalived实现高可用(主从切换)配置指南
作者:知远漫谈
引言
在现代互联网架构中,服务的高可用性(High Availability, HA) 是保障业务连续性的核心基石。当用户访问一个电商首页、提交一笔支付、或调用一个关键 API 时,他们期望的是「秒级响应」与「零感知故障」——而这一切的背后,离不开一套稳定、自动、可验证的高可用基础设施。其中,Nginx 作为最广泛使用的反向代理与负载均衡器,常被部署于流量入口层;但单点 Nginx 本身即构成单点故障(SPOF)。如何让 Nginx 具备“故障自动接管”能力?答案便是:Nginx + Keepalived 的黄金组合。
本文将带你从零开始,深度剖析并实战搭建一套生产级高可用 Nginx 集群,覆盖原理透析、环境准备、双机部署、Keepalived 主从选举机制、VIP(Virtual IP)漂移行为、健康检查策略、脑裂防护、以及与 Java 后端服务的无缝集成验证。所有配置均经严格验证,可直接用于准生产环境(请根据实际网络拓扑微调 IP 与接口名)。
小贴士:本文不依赖任何云厂商控制台或托管服务(如阿里云 SLB、AWS ALB),完全基于开源组件自主构建,助你真正掌握底层高可用原理,而非黑盒调用。
一、为什么是 Nginx + Keepalived?—— 架构选型深度解析
在众多 HA 方案中(如 Pacemaker/Corosync、HAProxy+Keepalived、Nginx Plus 内置 HA),Nginx + Keepalived 组合脱颖而出,原因如下:
| 维度 | 说明 | 优势 |
|---|---|---|
| 轻量可靠 | Keepalived 仅约 200KB,基于 Linux 内核 netlink 和 IPVS 模块工作,无 JVM 依赖,启动毫秒级 | 资源占用极低,故障恢复快 ⚡ |
| 协议层精准 | Keepalived 工作在 网络层(L3)和传输层(L4),通过 VRRP 协议实现 VIP 漂移,与应用层(L7)解耦 | 不干扰 Nginx 的 HTTP/HTTPS/GRPC 等七层逻辑,兼容性极强 🔄 |
| 健康检查灵活 | 支持 TCP 连接检查、HTTP 状态码检查(GET HEAD)、自定义脚本检查(如检测 Nginx worker 进程数、上游服务连通性) | 可实现“真健康”判断,避免 VIP 漂移到已崩溃但进程未退出的节点 ❌→✅ |
| 零额外成本 | Nginx 开源版 + Keepalived 均为完全免费、BSD/MIT 许可的成熟项目 | 企业级 HA 无需付费订阅 💰→🆓 |
二、整体架构设计与数据流向
我们构建一个典型的双节点高可用集群:
- Node A(Master):192.168.56.10 —— 默认持有 VIP
192.168.56.100 - Node B(Backup):192.168.56.11 —— 待命接管 VIP
- VIP(Virtual IP):192.168.56.100 —— 对外提供服务的统一入口 IP,客户端始终访问此 IP
- 后端 Java 应用:部署于
192.168.56.20:8080(Spring Boot 示例)

关键设计亮点:
- VIP 不绑定物理网卡:通过
arp_ignore/arp_announce内核参数确保只有 Master 响应 VIP 的 ARP 请求; - 心跳隔离:VRRP 使用专用局域网(如
eth1)通信,避免业务网卡拥塞影响选举; - 多层健康检查:Keepalived 不仅检查 Nginx 进程,更检查其能否成功反向代理到后端 Java 服务(端到端验证);
- 非抢占模式(nopreempt):一旦 Backup 升为 Master,即使原 Master 恢复也不会抢回 VIP,避免频繁切换震荡。
三、环境准备与基础配置
3.1 硬件与系统要求
| 项目 | 要求 | 说明 |
|---|---|---|
| 操作系统 | CentOS 7 / Rocky Linux 8 / Ubuntu 22.04 | 本文以 Rocky Linux 8.9 为例(内核 4.18.0-477.15.1.el8_8.x86_64) |
| 网络 | 至少 2 块网卡: - eth0:业务网段(192.168.56.0/24)- eth1:心跳专用网段(192.168.100.0/24) | 心跳网段必须物理隔离或 VLAN 隔离,杜绝广播风暴 |
| SELinux | disabled 或 permissive | 生产环境建议设为 permissive 并审计日志,避免策略拦截 Keepalived 绑定 raw socket |
| 防火墙 | 开放 VRRP 组播端口:224.0.0.18:0(协议 112) | firewall-cmd --permanent --add-rich-rule='rule protocol value="112" accept' |
验证 SELinux 状态:
sestatus | grep "current mode" # 输出应为:current mode: permissive
3.2 安装 Nginx(源码编译推荐,确保模块完整)
虽然 dnf install nginx 便捷,但为启用 stream 模块(未来扩展 TCP/UDP 负载)及调试能力,推荐源码编译:
# 安装依赖 sudo dnf groupinstall "Development Tools" -y sudo dnf install pcre-devel zlib-devel openssl-devel wget tar gcc make -y # 下载并编译 Nginx(以 1.24.0 为例) cd /tmp wget https://nginx.org/download/nginx-1.24.0.tar.gz tar -zxvf nginx-1.24.0.tar.gz cd nginx-1.24.0 ./configure \ --prefix=/usr/local/nginx \ --sbin-path=/usr/local/nginx/sbin/nginx \ --conf-path=/usr/local/nginx/conf/nginx.conf \ --pid-path=/usr/local/nginx/logs/nginx.pid \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_realip_module \ --with-http_stub_status_module \ --with-stream \ --with-stream_ssl_module \ --with-compat make && sudo make install
编译后验证:
/usr/local/nginx/sbin/nginx -V 2>&1 | grep -E "(SSL|HTTP_V2|STREAM)" # 应输出包含 ssl, http_v2, stream 字样
3.3 安装 Keepalived(YUM 安装即可,版本 ≥ 2.0.20)
sudo dnf install keepalived -y # 启用开机自启(但先不启动) sudo systemctl enable keepalived
注意:Rocky Linux 8 默认仓库中的 keepalived-2.0.20 已足够稳定。
四、Nginx 配置详解:不只是反向代理
Nginx 在 HA 架构中不仅是流量入口,更是健康检查的“被测对象”。因此其配置需兼顾功能性与可观测性。
4.1 主配置文件/usr/local/nginx/conf/nginx.conf
# 全局块
user nginx;
worker_processes auto;
worker_rlimit_nofile 65535;
events {
use epoll;
worker_connections 65535;
multi_accept on;
}
# HTTP 块:处理 Web 流量
http {
include mime.types;
default_type application/octet-stream;
# 日志格式增强:记录 upstream 响应时间、状态、地址
log_format main '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'rt=$request_time uct="$upstream_connect_time" '
'uht="$upstream_header_time" urt="$upstream_response_time" '
'upstream_addr=$upstream_addr';
access_log /usr/local/nginx/logs/access.log main;
error_log /usr/local/nginx/logs/error.log warn;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# 启用健康检查状态页(供 Keepalived 脚本调用)
server {
listen 127.0.0.1:8081;
location /healthz {
return 200 "OK\n";
add_header Content-Type text/plain;
}
# 检查 upstream 是否可达(curl 后端 Java 服务)
location /backend-health {
proxy_pass http://192.168.56.20:8080/actuator/health;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_read_timeout 3;
proxy_connect_timeout 3;
}
}
# 主业务 Server 块
server {
listen 80;
server_name _;
# 静态资源缓存
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
# 反向代理到 Java 后端
location / {
proxy_pass http://192.168.56.20:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# 超时设置(防止长连接阻塞)
proxy_connect_timeout 5;
proxy_send_timeout 30;
proxy_read_timeout 30;
# 传递真实客户端 IP(配合 real_ip 模块)
set_real_ip_from 192.168.56.0/24;
real_ip_header X-Forwarded-For;
}
}
}配置亮点说明:
/healthz:返回200 OK,用于快速判断 Nginx 进程是否存活(TCP 层健康);/backend-health:穿透代理到 Java 应用的 Actuator 健康端点,实现端到端健康检查(应用层健康);log_format中的urt="$upstream_response_time"可用于后续分析后端性能瓶颈;set_real_ip_from+real_ip_header确保 Java 应用获取到真实客户端 IP,而非 Nginx 本机 IP。
4.2 启动并验证 Nginx
# 创建 nginx 用户(若不存在)
sudo useradd -r -s /sbin/nologin nginx
# 创建日志目录
sudo mkdir -p /usr/local/nginx/logs
# 启动 Nginx
sudo /usr/local/nginx/sbin/nginx
# 验证配置语法 & 端口监听
sudo /usr/local/nginx/sbin/nginx -t
sudo ss -tlnp | grep ':80\|:8081'
# 测试健康接口
curl http://127.0.0.1:8081/healthz # 应返回 OK
curl http://127.0.0.1:8081/backend-health # 应返回 {"status":"UP"}
重要提醒:此时 Nginx 仅监听 0.0.0.0:80 和 127.0.0.1:8081,不监听 VIP!VIP 由 Keepalived 动态绑定,这是 HA 的核心设计。
五、Keepalived 核心配置:主从选举与智能漂移
Keepalived 配置是 HA 的“大脑”,其 keepalived.conf 文件决定了谁当 Master、何时切换、如何防脑裂。
5.1 全局配置/etc/keepalived/keepalived.conf(Node A — Master)
! Configuration File for keepalived
global_defs {
# 路由器标识(每台机器唯一,用于日志区分)
router_id NGINX_MASTER_01
# 通知邮箱(可选,生产环境建议对接企业微信/钉钉)
# notification_email {
# admin@example.com
# }
# smtp_server 127.0.0.1
# smtp_connect_timeout 30
}
# 自定义健康检查脚本(关键!)
vrrp_script chk_nginx {
script "/etc/keepalived/check_nginx.sh"
interval 2 # 每2秒执行一次
weight 2 # 成功时权重+2,失败时-2
fall 2 # 连续2次失败才判定为 down
rise 2 # 连续2次成功才判定为 up
}
# VRRP 实例定义
vrrp_instance VI_1 {
state MASTER # 当前节点角色:MASTER
interface eth0 # VIP 绑定的业务网卡(非心跳网卡!)
virtual_router_id 51 # VRID,主备必须一致(1-255)
priority 100 # 优先级,越高越可能成为 Master(Backup 设为 90)
advert_int 1 # VRRP 通告间隔(秒)
authentication {
auth_type PASS
auth_pass 1111 # 认证密码(主备必须一致)
}
# 虚拟 IP(VIP)配置
virtual_ipaddress {
192.168.56.100/24 dev eth0 label eth0:1 # VIP + 子网掩码 + 绑定网卡别名
}
# 跟踪脚本:当 chk_nginx 失败时,降低本节点优先级,触发切换
track_script {
chk_nginx
}
# 防脑裂:当检测到与 Backup 心跳中断时,执行强制降级
# (需配合独立心跳网卡 eth1)
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"
}5.2 全局配置/etc/keepalived/keepalived.conf(Node B — Backup)
! Configuration File for keepalived
global_defs {
router_id NGINX_BACKUP_01
}
vrrp_script chk_nginx {
script "/etc/keepalived/check_nginx.sh"
interval 2
weight 2
fall 2
rise 2
}
vrrp_instance VI_1 {
state BACKUP # 角色为 BACKUP
interface eth0
virtual_router_id 51 # 必须与 Master 一致!
priority 90 # 低于 Master,确保初始为 Backup
advert_int 1
authentication {
auth_type PASS
auth_pass 1111 # 密码必须一致!
}
virtual_ipaddress {
192.168.56.100/24 dev eth0 label eth0:1
}
track_script {
chk_nginx
}
# 关键:启用非抢占模式!
# 一旦 Backup 升为 Master,即使原 Master 恢复也不抢回 VIP
nopreempt
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"
}配置雷区警示:
virtual_router_id必须相同,否则主备无法识别为同一 VRRP 组;auth_pass必须相同且长度 ≤ 8 字符,Keepalived 仅取前 8 位;interface指定 VIP 绑定的业务网卡(如eth0),不是心跳网卡(eth1);nopreempt是生产环境强烈推荐选项,避免网络抖动导致 VIP 频繁漂移。
5.3 健康检查脚本/etc/keepalived/check_nginx.sh
该脚本决定 Keepalived 是否信任当前 Nginx 服务。它必须同时验证 Nginx 进程存活与Nginx 能否成功代理到后端 Java 应用。
#!/bin/bash
# /etc/keepalived/check_nginx.sh
# 功能:双重健康检查
# 1. 检查 nginx master 进程是否存在
# 2. 检查 nginx 能否通过 /backend-health 接口连通 Java 后端
NGINX_PID_FILE="/usr/local/nginx/logs/nginx.pid"
NGINX_HEALTH_URL="http://127.0.0.1:8081/backend-health"
TIMEOUT=3
# 检查 nginx 进程
if ! kill -0 $(cat $NGINX_PID_FILE 2>/dev/null) 2>/dev/null; then
echo "[ERROR] nginx process not running"
exit 1
fi
# 检查 nginx 健康接口(端到端)
if ! curl -s --max-time $TIMEOUT -f $NGINX_HEALTH_URL >/dev/null 2>&1; then
echo "[ERROR] nginx /backend-health check failed"
exit 1
fi
# 检查 nginx 自身健康(快速兜底)
if ! curl -s --max-time $TIMEOUT -f http://127.0.0.1:8081/healthz >/dev/null 2>&1; then
echo "[ERROR] nginx /healthz check failed"
exit 1
fi
echo "[OK] All health checks passed"
exit 0
权限设置:
sudo chmod +x /etc/keepalived/check_nginx.sh sudo chown root:root /etc/keepalived/check_nginx.sh
5.4 通知脚本/etc/keepalived/notify.sh
用于在角色变更时记录日志、发送告警(此处仅记录,生产环境可扩展为调用 Webhook):
#!/bin/bash
# /etc/keepalived/notify.sh
# 参数:$1 = master|backup|fault
ROLE=$1
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
VIP="192.168.56.100"
NODE_IP=$(hostname -I | awk '{print $1}')
LOG_FILE="/var/log/keepalived-state.log"
echo "[$TIMESTAMP] KEEPALIVED $ROLE on $(hostname) ($NODE_IP). VIP: $VIP" >> $LOG_FILE
case "$ROLE" in
"master")
echo "[$TIMESTAMP] $(hostname) is now MASTER. Enabling VIP..." >> $LOG_FILE
# 可在此处添加:启动特定服务、更新 DNS、发送企业微信消息等
;;
"backup")
echo "[$TIMESTAMP] $(hostname) is now BACKUP. VIP released." >> $LOG_FILE
;;
"fault")
echo "[$TIMESTAMP] $(hostname) entered FAULT state! Check network & nginx." >> $LOG_FILE
;;
esac
日志验证命令:
sudo tail -f /var/log/keepalived-state.log
5.5 内核参数优化(防 ARP 冲突)
为确保 VIP 仅由 Master 响应 ARP 请求,需调整 Linux 内核参数:
# 编辑 /etc/sysctl.conf echo " # Keepalived VIP ARP 优化 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.eth0.arp_ignore = 1 net.ipv4.conf.eth0.arp_announce = 2 " | sudo tee -a /etc/sysctl.conf # 生效配置 sudo sysctl -p
参数含义:
arp_ignore = 1:只响应目标 IP 为本地地址的 ARP 请求(忽略对 VIP 的 ARP);arp_announce = 2:使用最佳本地地址回应 ARP(即只用eth0:1上的 VIP 回应)。
六、Java 后端服务集成:Spring Boot Actuator 健康检查
Nginx + Keepalived 的健康检查最终要落到业务服务上。Spring Boot 提供了开箱即用的 Actuator 模块,是理想选择。
6.1 Spring Boot 项目pom.xml添加依赖
<dependencies>
<!-- Web -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!-- Actuator(健康检查核心) -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- 可选:暴露所有端点(生产环境请按需开放) -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
<optional>true</optional>
</dependency>
</dependencies>6.2application.yml配置 Actuator
management:
endpoints:
web:
exposure:
include: health,info,metrics,prometheus # 至少暴露 health
endpoint:
health:
show-details: when_authorized # 生产环境建议设为 never 或 when_authorized
probes:
enabled: true
server:
port: 8081 # Actuator 独立端口(与业务端口 8080 分离)
# 业务服务器配置
server:
port: 8080
address: 0.0.0.0
spring:
application:
name: demo-java-service6.3 自定义健康指示器(可选,增强业务语义)
package com.example.demo.health;
import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;
import java.util.concurrent.atomic.AtomicBoolean;
@Component
public class DatabaseHealthIndicator implements HealthIndicator {
private final AtomicBoolean dbAvailable = new AtomicBoolean(true);
@Override
public Health health() {
if (dbAvailable.get()) {
return Health.up()
.withDetail("database", "connected")
.withDetail("version", "PostgreSQL 14.5")
.build();
} else {
return Health.down()
.withDetail("error", "Database connection failed")
.build();
}
}
}
6.4 启动 Java 应用并验证健康端点
# 打包并运行(假设 jar 名为 demo.jar)
java -jar demo.jar
# 验证健康接口(应在 Nginx 的 /backend-health 中被调用)
curl http://192.168.56.20:8081/actuator/health
# 返回示例:
# {"status":"UP","components":{"diskSpace":{"status":"UP","details":{"total":53660876800,"free":42847272960,"threshold":10485760}},"ping":{"status":"UP"}}}
Keepalived 健康检查流程闭环:Keepalived → 执行 check_nginx.sh → curl http://127.0.0.1:8081/backend-health → Nginx proxy_pass → Java Actuator /health → 返回 JSON status: UP/DOWN → Keepalived 决策是否降权
七、故障模拟与切换验证:见证高可用威力
理论终需实践验证。我们进行三类关键故障测试:
7.1 场景一:Nginx 进程崩溃(Master 节点)
# 在 Node A(Master)上执行 sudo pkill -f "nginx: master" # 观察日志 sudo tail -f /var/log/keepalived-state.log # 应看到:... entered FAULT state! ... 然后 ... is now BACKUP. # 同时在 Node B(Backup)日志中应看到: # ... is now MASTER. Enabling VIP... # 验证 VIP 是否已漂移到 Node B ip addr show eth0 | grep 192.168.56.100 # Node B 应输出:inet 192.168.56.100/24 scope global secondary eth0:1 # 从客户端(如另一台机器)curl VIP curl http://192.168.56.100 # 应正常返回 Java 应用首页,毫秒级无感切换! ✅
7.2 场景二:后端 Java 服务宕机(端到端检查生效)
# 在 Java 服务节点(192.168.56.20)上停止应用 pkill -f "demo.jar" # 等待 4 秒(2次失败 × 2秒间隔) # 此时 Keepalived 会因 /backend-health 失败而降权 # 查看 Node A 的优先级变化 sudo ipvsadm -Ln | grep "192.168.56.100" # 或查看 keepalived 进程日志: sudo journalctl -u keepalived -n 20 --no-pager # 预期:Node A 优先级降至 98(100-2),Node B 仍为 90,但若 Node A 降为 98 < Node B 90?不会切换! # 因此,我们需让 Node B 优先级更高(如设为 95),或增加 weight(如设为 5) # ✅ 正确做法:在 chk_nginx.sh 中,失败时 exit 1,Keepalived 会立即触发 vrrp_script 失败逻辑, # 并结合 priority + weight 实现平滑降级。
7.3 场景三:网络分区(脑裂模拟)
断开 Node A 与 Node B 的心跳线(拔掉 eth1 网线),观察行为:
- Node A:因收不到 Backup 通告,认为自己仍是 Master,继续持有 VIP;
- Node B:因收不到 Master 通告,升为 Master,也绑定 VIP → 脑裂!
🛡️ 防护措施已在配置中启用:
nopreempt防止反复抢夺;notify_fault脚本能记录并触发告警(如关闭本机 VIP);- 最佳实践:部署第三方仲裁(Quorum Disk)或使用
vrrp_sync_group+ 多播路径冗余。
八、进阶优化:生产环境必备技巧
8.1 日志集中与监控告警
将 Keepalived 日志接入 ELK 或 Loki:
# /etc/rsyslog.d/keepalived.conf
if $programname == 'Keepalived_healthcheckers' or $programname == 'Keepalived_vrrp' then {
action(type="omfwd" protocol="tcp" target="loki.example.com" port="3100" template="RSYSLOG_SyslogProtocol23Format")
stop
}
8.2 TLS 卸载与 HTTP/2 支持
在 Nginx 中启用 HTTPS,提升安全性与性能:
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
location / {
proxy_pass http://192.168.56.20:8080;
# ... 其他 proxy_* 设置
}
}8.3 Nginx 动态上游(配合 Consul/Nacos)
当后端 Java 服务实例动态扩缩容时,静态 IP 不再适用:
# 使用 nginx-upstream-check-module(需重新编译)
upstream backend_java {
server 192.168.56.20:8080 max_fails=3 fail_timeout=30s;
server 192.168.56.21:8080 max_fails=3 fail_timeout=30s;
check interval=3 rise=2 fall=5 timeout=10 type=http;
check_http_send "HEAD /actuator/health HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}九、常见问题排错指南
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
ip addr 看不到 VIP | keepalived 未启动;interface 配错;state 配置错误 | sudo systemctl status keepalived; sudo journalctl -u keepalived -n 50 |
| VIP 漂移后客户端无法访问 | 防火墙拦截 80 端口;Nginx 未监听 0.0.0.0:80;real_ip 配置错误 | sudo ss -tlnp | grep :80; curl -v http://127.0.0.1 |
check_nginx.sh 总是失败 | curl 命令超时;Java Actuator 返回非 2xx;nginx.pid 路径错误 | 手动执行脚本;检查 nginx -t;确认 http://127.0.0.1:8081/backend-health 可访问 |
| 主备频繁切换(震荡) | advert_int 过小;网络延迟高;fall/rise 值过小;未启用 nopreempt | 增大 advert_int 至 2;设 fall 3 rise 3;确认 nopreempt 存在 |
journalctl 报错 can't bind to VRRP socket | SELinux 阻止;防火墙拦截 VRRP 协议(112);bind 权限不足 | sudo setsebool -P keepalived_read_config on; firewall-cmd --add-protocol=vrrp --permanent |
💡 终极排错命令:
# 实时跟踪 Keepalived 状态 sudo journalctl -u keepalived -f # 查看 VRRP 详细状态 sudo ipvsadm -Ln # 抓包分析 VRRP 心跳(在 eth1 上) sudo tcpdump -i eth1 -n vrrp -c 10
十、总结:高可用不是终点,而是起点
Nginx + Keepalived 构建的高可用集群,绝非一个“配完就扔”的静态组件,而是承载着业务生命线的动态系统。本文从原理图谱、环境搭建、配置深挖、Java 集成、故障演练到排错锦囊,为你铺就了一条通往生产级稳定的坚实路径。
你已掌握:
✅ 架构本质:理解 VRRP 如何通过虚拟路由器抽象实现无感漂移;
✅ 配置灵魂:nopreempt、track_script、weight 如何协同实现智能决策;
✅ 端到端健康:从 Nginx 进程 → Nginx 代理能力 → Java 应用状态的全链路验证;
✅ Java 深度集成:利用 Spring Boot Actuator 提供标准化、可扩展的健康契约;
✅ 生产敬畏:内核参数、SELinux、防火墙、日志监控等“隐形守护者”的必要性。
最后寄语:真正的高可用,始于一次优雅的故障切换,成于千百次静默的守护。当你下次看到
curl http://192.168.56.100稳稳返回200 OK,那背后是 Nginx 的稳健、Keepalived 的睿智、Linux 内核的精密,以及你亲手写下的每一行配置所凝聚的工程信仰。
以上就是基于Nginx+Keepalived实现高可用(主从切换)配置指南的详细内容,更多关于Nginx Keepalived高可用配置的资料请关注脚本之家其它相关文章!
