在负载均衡体系中，active 一词通常出现在节点角色、集群工作模式和健康检查结果三个层面。节点被标记为 active，意味着负载均衡器认为该后端实例当前可用，可以接收并处理转发过来的请求。一个节点从 active 变为 standby 或 down，不是单纯的状态文字变化，而会直接影响流量分发、故障恢复和用户体验。理解这个状态需要把它放到具体产品与架构中去看，因为不同语境下 active 的含义存在细微差别，例如 Nginx 的 backup 节点、HAProxy 的 UP/DOWN 状态、Keepalived 的 MASTER/BACKUP 状态，都和 active 概念密切相关。
负载均衡里的 active 具体指什么
在负载均衡器的后端列表中，active 通常对应一个通过健康检查、正在接收流量的节点。与之相对的状态常见有 standby、passive、inactive、down。不同的产品和模块叫法不同，但判断标准基本一致：节点必须通过健康检查，并且没有被管理员手动禁用或标记为备用。例如 HAProxy 默认将健康检查成功的服务器显示为 UP，某些面板会将其翻译为 active；Nginx 没有单独的 active 字段，但 upstream 中的普通 server 如果未超出 max_fails 阈值，就会持续参与转发。
需要注意的是，active 还会出现在 active health check 这个术语中。这里的 active 指的是负载均衡器主动向后端发起探测请求，例如 TCP 连接、HTTP GET、gRPC health check。它和节点是否 active 是两个维度：主动探测是手段，节点 active 是结果。被动健康检查则是根据真实请求的失败率、超时率来推断节点是否仍然健康。把这两个 active 分开理解，排查问题时就不容易把配置错误和节点故障混在一起。
在集群工作模式层面，active 还经常出现在 active-active 和 active-passive 两种架构名称中。前者表示多节点同时活跃，后者表示只有主节点活跃、备节点等待接管。这里的 active 不再是单个节点的状态，而是整个集群的流量策略。例如两个数据中心同时对外提供服务属于 active-active，而主数据中心故障后备用数据中心才接管属于 active-passive。
active-active 与 active-passive 的区别和选型
active-active 模式下，所有节点都在接收请求，负载均衡器按轮询、最少连接、哈希等策略分发流量。这种模式最大的优点是资源利用率高，不存在闲置设备；当某个节点故障时，其他节点可以继续承接流量，整体吞吐能力不会下降太多。但它对应用层要求也更高，多个节点同时处理写请求时，必须解决数据一致性、缓存一致性、分布式锁等问题。例如用户会话如果只保存在单台服务器本地，切换到另一台后登录状态就会丢失。
active-passive 模式则把节点分为主备，主节点标记为 active，备节点保持 standby。只有主节点故障或人工切换时，备节点才会接管流量。优点很明显：架构简单，状态一致性问题较少，适合数据库、消息队列、状态型服务等对一致性要求高的场景。缺点是一台机器长时间不承载流量，资源浪费明显；同时切换过程通常存在几秒到几十秒的中断，如果健康检查参数设置得过于迟钝，故障恢复时间会更长。
下表从几个关键维度对两种模式做了对比。
| 对比维度 | active-active | active-passive |
|---|---|---|
| 资源利用率 | 高，多节点同时工作 | 较低，备机常处于闲置 |
| 故障切换 | 节点故障后流量自动分流 | 需要检测并触发切换，存在中断 |
| 数据一致性 | 复杂度高，需同步状态 | 较容易控制 |
| 适用场景 | 无状态服务、读多写少、多活数据中心 | 数据库主备、状态型服务、强一致事务 |
在 Nginx 中并没有严格意义上的 active-active 或 active-passive 开关，但可以通过 upstream 的 server 参数模拟主备。普通 server 相当于活跃节点，backup 节点只有在所有非 backup 节点不可用后才会接收请求。下面是一个简单示例：
upstream app_backend {
server 10.0.0.11:80 max_fails=3 fail_timeout=30s;
server 10.0.0.12:80 max_fails=3 fail_timeout=30s;
server 10.0.0.13:80 backup;
}
这个配置表示 10.0.0.11 和 10.0.0.12 默认为活跃节点，10.0.0.13 作为备用。只有前两台都连续失败达到 max_fails 阈值后，backup 节点才会被启用。它更接近 active-passive 的思想，但不能实现秒级主备切换，因为 Nginx 的 fail_timeout 和探测是惰性的。
健康检查如何决定 active 状态
一个节点能否被标记为 active，核心取决于健康检查结果。主动健康检查是负载均衡器周期性向后端发起探测，只有连续成功达到 rise 次，节点才会从 down 恢复为 active；连续失败达到 fall 次，节点会被摘除。HAProxy 的参数非常直观：
backend web_backend
balance roundrobin
server web1 10.0.0.11:80 check inter 3s fall 3 rise 2
server web2 10.0.0.12:80 check inter 3s fall 3 rise 2
server web3 10.0.0.13:80 check inter 3s fall 3 rise 2 backup
这里的 inter 3s 表示每 3 秒探测一次，fall 3 表示连续失败 3 次后摘除，rise 2 表示连续成功 2 次后重新加入。backup 节点同样有自己的健康检查，只有它通过检查并且在活跃节点全部不可用时才会变成承载流量的 active。
Nginx 社区版默认不做主动健康检查，而是采用被动方式：当请求转发到某台服务器出现超时、连接拒绝等错误时，会计入失败次数；超过 max_fails 后在 fail_timeout 时间内停止调度。这种机制依赖真实流量，如果流量很低，节点故障可能很久才被发现。对于敏感业务，可以结合第三方模块或商业版进行主动探测，也可以在应用内暴露健康检查接口，让外部系统及时摘除异常节点。
还要区分健康检查的 active 和节点角色 active 的另一个地方：一个节点显示 active，只代表它当前通过了健康检查并且被调度策略选中，并不代表它一定能正确处理业务逻辑。比如后端返回 200，但代码内部依赖的数据库已经不可用，负载均衡器仍会认为节点 active。因此，健康检查的路径最好是业务级探针，例如 /health 接口检查数据库连接、缓存状态、关键依赖是否正常，而不是只返回一个空页面。
热门问题汇总与注意事项
问题一：为什么配置了两个节点，其中一个一直不接收流量？这种情况通常要看节点是否被标记为 backup、down，或者健康检查没有通过。Nginx 中 backup 节点只有在普通节点全部失败后才会启用；HAProxy 中如果节点未通过 check，状态会显示 DOWN。还要检查负载均衡算法和会话保持策略，例如使用了 ip_hash 后，同一客户端会被持续固定到同一节点，另一个节点看起来就像没流量。
问题二：active-active 模式下会出现数据不一致吗？会，而且很常见。两个节点同时处理写请求时，如果底层没有共享存储或分布式一致性机制，各自本地状态会逐渐分叉。解决思路包括：把写操作路由到固定节点，用消息队列做异步同步，使用 Redis、数据库等集中式存储保存可变状态，或者限制某些接口只允许在主节点执行。
问题三：切换时为什么会丢请求？主备切换过程中，已经进入旧主节点但尚未完成的请求可能被中断。如果负载均衡器在旧主节点完全断开前就把新请求转发走，也可能出现连接重置。缓解方法包括合理设置重试策略、让应用接口幂等、使用长连接快速感知断开、在客户端做有限次重试。对于非常敏感的场景，可以在应用层设计补偿机制，而不是完全依赖负载均衡层的秒级完美切换。
问题四：如何避免 active-active 集群脑裂？脑裂通常指两个节点都认为自己是 active，同时对外提供服务或写共享存储。避免脑裂的关键是引入仲裁机制，例如使用 ZooKeeper、etcd 的 leader election，数据库使用多数派写确认，存储层使用 fencing 或隔离机制。单纯依赖心跳线很容易在网络分区时出现双主，因此不能把心跳当成唯一判断依据。
注意事项方面，首先要给健康检查设置合理的 rise 和 fall 阈值，避免一次网络抖动就频繁切换 active 节点。其次要区分无状态服务和有状态服务，无状态服务适合 active-active，有状态服务建议使用主备或集中式状态。第三，节点状态变化要接入监控，如果 active 节点数量突然从 2 变成 0，说明后端可能已经全部不可用。最后，切换后要检查连接池和会话信息是否还能复用，必要时让客户端重新建立连接。
选型建议与日常排查思路
在具体选型时，可以先看服务是否无状态。静态资源、API 网关、无本地会话的 Web 服务通常可以直接采用 active-active，通过横向扩容提升吞吐。数据库、消息队列、带本地缓存的报表服务则更适合 active-passive，或者采用中间件自带的主从复制和故障切换能力。混合场景很常见，例如前端 Web 层 active-active，数据库层 active-passive，这样既能发挥 Web 层多活优势，又能保证数据一致性。
排查 active 状态异常时，建议从三个层面入手。先看负载均衡器的状态页或管理接口，确认节点当前是 active、standby 还是 down；再看健康检查日志，判断是主动探测失败还是被动失败次数超限；最后直接请求后端节点的健康检查地址，从业务视角确认服务是否真的可用。不要只盯着负载均衡器显示 active 就认为后端一定正常，因为状态更新有延迟，健康检查也可能误判。
对于已经出现问题的集群，可以先整理最近一次配置变更、网络抖动和后端发布记录。很多 active 状态异常并不是负载均衡器自身问题，而是后端发布时未先摘除节点、数据库连接池耗尽、或者防火墙规则变更导致健康检查被拦截。把这些外部因素排除后，再调整 rise、fall、timeout 等参数，通常能避免无意义的参数试探。
