dubbo 长连接

1、dubbo://

Dubbo 缺省协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。反之，Dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。Transporter: mina, netty, grizzySerialization: dubbo, hessian2, java, jsonDispatcher: all, direct, message, execution, connectionThreadPool: fixed, cached 特性缺省协议，使用基于 mina 1.1.7 和 hessian 3.2.1 的 tbremoting 交互。连接个数：单连接连接方式：长连接传输协议：TCP 传输方式：NIO 异步传输序列化：Hessian 二进制序列化适用范围：传入传出参数数据包较小（建议小于 100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用 dubbo 协议传输大文件或超大字符串。适用场景：常规远程服务方法调用约束参数及返回值需实现 Serializable 接口参数及返回值不能自定义实现 List , Map , Number , Date , Calendar 等接口，只能用 JDK 自带的实现，因为 hessian 会做特殊处理，自定义实现类中的属性值都会丢失。Hessian 序列化，只传成员属性值和值的类型，不传方法或静态变量，兼容情况详细查看官方文档

2、问题

看过一篇博客 讲解的是 dubbotcp 链接过多的情况dubbo连接池爆满然后跟着实验了一遍;先看下有总共有 4 个提供者

 <!-- dubbo服务发布配置文件 --> <dubbo:service interface="com.**.MenuFacade" ref="menuFacadeImpl"/> <dubbo:service interface="com.**.MaterialFacade" ref="materialFacadeImpl"/> <dubbo:service interface="com.**.QrCodeFacade" ref="qrCodeFacadeImpl"/> <dubbo:service interface="com.**.WeChatCommonFacade" ref="weChatCommonFacadeImpl"  />

提供者 provider 端口是 18220;有若干个消费者;先不做额外操作；先看一下有多少个 tcp 长连接

netstat -an |grep 18220

结果可以看到有 8 个连接

1.将某个 provider 链接设置为 10 个，consumer 不设置

 <dubbo:service interface="com.*.WeChatCommonFacade" ref="weChatCommonFacadeImpl" connections="10" />

启动然后查看 tcp 链接数

netstat -an |grep 18220 | wc -l

显示的结果为 38;之前是 8 个中有三个消费者是消费 WeChatCommonFacade 服务的；现在变成了 38，明显是多了很多个，这个多出来的是 WeChatCommonFacade 这个 Provider 跟它的消费者连接数，WeChatCommonFacade 的消费者有三个

3*10=30 个链接数了;

2.将一台 comsumer 的连接数配置成 5 个

在之前的基础上，我们把其中一台 ip 为：*...194 的 consumer 连接数改成 5

<dubbo:reference id="weChatCommonFacade" check="false" interface="com.*.WeChatCommonFacade" connections="5"  />

再看看提供者的 tcp 连接数

总共有 33 个；少了 5 个，说明我们修改了 consumer 的连接数起作用了，以 consumer 为准了；(至于 194 的连接数有 6 个不用在意，多出的那个 tcp 链接是另一个消费者消费了另一个提供者)

3.将 consumer 设置为懒连接 lazy="true"

<dubbo:reference id="weChatCommonFacade" check="false" interface="com.*.WeChatCommonFacade" connections="5" lazy="true" />

netstat -an |grep 18220 | wc -l 结果：28 又少了五个连接;因为这个服务没有被调用，所以没有建立起 tcp 链接；等第一次调用这个服务的时候就会建立起这个 tcp 的长连接的；所以 lazy 延迟连接有利于减少长连接数；

4.粘滞连接 sticky="true"

<dubbo:reference id="weChatCommonFacade" check="false" interface="com.*.WeChatCommonFacade" connections="5" sticky="true" />

粘滞连接用于有状态服务，尽可能让客户端总是向同一提供者发起调用，除非该提供者挂了，再连另一台。粘滞连接将自动开启延迟连接，以减少长连接数。

5.actives="" 可建立连接数如果小于 connections 连接数的话 tcp 连接会一直尝试建立连接

可以看到一直是 TIME_WAIT 状态

dubbo官网如果访问不了,去下面链接直接下载dubbo文档下载