nginx+keepalived构建web高可用集群的核心是消除单点故障：nginx负责七层负载均衡与反向代理，keepalived通过vrrp协议实现vip漂移与主备自动切换，后端需多台无状态web服务配合upstream健康检查，三者协同确保流量入口高可用与后端弹性分发。
用 Nginx 和 Keepalived 构建分布式 Web 集群，核心不是堆机器，而是消除单点故障、实现流量入口的自动接管和后端服务的弹性分发。它不等于“分布式系统”的全部（比如无状态服务编排、数据分片），但确实是面向真实业务场景中最常用、最可控、最易落地的高可用入口层方案。
明确角色分工：谁干啥，不能混
Nginx 不是万能胶，Keepalived 也不是万能钥匙。必须清楚每层职责：
- Nginx 负责七层（应用层）流量处理：解析 HTTP/HTTPS、做 URL 路由、动静分离、限流、反向代理到后端 Tomcat/Nginx/PHP-FPM 等；它本身是软件负载均衡器，但单实例就是瓶颈。
- Keepalived 不转发请求，只管“IP 归属”：通过 VRRP 协议在多台 Nginx 服务器间维护一个虚拟 IP（VIP），持续健康检查（如检测 Nginx 进程或端口是否存活），主节点失效时秒级把 VIP 绑定到备用节点。
- 后端 Web 服务器（如多台 Tomcat 或 Nginx 静态服务）是真正处理业务逻辑的单元，Nginx 把它们当作上游（upstream）来轮询、加权或按 IP 哈希分发请求。
关键配置不能跳步：VIP + 检测脚本 + 同步状态
光装上两个软件没用，三处配置缺一不可：
- 统一 VIP 设置：两台 Nginx 服务器共用同一个 VIP（例如 192.168.5.100），该 IP 不配置在任何物理网卡上，而是由 Keepalived 动态绑定。客户端只访问这个 VIP，完全感知不到后端切换。
-
自定义健康检查脚本：不能只依赖进程是否存在。推荐写 shell 脚本（如
/etc/keepalived/check_nginx.sh），用curl -I http://127.0.0.1:80检查 Nginx 是否返回 200，再配合interval 2秒频次执行。避免因 Nginx 进程活着但无法响应导致 VIP 漂移失败。 -
主备优先级与抢占控制：MASTER 节点 priority 设为 100，BACKUP 设为 90；同时开启
nopreempt（非抢占模式）可防止网络抖动引发频繁切换；若需恢复后自动抢回 VIP，则去掉该选项并确保 MASTER 优先级更高。
后端服务要真正“可负载”：别让集群卡在最后一环
Nginx 做得再稳，如果后端只有一台服务器，整个集群还是单点。必须同步做好后端伸缩：
- 至少部署两台及以上 Web 服务（如 Tomcat 或 Node.js 应用），监听不同端口或 IP，且应用本身无状态或共享外部 Session 存储（Redis）。
- Nginx upstream 中明确列出所有后端地址，并启用
health_check（需 stream 模块）或配合第三方模块（如 nginx_upstream_check_module）做主动探活，自动摘除异常节点。 - 注意转发头设置：在 proxy_pass 配置中加入
proxy_set_header Host $host;和proxy_set_header X-Real-IP $remote_addr;，确保后端能正确获取原始请求信息。
验证比部署更重要：切换必须可测、可观、可回溯
上线前务必模拟真实故障：
- 手动
systemctl stop keepalived在 MASTER 上触发切换，用ip addr show查看 VIP 是否已出现在 BACKUP 的网卡上；用tcpdump -i eth0 host 192.168.5.100确认流量是否已导向新节点。 - 用 curl 或浏览器持续访问 VIP，观察是否出现 502/超时（说明切换失败或后端未就绪），理想情况是最多丢 1–2 个请求，其余无缝承接。
- 记录 Keepalived 日志（默认 /var/log/messages），关注 “Transition to MASTER/BACKUP STATE”、“VRRP_Instance vi_1: Sending/Entering FAULT state” 等关键事件，便于事后分析。
