dubbo user guider笔记之六Demos----Thread Model

Thread Model(线程模型)

• 如果事件处理可以很快被执行完，像内存标记那样，不需要分发出新的请求，那么它可以直接由I/O线程来处理，因为它减少了线程的分发。
• 如果事件处理起来很慢，或者需要发起新的I/O请求，比如查询数据库，那么这些事件应该在线程池中被执行。否则I/O线程可能会阻塞，导致不能接收新的请求。
• 如果事件被I/O线程处理了，并且在处理的期间发起了一个新的I/O请求，比如发起了一个登陆请求，它将提示一下Potentially leading to deadlock，但是实际上deadlock可能并不会发生。

因此，我们需要不同的分发策略和不同的线程池配置来面对不同的场景。

<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />

Dispatcher(分发器)

• all:所有的消息都会被分发到线程池里，包括请求，响应，连接事件，断开连接事件和心跳。
• direct：所有的消息都会由I/O线程直接执行，不会被分发给线程池
• message:只有请求/相应消息会被分发给线程池，其他消息比如连接，心跳等消息都会由I/O线程直接处理
• execution:仅仅请求消息会被分发给线程池，其他消息都会由I/O线程直接处理
• connection:连接，断开连接会被放到队列里，然后由I/O线程依次处理，其他消息会被分发给线程池。

Thread pool (线程池)

• fixed:数量固定的线程池，默认启动时创建线程，不会关闭线程；
• cached：一个缓存的线程池，如果一个线程空闲了一分钟以上就会自动删掉这个线程。如果需要了会再次创建
• limit：弹性线程池，但是只能单向的增加线程池数量。理由是可以避免当减少线程池中的数量时出现的流量尖峰从而造成的性能问题。

标签：dubbo,请求,Thread,分发,发给,之六,处理,线程,消息
来源： https://www.cnblogs.com/po-shi/p/11262211.html