dubbo 长连接

dubbo://

Dubbo 缺省协议采用单一长连接和 NIO 异步通讯,适合于小数据量大并发的服务调用,以及
服务消费者机器数远大于服务提供者机器数的情况。
反之,Dubbo 缺省协议不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很
低。
Transporter: mina, netty, grizzy
Serialization: dubbo, hessian2, java, json
Dispatcher: all, direct, message, execution, connection
ThreadPool: 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 序列化,只传成员属性值和值的类型,不传方法或静态变量,兼容情况
详细查看官方文档


问题

看过一篇博客 讲解的是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文档下载

  • 4
    点赞
  • 26
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 4
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

石臻臻的杂货铺

不用打赏,加微信,交个朋友就好

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值