高性能RPC框架--Dubbo（四）

线程模型：

对于dubbo来说实际上线程分类可以分为两种一种是dubo的io线程另一种则是dubbo的业务线程

我们知道dubbo本身是基于tcp进行通讯的那么就会监听多种的事件，对于事件监听的处理如果是不同的类型的线程处理不同的事件机制就会分为不同的线程模型

• 建立连接：connected，主要是的职责是在channel记录read、write的次数，以及处理建立连接后的回调逻辑，比如dubbo支持在断开后自定义回调的hook（onconnect），即在该操作中执行。
• 断开连接：disconnected，主要是的职责是在channel移除read、write的时间，以及处理断开连接后的回调逻辑，比如dubbo支持在断开后自定义回调的hook（ondisconnect），即在该操作中执行。
• 发送消息：sent，包括发送请求和发送响应。记录write的时间。
• 接收消息：received，包括接收请求和接收响应。记录read的时间。
• 异常捕获：caught，用于处理在channel上发生的各类异常

首先dubbo的不同事件主要分为以上五种，而线程的模型则分为以下几种

线程模型	关键特性	适用场景	配置参数
all	所有请求（网络事件+业务逻辑）都由 业务线程池 处理	测试/特殊需求	dispatcher="all"
direct	所有请求在 I/O 线程 中直接处理，不切换线程	高性能场景（业务非阻塞）	dispatcher="direct"
message	默认模型：仅业务请求派发到线程池，网络事件由 I/O 线程处理	生产环境通用场景	dispatcher="message"
execution	仅业务请求派发到线程池，其他事件（如心跳）直接丢弃	需要严格过滤非业务请求的场景	dispatcher="execution"
connection	按连接分配线程，同一连接的请求在固定线程处理	需要连接级隔离的场景	dispatcher="connection"

上述五种线程模型我们一一介绍

all模型：

他主要是将所有的事件处理都交给业务线程池来进行处理这样做没有实现线程池的隔离，对于一些耗时长的操作和耗时短的操作都堆在一个线程池进行处理很有可能会造成线程池占满从而影响性能

direct模型：

他主要则是将所有事件处理都放给io线程池进行处理，因为本身dubbo的底层io是采用的netty线程模型来进行实现的所以性能更优秀吞吐量更高，同时需要注意的是direct适合耗时操作短的线程模型，如果耗时操作比较长就会使得io阻塞而影响整个服务的通信，适合 纯内存操作 或 快速非阻塞 调用（如缓存查询）。

message模型：

message模型则是dubbo的默认模型机，它是sent、connected、disconnected、caught操作在IO线程上执行，received都是在Dubbo线程上执行的。message模型可能不是性能最好的但是最稳定的，原因是他将主业务的received事件放在Dubbo线程上执行如果处理时间过长也不会阻塞其他线程的操作，同时对于耗时时间比较短的线程则是放在io中进行

execution模型：

对于execution与message模型其实是很像的两个模型，execution 线程模型和 message 线程模型 的核心区别在于 事件处理的范围 和 线程池的使用策略

对比维度	message 模型（默认）	execution 模型
处理事件类型	业务请求 + 部分网络事件（如心跳响应）	仅业务请求，其他事件直接丢弃
线程池使用	业务请求转发到线程池，网络事件由 I/O 线程处理	仅业务请求进入线程池

对于一些网络事件message则是交给业务线程进行处理，而execution则是只有业务请求给业务线程处理

connection模型：

received、connected、disconnected、caught都是在Dubbo线程上执行的。但是connected和disconnected两个行为是与其他两个行为通过线程池隔离开的。并且在Dubbo connected thread pool中提供了链接限制、告警等能力。