[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" 来修改这一行为,这样可以将建联延迟到调用时。

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

url=“dubbo://

s

e

r

v

e

r

.

h

o

s

t

:

{server.host}:

server.host:{server.port}”

lazy=“true”/>

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

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

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();

bootstrap.group(NIO_EVENT_LOOP_GROUP)

.option(ChannelOption.SO_KEEPALIVE, true)

.option(ChannelOption.TCP_NODELAY, true)

.option(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT);

}

Constants.DEFAULT_IO_THREADS 在 org.apache.dubbo.remoting.Constants 中被写死了

int DEFAULT_IO_THREADS = Math.min(Runtime.getRuntime().availableProcessors() + 1, 32);

在我的 4c8g 的机器上,默认等于 5。

服务端 org.apache.dubbo.remoting.transport.netty4.NettyServer:

protected void doOpen() throws Throwable {

bootstrap = new ServerBootstrap();

bossGroup = NettyEventLoopFactory.eventLoopGroup(1, “NettyServerBoss”);

workerGroup = NettyEventLoopFactory.eventLoopGroup(

getUrl().getPositiveParameter(IO_THREADS_KEY, Constants.DEFAULT_IO_THREADS),

“NettyServerWorker”);

final NettyServerHandler nettyServerHandler = new NettyServerHandler(getUrl(), this);

channels = nettyServerHandler.getChannels();

ServerBootstrap serverBootstrap = bootstrap.group(bossGroup, workerGroup)

.channel(NettyEventLoopFactory.serverSocketChannelClass());

.option(ChannelOption.SO_REUSEADDR, Boolean.TRUE)

.childOption(ChannelOption.TCP_NODELAY, Boolean.TRUE)

.childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT);

}

服务端倒是可以配置,例如我们可以通过 protocol 来控制服务端的 IO 线程数:

dubbo:protocol name=“dubbo” host=“${server.host}” server=“netty4” port=“${server.port}” iothreads=“5”/

如果不设置,则跟客户端逻辑一致,是 core + 1 个线程。

好了,问题就在这儿,由于我并没有进行任何 IO 线程的设置,所以客户端和服务端都会默认开启 5 个 IO 线程。当 connections=1 时,Netty 会将 channel1 绑定到一个 IO 线程上,而当 connections=2 时,Netty 会将 channel1 和 channel2 按照顺序绑定到 NettyWorkerThread-1和 NettyWorkerThread-2 上,这样就会有两个 IO 线程在工作,这样的测试结果当然是不公平的。

这里需要考虑实际情况,在实际生产中,大多数时候都是分布式场景,连接数一定都是大于 IO 线程数的,所以基本不会出现测试场景中的 channel 数少于 IO 线程数的场景。

解决方案也很简单,我们需要控制变量,让 IO 线程数一致,仅仅观察连接数对吞吐量的影响。针对服务端,可以在 protocol 层配置 iothreads=1;针对客户端,由于源码被写死了,这里我只能通过修改源码的方式,重新本地打了一个包,使得客户端 IO 线程数也可以通过 -D 参数指定。

改造之后的,我们得到了如下的测试结果:

1 IO 线程 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

1 IO 线程 2 连接

Benchmark           Mode  Cnt      Score      Error  Units

Client.createUser  thrpt    3  21776.436 ± 1888.845  ops/s

Client.existUser   thrpt    3  31826.320 ± 1350.434  ops/s

Client.getUser     thrpt    3  19354.470 ±  369.486  ops/s

Client.listUser    thrpt    3   3506.714 ±   18.924  ops/s

可以发现,单纯提升连接数并不会提升服务的吞吐量,这样的测试结果也更加符合我认知的预期。

总结

从上述测试的结果来看,一些配置参数并不是越大就代表了越好,类似的例子我也在多线程写文件等场景分析过,唯有理论分析+实际测试才能得出值得信服的结论。当然个人的测试,也可能会因为局部性关键信息的遗漏,导致误差,例如,如果我最终没有发现 IO 线程数和连接数之间的隐性关联,很容易就得出连接数和吞吐量成正比的错误结论了。当然,也不一定就代表本文最终的结论是靠谱的,说不定还是不够完善的,也欢迎大家留言,提出意见和建议。

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

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

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

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

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

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)

2021年Java中高级面试必备知识点总结

在这个部分总结了2019年到目前为止Java常见面试问题,取其面试核心编写成这份文档笔记,从中分析面试官的心理,摸清面试官的“套路”,可以说搞定90%以上的Java中高级面试没一点难度。

本节总结的内容涵盖了:消息队列、Redis缓存、分库分表、读写分离、设计高并发系统、分布式系统、高可用系统、SpringCloud微服务架构等一系列互联网主流高级技术的知识点。

目录:

(上述只是一个整体目录大纲,每个点里面都有如下所示的详细内容,从面试问题——分析面试官心理——剖析面试题——完美解答的一个过程)

部分内容:

对于每一个做技术的来说,学习是不能停止的,小编把2019年到目前为止Java的核心知识提炼出来了,无论你现在是处于什么阶段,如你所见,这份文档的内容无论是对于你找面试工作还是提升技术广度深度都是完美的。

不想被后浪淘汰的话,赶紧搞起来吧,高清完整版一共是888页,需要的话可以点赞+关注 《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取! L-1713342267355)]

部分内容:

[外链图片转存中…(img-oLKmPTd9-1713342267355)]

[外链图片转存中…(img-qa2hZ70f-1713342267355)]

[外链图片转存中…(img-s2OmE3nm-1713342267356)]

对于每一个做技术的来说,学习是不能停止的,小编把2019年到目前为止Java的核心知识提炼出来了,无论你现在是处于什么阶段,如你所见,这份文档的内容无论是对于你找面试工作还是提升技术广度深度都是完美的。

不想被后浪淘汰的话,赶紧搞起来吧,高清完整版一共是888页,需要的话可以点赞+关注 《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!

推荐文章

评论可见,请评论后查看内容,谢谢!!!
 您阅读本篇文章共花了: