[实战干货]C10K场景下的线上Dubbo问题排查（2）

场景 2：单边连接导致交易超时

1、分析单边连接产生的原因

TCP 建立连接三次握手的过程中，若全连接队列满，将导致单边连接。

全连接队列大小由系统参数 net.core.somaxconn 及 listen(somaxconn,backlog) 的 backlog 取最小值决定。somaxconn 是 Linux 内核的参数，默认值是 128；backlog 在创建 Socket 时设置，Dubbo2.5.9 中默认 backlog 值是 50。因此，生产环境全连接队列是 50。通过 ss 命令（Socket Statistics）也查得全连接队列大小为 50。

观察 TCP 连接队列情况，证实存在全连接队列溢出的现象。

即：全连接队列容量不足导致大量单边连接产生。因在本验证场景下，订阅提供方的消费方数量过多，当提供方重启后，注册中心向消费方推送提供方上线通知，所有消费方几乎同时与提供方重建连接，导致全连接队列溢出。

2、分析单边连接影响范围

单边连接影响范围多为消费方首笔交易，偶发为首笔开始连续失败 2-3 笔。

建立为单边的连接下，交易非必然失败。三次握手全连接队列满后，若半连接队列空闲，提供方创建定时器向消费方重传 syn+ack，重传默认 5 次，重传间隔以倍数增长，1s..2s..4s.. 共 31s。在重传次数内，若全连接队列恢复空闲，消费方应答 ack、连接建立成功。此时交易成功。

在重传次数内，若全连接队列仍然忙碌，新交易到达超时时间后失败。

到达重传次数后，连接被丢弃。此后消费方发送请求，提供方应答 RST。后交易到达超时时间失败。

根据 Dubbo 的服务调用模型，提供方发送RST后，消费方抛出异常 Connection reset by peer，后断开与提供方的连接。而消费方无法收到当前交易的响应报文、导致超时异常。同时，消费方定时器每2s检测与提供方连接，若连接异常，发起重连，连接恢复。此后交易正常。

3

C10K 场景问题分析总结

总结以上造成交易超时的原因有两个：

1、心跳机制导致 netty worker 线程忙碌。在每个心跳任务中，提供方向所有 1 个心跳周期内未收发过报文的消费方发送心跳；消费方向所有 1 个心跳周期内未收发过报文的提供方发送心跳。提供方上所连接的消费方较多，导致心跳报文堆积；同时，处理心跳过程消耗较多 CPU，影响了业务报文的处理时效。

2、全连接队列容量不足。在提供方重启后该队列溢出，导致大量单边连接产生。单边连接下首笔交易大概率超时失败。

4

下一步思考

1、针对以上场景 1：如何能降低单个 netty worker 线程处理心跳的时间，加速 IO 线程的运行效率？初步设想了如下几种方案：

• 降低单个心跳的处理耗时
  
• 增加 netty worker 线程数，降低单个 IO 线程的负载
  
• 打散心跳，避免密集处理
  

2、针对以上场景 2：如何规避首笔大量半连接导致的交易失败？设想了如下方案：

• 增加 TCP 全连接队列的长度，涉及操作系统、容器、Netty
  
• 提高服务端 accept 连接的速度
  

交易报文处理效率提升

ALIWARE

1

逐层优化

基于以上设想，我们从系统层面、Dubbo 框架层面进行了大量的优化，以提升 C10K 场景下交易处理效率，提升服务调用的性能容量。

优化内容包括以下方面：

具体涉及优化的框架层如下：

经对各优化内容逐项验证，各措施均有不同程度的提升，效果分别如下：

2

综合优化验证效果

综合运用以上优化效果最佳。在此 1 个提供方连接 7000 个消费方的验证场景下，重启提供方后、长时间运行无交易超时场景。对比优化前后，提供方 CPU 峰值下降 30%，消费方与提供方之间处理时差控制在 1ms 以内，P99 交易耗时从 191ms 下降至 125ms。在提升交易成功率的同时，有效减少了消费方等待时间、降低了服务运行资源占用、提升了系统稳定性。

3

线上实际运行效果

基于以上验证结果，中国工商银行在分布式服务平台中集成了以上优化内容。截至发文日期，线上已存在应用一个提供方上连接上万个消费方的场景。落地该优化版本后，在提供方版本升级、及长时间运行下均无异常交易超时情况，实际运行效果符合预期。