Java客户端跨多AZ请求NLB未负载均衡的原因及优化方案

预期Java客户端的请求能在两个节点间实现负载均衡，但实际所有请求仅流向一个节点，且两个节点均处于可用状态。需排查该现象原因，并找到实现负载均衡的最优策略。

环境信息 #

NLB部署在两个可用区（AZ）中，每个AZ对应一个端点，且每个AZ内有一台监听HTTPS的EC2实例。Java应用向该NLB发送HTTP请求。

已排查的可能原因 #

• NLB默认仅将请求转发至同AZ内的节点，可开启cross-zone load balancing修改此行为，但担心启用后产生不良副作用。
• 请求使用HTTPS且开启Keep-Alive，连接复用会导致请求固定流向单一节点。
• NLB通过DNS轮询实现负载均衡，但Java默认缓存DNS查询结果，虽可通过JVM参数networkaddress.cache.ttl=0禁用缓存，但担心引发DNS泛洪问题。

已尝试的方案 #

已启用cross-zone load balancing并添加Connection:close请求头，初步测试效果良好，但不确定在高请求量或高负载场景下是否适用。

1. 跨区负载均衡（Cross-Zone Load Balancing）的合理启用 #

NLB默认的同AZ转发逻辑是为了降低跨AZ数据传输成本，但如果业务需要两个AZ节点承担均衡流量，开启cross-zone load balancing是合理选择：

• 副作用说明：唯一明显的副作用是跨AZ数据传输费用增加，但这是实现跨AZ流量均衡的必要成本。AWS官方明确推荐在需要跨AZ负载均衡时启用该选项，开启后NLB会将请求均匀分发到所有注册的可用节点，不会带来额外性能损耗。

2. 替代Connection:close的连接复用优化 #

添加Connection:close强制每次请求新建连接，虽能临时解决单一节点流量集中问题，但高负载场景下会产生大量TCP连接建立/销毁的开销，严重影响性能，不建议长期使用。推荐替代方案：

• 使用OkHttp、Apache HttpClient这类支持智能连接池的HTTP客户端，配置连接池的最大空闲时间（如30秒），定期刷新闲置连接，避免长期复用同一连接到单一节点。
• 若使用Java原生HttpURLConnection，可通过JVM参数-Dhttp.keepAlive.timeout=30000（单位毫秒）限制连接空闲时长，超时后自动关闭连接，后续请求会重新建立连接并可能被分发到其他节点。

3. DNS缓存的优化配置 #

直接设置networkaddress.cache.ttl=0禁用DNS缓存会导致每次请求都查询DNS，极易引发DNS服务器压力过大，绝对不推荐。优化方案：

• 设置合理的DNS缓存TTL值，比如networkaddress.cache.ttl=60（60秒），既不会频繁触发DNS查询，又能定期刷新NLB的DNS解析结果，获取不同的AZ端点IP，配合DNS轮询实现负载均衡。

最优组合策略 #

1. 启用cross-zone load balancing，确保NLB能将请求分发到两个AZ的所有可用节点；
2. 使用智能HTTP客户端并配置合理的连接池参数，避免长期复用同一连接；
3. 设置30-60秒的DNS缓存TTL，平衡DNS查询频率与负载均衡效果。

该组合既能保证流量在两个节点间均衡分配，又能避免高负载下的性能损耗和DNS压力，是生产环境的最优选择。

内容的提问来源于stack exchange，提问作者ŌHARA Kazutaka