没想到吧!关于Dubbo的『消费端线程池模型』官网也写错了。 (6)

简介: 没想到吧!关于Dubbo的『消费端线程池模型』官网也写错了。 (6)

上面这个方法里面就是在搞 header 的事情。


其中有一个检查报文长度的方法:checkPayLoad。


那么问题又来了:请问 Dubbo 默认的报文长度限制是多少呢?


带大家去源码里面找答案:


image.png



答案是 8M。


另外,既然是有默认值,那必须是可以配置的。所以上图标号为①的地方是从配置中获取,获取不到,就返回默认值。


稍微有点意思的是标号为②的地方,我第一次看的时候愣是看了一分钟没反应过来。主要是前面的这个 payload > 0,我想着这不是废话嘛,长度不都是大于 0 的。兴奋的我以为发现了一个无用代码呢。


后来才理解到,如果当 payload 设置为负数的时候,就代表不限制报文长度。


可以进行如下配置:



image.png


一个基本上用不到的 Dubbo 小知识点,免费赠送给大家。


好了,header 和 body 都齐活了。


到这里,再总结一下:2.7.5 版本之前,业务数据返回后,默认在 IO 线程里面进行反序列化的操作。而2.7.5 版本之后,默认是延迟到客户端线程池里面进行反序列化的操作。

所以,对于官网中,红框框起来这个地方的描述是有问题的:


http://dubbo.apache.org/zh-cn/docs/user/demos/consumer-threadpool.html


image.png


正确的说法应该是:在老的(2.7.5 版本之前)线程池模型中,当业务数据返回后,默认在 IO 线程上进行反序列化操作,如果配置了 decode.in.io 参数为 false,则延迟到独立的客户端线程池进行反序列化操作。


聊聊线程池模型的变化


接下来再聊聊线程池模型的变化。这里的线程池指的都是客户端线程池。


先抛两个知识点:


  • 不论是新老线程池模型,默认的 Dispatch 策略都是 all。所有响应还是会转发到客户端线程池里面,在这个里面进行解码操作(如果 IO 线程没有解码的话)把结果返回到用户线程中去。


  • 对于线程池客户端的默认实现是 cached,服务端的默认实现是 fixed。


官网这里的 fixed 缺省,特指服务端:


image.png


image.png


所以会出现消费端线程数分配多的问题。


但官网的描述是:分配过多。多和过多还不一样。


为什么会过多呢?


因为在 2.7.5 版本之前,是每一个链接都对应一个客户端线程池。相当于做了链接级别的线程隔离,但是实际上这个线程隔离是没有必要的。反而影响了性能。


而在 2.7.5 版本里面,就是不管你多少链接,大家共用一个客户端线程池,引入了 threadless executor 的概念。


简单的来说,优化结果就是从多个线程池改为了共用一个线程池。


线程池模型的变化,我在《Dubbo 2.7.5在线程模型上的优化》里面比较详细的聊过了,就不在重复讲了,有兴趣的可以去翻一下。


感谢您的阅读,我坚持原创,十分欢迎并感谢您的关注。



我是 why,一个被代码耽误的文学创作者,不是大佬,但是喜欢分享,是一个又暖又有料的四川好男人。

目录
相关文章
|
3天前
|
Java
网络 I/O:单 Selector 多线程(单线程模型)
网络 I/O:单 Selector 多线程(单线程模型)
|
3天前
|
人工智能 JSON 前端开发
【Spring boot实战】Springboot+对话ai模型整体框架+高并发线程机制处理优化+提示词工程效果展示(按照框架自己修改可对接市面上百分之99的模型)
【Spring boot实战】Springboot+对话ai模型整体框架+高并发线程机制处理优化+提示词工程效果展示(按照框架自己修改可对接市面上百分之99的模型)
|
3天前
|
安全 API 数据库
【转】Android线程模型(AsyncTask的使用)
【转】Android线程模型(AsyncTask的使用)
13 1
|
3天前
|
消息中间件 存储 网络协议
Kafka 线程模型痛点攻克: 提升分区写入 2 倍性能
Apache Kafka的单分区写入性能在某些严格保序场景中至关重要,但其现有线程模型限制了性能发挥。本文分析了Kafka的串行处理模型,包括SocketServer、KafkaChannel、RequestChannel等组件,指出其通过KafkaChannel状态机确保请求顺序处理,导致处理效率低下。AutoMQ提出流水线处理模型,简化KafkaChannel状态机,实现网络解析、校验定序和持久化的阶段间并行化,提高处理效率。测试结果显示,AutoMQ的极限吞吐是Kafka的2倍,P99延迟降低至11ms。
21 3
Kafka 线程模型痛点攻克: 提升分区写入 2 倍性能
|
3天前
|
存储 NoSQL Redis
深入浅出Redis(二):Redis单线程模型与通信流程
深入浅出Redis(二):Redis单线程模型与通信流程
|
3天前
|
NoSQL Redis
Redis 线程模型
Redis 线程模型
|
3天前
|
监控 安全 Java
【多线程学习】深入探究阻塞队列与生产者消费者模型和线程池常见面试题
【多线程学习】深入探究阻塞队列与生产者消费者模型和线程池常见面试题
|
3天前
|
Java Linux
【linux线程(三)】生产者消费者模型详解(多版本)
【linux线程(三)】生产者消费者模型详解(多版本)
|
3天前
|
消息中间件 安全 Java
多线程(初阶七:阻塞队列和生产者消费者模型)
多线程(初阶七:阻塞队列和生产者消费者模型)
32 0
|
3天前
|
缓存 NoSQL 安全
Redis 新特性篇:多线程模型解读
Redis 新特性篇:多线程模型解读
56 5