Dubbo中的连接控制，你真的理解吗？，通用流行框架大全

先来看一个 Dubbo 构建的简单 demo，启动一个消费者（192.168.4.226）和一个提供者（192.168.4.224），配置他们的直连。

消费者：

<dubbo:reference id=“userService” check=“false”

interface=“org.apache.dubbo.benchmark.service.UserService”

url=“dubbo://192.168.4.224:20880”/>

提供者：

dubbo:service interface=“org.apache.dubbo.benchmark.service.UserService” ref=“userService” /

长连接是看不见摸不着的东西，我们需要一个观测性工作来”看到“它。启动提供者和消费者之后，可以使用如下的命令查看 tcp 连接情况

• Mac 下可使用：lsof -i:20880

• Linux 下可使用：netstat -ano | grep 20880

提供者：

[root ~]# netstat -ano | grep 20880

tcp6       0      0 192.168.4.224:20880      ::😗                    LISTEN      off (0.00/0/0)

tcp6    2502      0 192.168.4.224:20880      192.168.4.226:59100     ESTABLISHED off (0.00/0/0)

消费者：

[root@ ~]# netstat -ano | grep 20880

tcp6     320    720 192.168.4.226:59110     192.168.4.224:20880      ESTABLISHED on (0.00/0/0)

通过上述观察到的现象我们可以发现几个事实。

仅仅是启动了提供者和消费者，上述的 TCP 连接就已经存在了，要知道我并没有触发调用。也就是说，Dubbo 建连的默认策略是在地址发现时，而不是在调用时。当然，你也可以通过延迟加载 lazy="true" 来修改这一行为，这样可以将建联延迟到调用时。

<dubbo:reference id=“userService” check=“false”

interface=“org.apache.dubbo.benchmark.service.UserService”

url=“dubbo://$server.host:${server.port}”

lazy=“true”/>

除此之外，还可以发现消费者和提供者之间只有一条长连接，20880 是 Dubbo 提供者默认开放的端口，就跟 tomcat 默认开放的 8080 一个地位，而 59110 是消费者随机生成的一个端口。（我之前跟一些朋友交流过，发现很多人不知道消费者也是需要占用一个端口的）

而今天的主角”连接控制“便可以控制长连接的数量，例如我们可以进行如下的配置

<dubbo:reference id=“userService” check=“false”

interface=“org.apache.dubbo.benchmark.service.UserService”

url=“dubbo://192.168.4.224:20880”

connections=“2” />

再启动一次消费者，观察长连接情况

提供者：

[root@ ~]# netstat -ano | grep 20880

tcp6       0      0 192.168.4.224:20880      ::😗                    LISTEN      off (0.00/0/0)

tcp6    2508     96 192.168.4.224:20880      192.168.4.226:59436     ESTABLISHED on (0.00/0/0)

tcp6    5016    256 192.168.4.224:20880      192.168.4.226:59434     ESTABLISHED on (0.00/0/0)

消费者：

[root@ ~]# netstat -ano | grep 20880

tcp6       0   2520 192.168.4.226:59436     192.168.4.224:20880      ESTABLISHED on (0.00/0/0)

tcp6      48   1680 192.168.4.226:59434     192.168.4.224:20880      ESTABLISHED on (0.00/0/0)

可以看到，这里已经变成两条长连接了。

什么时候需要配置多条长连接

现在我们知道了如何进行连接控制，但什么时候我们应该配置多少条长连接呢？这个时候我可以跟你说，具体视生产情况而定，但你如果你经常看我的公众号，肯定会知道这不是我的风格，我的风格是什么？benchmark！

写作之前，我跟几个同事和网友对这个话题进行了简单的讨论，其实也没有什么定论，无非是对单连接和多连接吞吐量高低不同的论调。参考既往 Dubbo github 中的 issue，例如：https://github.com/apache/dubbo/pull/2457，我也参与了这个 pr 的讨论，讲道理，我是持怀疑态度的，我当时的观点是多连接不一定能够提升服务的吞吐量（还是挺保守的，没有这么绝对）。

那接下来，还是用 benchmark 来说话吧，测试工程还是我们的老朋友，使用 Dubbo 官方提供的 dubbo-benchmark 工程。

