Dubbo 心跳、重连、长连接管理知识点

一、Dubbo 为什么要用长连接？

Dubbo 默认协议是 TCP 长连接 + NIO 复用

• 短连接（HTTP）每次请求都要三次握手，开销大
• 长连接一次建立，多次复用，性能极高
• 适合微服务内部高频、小包调用

但长连接必须解决三个问题：

1. 连接断了不知道 → 心跳检测
2. 断了之后不能恢复 → 自动重连
3. 连接太多 / 失效 → 连接管理

---

二、心跳机制（核心）

1. 作用

• 探测对方是否存活
• 防止连接被防火墙、网关 “静默断开”（常见于内网、云环境）
• 维持长连接活性

2. 默认配置

• 默认心跳间隔：60s

• 心跳失败次数阈值：

  3 次

  连续 3 次没收到心跳回包 → 判定连接断开

3. 心跳流程

1. Consumer / Provider 双向都会发心跳
2. 一方发送 PING
3. 对方回复 PONG
4. 连续超时无响应 → 标记连接断开
5. 触发重连

4. 关键点

• 双向心跳：不仅消费者发，提供者也会发
• 心跳是应用层心跳，基于 Dubbo 协议，不是 TCP 自带的 Keepalive
• TCP Keepalive 间隔太长（默认 2 小时），不适合微服务

---

三、重连机制

1. 什么时候触发重连？

• 心跳连续失败
• 网络闪断
• 提供者重启
• 连接被防火墙切断

2. 重连策略

Dubbo 使用 指数退避重连（避免风暴）

1. 第一次失败：立即重试
2. 持续失败：间隔逐步加大（1s → 2s → 4s → … 上限 30s）
3. 重连成功后恢复正常

3. 重连由谁发起？

• Consumer 主动重连 Provider（客户端维持连接）
• Provider 一般不主动连 Consumer
• 注册中心推送服务下线时，Consumer 会主动废弃旧连接

---

四、长连接管理机制

1. 连接模型

• 一个 Provider 实例，对一个 Consumer 只建立一条长连接
• 多个请求复用同一条 TCP 连接，通过 NIO 异步多路复用
• 连接数 = 服务提供者数量

极大减少连接数，支持高并发。

2. 连接空闲处理

• 空闲时间过长的连接不会立即断开
• 靠心跳维持活性
• 真正断连才触发重连

3. 连接缓存

• Consumer 会本地缓存连接
• 不每次调用都重建连接
• 注册中心变更时才更新列表、重建连接

---

五、高级问题

1. Dubbo 心跳和 TCP Keepalive 区别？

• TCP Keepalive：传输层，默认 2 小时，系统级，不适合微服务
• Dubbo 心跳：应用层，60s，灵活可控，专门为 RPC 设计

2. 重连会导致重复调用吗？

有可能。

所以 写接口必须设计成幂等，Dubbo 重试 + 重连都可能引发重复请求。

3. 为什么不使用短连接？

短连接握手开销大、并发高时端口不够用，性能远差于长连接复用。

4. 心跳失败一定是服务挂了吗？

不一定：

• 网络抖动

• 防火墙静默切断

• 机器负载高、GC 卡顿导致响应慢

  所以 Dubbo 采用

  连续 3 次失败

  才判定断开。

---

六、一句话总结

Dubbo 基于 TCP 长连接 + NIO 多路复用 提升性能；

通过 60s 双向应用层心跳 检测链路存活；

连续 3 次心跳超时判定断连，并使用 指数退避策略自动重连；

同一消费者与提供者之间单条长连接复用，连接数极低、高并发友好。