Dubbo线程模式和多协议与Netty线程模式详解分析

概述

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源码分析