概述
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上，从而提升了响应速度，使消费的负载更均衡
