Nacos 为什么使用长轮询而不是标准的 Push 或 Pull？

知识点图片

Nacos 在设计配置中心（Config Service）和服务发现（Naming Service）的数据同步机制时，选择 长轮询（Long Polling） 是为了在 实时性 和 资源消耗 之间找到最佳平衡点。

简单来说，长轮询结合了 Push（推）和 Pull（拉）的优点，同时规避了它们的缺点。

以下是详细的对比分析和 Nacos 选择长轮询的核心原因：

为了理解长轮询的优势，我们需要先看另外两种标准模式的问题：

客户端每隔固定时间（例如 1 秒）向服务端发送请求，询问“配置有没有变化？”。

缺点：
- 延迟与资源的矛盾： 如果轮询间隔短（如 1s），能保证实时性，但服务端压力巨大，且绝大多数请求都是无效的（配置未变更）；如果轮询间隔长（如 60s），服务端压力小，但配置更新会有很大延迟。
- 无效流量： 在配置不常更新的场景下，99.9% 的请求都是浪费带宽和 CPU 的。

服务端与客户端建立长连接（如 TCP/WebSocket），一旦数据变更，服务端主动推给客户端。

缺点：
- 状态维护成本高： 服务端需要维护所有客户端的长连接状态（Session），在海量客户端（如数万个微服务实例）场景下，内存和 CPU 消耗极大。
- 流控困难： 如果配置更新频繁，服务端可能会瞬间向客户端推送大量数据，导致客户端过载（需要复杂的背压机制）。
- 网络问题： 在复杂的网络环境（NAT、防火墙）下，服务端主动连接客户端往往不可行，且长连接容易断开，需要复杂的重连和心跳保活机制。

Nacos 的长轮询机制（主要用于配置中心）是这样的：

客户端发起请求： 客户端发起一个 HTTP 请求，询问配置是否有变更，并带上当前配置的 MD5。
服务端“Hold”住请求： 服务端接收到请求后，不会立即返回。
- 它会检查配置有没有变化。
- 如果有变化： 立即返回最新配置。
- 如果没有变化： 服务端利用 Servlet 3.0 的异步机制（AsyncContext）将请求挂起（Hold），通常挂起 29.5 秒（略小于客户端的 30 秒超时时间）。
事件触发或超时：
- 如果在挂起期间，有人在控制台修改了配置，服务端触发事件，立即唤醒挂起的请求并返回新配置。
- 如果挂起时间到了（29.5秒）配置仍未变，服务端返回“无变更（304）”。
客户端循环： 客户端收到响应后，立马再次发起下一次长轮询请求。

低延迟（准实时性）：
一旦配置变更，服务端能立刻响应挂起的请求。这在效果上等同于“Push”，延迟极低。
低资源消耗（轻量级）：
- 减少请求量： 相比短轮询，长轮询在无变更时每 30 秒才发生一次 HTTP 交互，大幅减少了网络开销。
- 非阻塞 IO： Nacos 服务端使用异步 Servlet，挂起请求时不占用 Tomcat 线程（线程释放回线程池），只消耗极少的内存对象，因此单机能支撑数万级客户端连接。
无状态与兼容性：
- 基于标准的 HTTP 协议，对防火墙、负载均衡器（Nginx/F5）非常友好，不需要特殊的端口或协议支持。
- 服务端不需要像 TCP 长连接那样维护复杂的客户端状态机，开发和运维更简单。
自带“流控”：
因为是客户端发起请求，客户端可以根据自身处理能力决定何时发起下一次轮询，天然避免了服务端 Push 过猛把客户端打挂的问题。

值得注意的是，虽然长轮询是 Nacos 1.x 的核心机制，也是 Nacos 设计哲学的经典体现，但在 Nacos 2.x 版本中，为了进一步提升性能和连接管理能力，Nacos 引入了 gRPC（基于 HTTP/2 的长连接）。

为什么 2.x 引入 gRPC？
虽然长轮询很好，但在超大规模（十万级以上实例）场景下，频繁建立和断开 HTTP 连接（即使是 Keep-Alive）以及 HTTP 协议本身的 Header 解析开销仍然是瓶颈。
长轮询被抛弃了吗？
并没有完全抛弃。Nacos 2.x 依然兼容 1.x 的 HTTP 长轮询接口。而且，gRPC 的双向流模式在逻辑上依然遵循了“客户端订阅 -> 服务端变更通知”的理念，只是通信通道从“反复建立的 HTTP”变成了“持久的 gRPC Stream”。

Nacos 选择长轮询是因为它在 HTTP/1.x 时代 是解决实时性与扩展性矛盾的最佳方案：

播面