dubbo消费者与提供者之间的tcp长连接

dubbo消费者与提供者之间的tcp长连接

摘要

      dubbo消费者同提供者之间的tcp连接是长连接形式，连接由消费方建立随机端口主动向提供者的dubbo端口发起连接请求，一旦连接建立，除非服务停止、网络异常，否则双方不会主动关闭tcp连接。也就是说dubbo消费方在调用提供者方法时使用的tcp连接都是长连接且是复用的。

TCP建立的时机

     在dubbo消费者reference的提供者接口bean被spring实例化时会向注册中心发送消费方数据（比如ZK中此时可在/dubbo/xx.xxService/consumers节点下看到消费方数据），并且在此时会主动向提供者发起连接建立请求。当配置的连接数较大时，建立这些连接会比较耗时（根据某次测试，建立250个tcp连接大约耗时7秒）。

      请注意，因为是在bean实例化时建立tcp连接，因此当项目中使用了spring的自动注入功能（比如@Autowired注解），那么在消费方启动过程中会同此被注入的service的提供者建立tcp连接。如果配置了懒加载bean或者使用硬编码方式获取bean（比如applicationContext.getBean），且在启动时没有调用此获取bean的代码，那么在消费者启动后不会同提供者建立tcp连接，此时只有在此getBean代码在首次被执行时消费者才会同提供者之间建立tcp连接，这也是当连接数配置较大时首次访问某些接口会耗时较久的原因之一。

      Tcp建立之前，消费者会先向注册中心发送订阅消息，注册中心会将符合条件的提供者数据（比如有N个符合条件的提供者）下发到消费方，此时假如配置的连接数是100，那么此消费者会同这N个提供者之间的每一个提供者建立100个tcp连接。

TCP连接数控制

1. 根据测试结果看，默认情况下，消费者与提供者之间的tcp连接数为1；
2. 连接数可以在消费者端或者提供者端控制，配置示例，

提供者端：

or



or

消费者端：

or

和dubbo其它许多配置类似，接口层面的配置优先级高于全局配置；同样层面的配置消费者端优先于提供者。

消费方同提供方之间的通讯tcp复用机制

     如果只有一条tcp连接存在，那么必然只会使用这1个tcp交互；如果与同一个提供者之间存在多条tcp连接，那么会复用这多条连接，此时相当于连接池。具体：

1、当配置了connections并且使用dubbo协议时，每一个service都会建立自己的私有tcp连接，无论这些service是否在同一个提供者中。

比方下面的OrderService、OrderDeliverService均由10.1.50.30:10220提供者提供服务，连接数由消费者控制，其配置为，

2、当未配置connections时，属于同一个提供者的多个不同service只会共享1条tcp连接同提供者进行通讯。此消费者与10.1.50.30:10220会建立5条dubbo通讯tcp连接，其中3条为OrderService通讯服务，另外2条为OrderDeliverService通讯服务。

另外可参考dubbo官方文档

Config connections | Apache Dubbo