• 测试工程地址：https://github.com/apache/dubbo-benchmark.git

• 测试环境：2 台阿里云 Linux 4c8g ECS

测试工程在之前的文章介绍过，这里就不过多赘述了，测试方案也非常简单，两轮 benchmark，分别测试 connections=1 和 connections=2 时，观察测试方法的吞吐量。

说干就干，省略一堆测试步骤，直接给出测试结果。

connections=1

Benchmark           Mode  Cnt      Score      Error  Units

Client.createUser  thrpt    3  22265.286 ± 3060.319  ops/s

Client.existUser   thrpt    3  33129.331 ± 1488.404  ops/s

Client.getUser     thrpt    3  19916.133 ± 1745.249  ops/s

Client.listUser    thrpt    3   3523.905 ±  590.250  ops/s

connections=2

Benchmark           Mode  Cnt      Score      Error  Units

Client.createUser  thrpt    3  31111.698 ± 3039.052  ops/s

Client.existUser   thrpt    3  42449.230 ± 2964.239  ops/s

Client.getUser     thrpt    3  30647.173 ± 2551.448  ops/s

Client.listUser    thrpt    3   6581.876 ±  469.831  ops/s

从测试结果来看，似乎单连接和多连接的差距是非常大的，近乎可以看做是 2 倍了！看起来连接控制的效果真是好呀，那么事实真的如此吗？

按照这种方案第一次测试下来之后，我也不太相信这个结果，因为我之前按照其他方式做过多连接的测试，并且我也参加过第三届中间件挑战赛，使得我对长连接的认知是：大多数时候，单连接往往能发挥出最优的性能。即使由于硬件原因，这个差距也不应该是两倍。怀着这样的疑问，我开始研究，是不是我的测试场景出了什么问题呢？

发现测试方案的问题

经过和闪电侠的讨论，他的一席话最终让我定位到了问题的所在。

不知道大家看完我和闪电侠的对话，有没有立刻定位到问题所在。

之前测试方案最大的问题便是没有控制好变量，殊不知：在连接数变化的同时，实际使用的 IO 线程数实际也发生了变化。

Dubbo 使用 Netty 来实现长连接通信，提到长连接和 IO 线程的关系，这里就要介绍到 Netty 的连接模型了。一言以蔽之，Netty 的设置 IO worker 线程和 channel 是一对多的绑定关系，即一个 channel 在建连之后，便会完全由一个 IO 线程来负责全部的 IO 操作。再来看看 Dubbo 是如何设置 NettyClient 和 NettyServer 的 worker 线程组的：

客户端 org.apache.dubbo.remoting.transport.netty4.NettyClient：

private static final EventLoopGroup NIO_EVENT_LOOP_GROUP = eventLoopGroup(Constants.DEFAULT_IO_THREADS, “NettyClientWorker”);

@Override

protected void doOpen() throws Throwable {

final NettyClientHandler nettyClientHandler = new NettyClientHandler(getUrl(), this);

bootstrap = new Bootstrap();

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）

最后

我还通过一些渠道整理了一些大厂真实面试主要有：蚂蚁金服、拼多多、阿里云、百度、唯品会、携程、丰巢科技、乐信、软通动力、OPPO、银盛支付、中国平安等初，中级，高级Java面试题集合，附带超详细答案，希望能帮助到大家。

还有专门针对JVM、SPringBoot、SpringCloud、数据库、Linux、缓存、消息中间件、源码等相关面试题。

中…(img-dqwQO8m1-1711736228737)]

最后

我还通过一些渠道整理了一些大厂真实面试主要有：蚂蚁金服、拼多多、阿里云、百度、唯品会、携程、丰巢科技、乐信、软通动力、OPPO、银盛支付、中国平安等初，中级，高级Java面试题集合，附带超详细答案，希望能帮助到大家。

[外链图片转存中…(img-4BlvC3xF-1711736228738)]

还有专门针对JVM、SPringBoot、SpringCloud、数据库、Linux、缓存、消息中间件、源码等相关面试题。

[外链图片转存中…(img-xEo04Hvo-1711736228739)]