获课：xingkeit.top/16296/

Keepalived 高可用集群：解决 Web 层单点故障，其实比你想的简单

我见过太多创业公司的技术架构是这样起步的：一台服务器，跑着 Nginx、应用服务、数据库，所有东西挤在一起。访问量小的时候相安无事，一旦流量上来或者服务器出了点毛病，整个服务就挂了。最要命的是半夜服务器宕机，运维被电话叫醒，吭哧吭哧连上去重启，等恢复的时候用户已经跑了一半。

所有单点故障的根源都是同一个问题：你没有备胎。 硬件会坏、网络会抖、系统会崩，这是迟早的事，跟你的代码写得多好没有半点关系。解决单点故障的思路其实特别朴素——多准备一台机器，一台倒下了另一台顶上。Keepalived 做的事情，就是用极低的成本把“主备切换”这件事自动化。

Keepalived 到底在解决什么问题？

很多人一听到“高可用集群”就觉得是个重型方案，得要专门的运维团队才能搞定。但 Keepalived 的真实面目其实是一个轻量到有些朴素的小工具——它的核心工作就是通过 VRRP 协议在多个服务器之间抢一个虚拟 IP。

你不需要理解 VRRP 是什么缩写，你只需要理解这个场景：你有两台服务器，一台是主（MASTER），一台是备（BACKUP）。两台服务器共用同一个虚拟 IP 地址，这个 IP 飘在哪里，哪台服务器就对外提供服务。正常情况下，虚拟 IP 在主服务器上，所有流量都打到主服务器。主服务器挂了之后，备服务器检测到心跳超时，自动把虚拟 IP 抢过来，接管所有流量。

就这么简单。用户访问的始终是同一个 IP 地址，他根本不知道背后是哪台服务器在响应。 切换过程对用户完全透明，无非是某个请求慢了一两秒，然后就自动恢复了。

为什么 Keepalived 比云厂商的负载均衡更“轻”

现在云服务商都提供了托管的负载均衡服务，功能强大、界面友好。那我为什么还推荐 Keepalived？原因很简单：有些场景你根本不需要一个独立的负载均衡器。

如果你的场景是“两台 Nginx 做 Web 层的高可用”，那 Keepalived 比云上的负载均衡服务至少省两个东西：一是省钱，云上的负载均衡器是按流量和实例数收费的，长期跑下来成本可观；二是省延迟，Keepalived 的 VRRP 心跳检测到切换的时间通常在 3 秒以内，而且没有额外的网络跳转，请求延迟比多经过一层负载均衡器要低。

更关键的是，Keepalived 不依赖云厂商的特定能力。你可以在自有机房用、在混合云用、在云和云之间用——只要你有多台机器和一个可用的 IP 段，Keepalived 就能干活。这种“不绑定”的自由度，在架构设计里是稀缺价值。

实践中的关键问题：别把“脑裂”当传说

Keepalived 虽然简单，但有一个场景我亲眼见过好几次翻车——脑裂（Split-Brain）。简单来说，就是主备之间的心跳断了，备服务器以为主挂了，于是自己也把虚拟 IP 抢了过来。结果两台服务器同时响应同一个虚拟 IP，用户请求一会儿打到主、一会儿打到备，数据状态不一致，比服务完全挂掉还难处理。

脑裂的根源是单条心跳链路。解决思路也很朴素：不让心跳只走一条路。常见的做法是用两条独立的网卡做心跳，或者在同一网卡上配置两个不同网段的心跳通信。Keepalived 本身支持配置多播心跳，你只要在配置里多加几个 unicast_peer，让备服务器同时向多个 IP 地址发送心跳检测，能大幅降低误判概率。

还有一个更加底层的问题是抢占模式的设计。默认情况下 Keepalived 是抢占式的——主挂了备接管，主恢复了备自动让位。这在有些场景下是隐患：主恢复之后立即切回来可能导致正在处理的请求中断，频繁切换反而降低了可用性。如果你的业务对“平稳”的追求高于对“主始终为主”的追求，可以把模式改成非抢占式（nopreempt），让主恢复之后不再自动抢回 VIP，直到当前的节点真正挂了再切换。

Keepalived 的定位：不是万能，但足够解决 80% 的问题

说到底，Keepalived 解决的是一个非常聚焦的问题：如何让两台机器共用同一个 IP，并自动完成故障切换。 它不负责流量分发，不负责健康检查（虽然它也带了一个简单的检测机制），不负责自动伸缩。它就是做好一件事——抢 IP、保 IP、换 IP。

但这个“一件小事”恰恰是 Web 层高可用的基石。有了 Keepalived，你的 Nginx 层从“挂了就凉了”变成了“挂了能自动恢复”。虽然它不能保证零宕机，但至少能把故障恢复时间从“半夜被叫醒人工重启”变成“心跳超时自动切换”，这个差异对业务的体验来说是量级的。

高可用从来不是一蹴而就的，是从最薄弱的环节一个个补起来的。 Web 层是最前端的入口，入口都站不稳，后面再坚固也没用。Keepalived 就是那个让你花最少力气把入口站住的小工具。它不够花哨，但足够管用。