概述
Dubbo线程模型
IO线程组：负责IO流形式监听客户端的所有行为（连接、断开、发送读、写请求）
业务线程池：堆积和处理业务消息，默认fixed、同步阻塞队列、过载丢弃等属性
dispatcher：任务调度器，根据配置（默认all)把IO线程组监听到的事件派发到业务线程池。简单的操作，可以直接在IO线程组里做，复杂和慢的操作必须丢给业务线程池，比如数据库操作，因为IO线程组是 Nio多路复用一个 Selector 阻塞执行的，慢操作会导致其它请求的处理阻塞。
Dubbo多协议：
Dubbo协议：长连接、异步NIO、适合小数据高并发业务场景
Http协议：短连接，SpringCloud的Feign就是http协议交互的。
WebService 、Redis、Memcache、RMI等等协议
线程模型
IO线程：配置在netty连接点的用于处理网络数据的线程，主要处理编解码等直接与网络数据打交道的事件。
调用交互中，每个Provider都是一个Netty的Server端，每个Consumer都是Neety的Client端，Netty的Reactor模型中的 woker线程，就是这里指的IO线程。
每个Consumer连接成功后都有1个SocketChannel，都需要绑定在woker线程池的其中一个线程中，这里的关系是 1 对多的，1个IO线程可以绑定N个consumer的连接，从而实现 1个Provider对N个Consumer循环监听调用事件。
所以说Dubbo协议适用于 小数据量、高并发、服务提供者远小于消费者的业务场景的原理所在
业务线程：用于处理具体业务逻辑的线程，可以理解为自己在provider上写的代码所执行的线程环境。
这里也可以体现Dubbo协议框架的安全性，其实在Server端是具有一定的限流和堆积的作用。不过这种堆积是堆积在java内存中，宕机数据会丢失
防止过度的Consumer调用，导致Provider性能不足而宕机的风险。
业务线程池的饱和策略是直接抛弃且报错，结合Dubbo的多种重试策略，这个请求会很快转发到其它Provider上，从而提升了响应速度，使消费的负载更均衡
下面小编为大家整理了相关技术点如下：
需要相关资料的加群810589193免费获取！！！
Dubbo应用及源码解读
Dubbo简介及初入门
Dubbo管理中心及监控系统安装部署
领域驱动之如何正确划分Dubbo分布式服务
通讯协议TCP、UDP、HTTP分析
Dubbo负载均衡机制探析
如何完成Dubbo服务只订阅及只注册模式
架构师必备技术之如何设计Dubbo服务接口
Dubbo设计原理及源码分析
Dubbo容错机制及高扩展性分析
Dubbo服务与Docker虚拟化技术集成实战
线程模型设计的好坏，决定了系统的吞吐量，并发性和安全性能架构质量属性。Netty线程模型被精心的设计，既提升了并发性，又在很大程度避免锁，局部进行了无锁优化。
Netty线程模型
Netty服务端在启动的时候，创建了两个NioEventLoopGroup，它们实际是两个独立的Reactor线程池，一个用于接收客户端的TCP连接，另一个用于处理I/O相关的读写操作，或者执行系统Task，定时任务Task等。
Netty用于接收客户端请求的线程池职责如下：
接收客户端TCP连接，初始化Channel参数
将链路状态变更事件通知给ChannelPipeline
Netty处理I/O操作的线程池职责如下：
异步读取通信对端的数据报，发送读事件到ChannelPipeLine
异步发送消息到通信对端，调用ChannelPipeLine的消息发送接口
执行系统调用Task
执行定时任务Task
最佳实践
Netty的多线程编程最佳实践如下：
尽量不要再ChannelHandler中启动用户线程(解码后用于将POJO消息派发到后端业务线程的除外)
解码要放在NIO线程调度用的解码Handler中进行，不要切换到用户线程完成消息的解码。专门的类做专门的事，Netty内部提供了编码与解码的抽象类
如果用户业务逻辑复杂，不要再NIO线程上完成，建议派发到业务线程中执行，以保证NIO线程尽快被释放
如果用户业务逻辑简单，可以直接在NIO线程上完成。
下面小编为大家整理了相关技术点如下：
需要相关资料的加群810589193免费获取！！！
高性能Netty框架
Netty简介
I/O 演进之路及NIO 入门
Netty 开发环境搭建安装
TCP 粘包/拆包问题的解决之道
分隔符和定长×××的应用
Netty 多协议开发和应用
WebSocket 协议开发
Netty源码分析
转载于:https://blog.51cto.com/14214335/2356420
824
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
