关于dubbo:dubbo线程模型及参数优化持续更新

一、Dubbo 整体架构图

二、线程模型

• 官网地址：https://dubbo.apache.org/zh/d…

三、本地 dubbo 测试记录

（一）踩坑

  应用 SpringBoot 构建 dubbo 服务的时候，既应用了注解配置，又遗记敞开 xml 文件配置，导致利用启动失败。

（二）消费者端配置

1. dubbo.consumer.timeout=3000，管制消费者期待服务端返回音讯的最大工夫，默认 1 秒；【默认配置下，某些服务端又存在慢办法，很容易导致申请超时报错；】

（三）服务提供端配置

1. dubbo.protocol.threadpool=cached，配置业务线程池类型；其余线程池类型如下：【若不配置，线程池默认应用 SynchronousQueue 队列（除 eager 线程池），SynchronousQueue没有容量，是无缓冲期待队列，是一个不存储元素的阻塞队列，会间接将工作交给消费者，必须等队列中的增加元素被生产后能力持续增加新的元素】
    

   1. fixed 固定大小线程池，启动时建设线程，不敞开，始终持有；(默认)
   2. cached 缓存线程池，闲暇一分钟主动删除，须要时重建；
   3. limited 可伸缩线程池，但池中的线程数只会增长不会膨胀。只增长不膨胀的目标是为了防止膨胀时忽然来了大流量引起的性能问题；
   4. eager 优先创立 Worker 线程池。在工作数量大于 corePoolSize 然而小于 maximumPoolSize 时，优先创立 Worker 来解决工作。当工作数量大于 maximumPoolSize 时，将工作放入阻塞队列中。阻塞队列充斥时抛出 RejectedExecutionException。(相比于 cached，cached 在工作数量超过 maximumPoolSize 时间接抛出异样而不是将工作放入阻塞队列)。

2. dubbo.protocol.threads=10，限度业务线程池最大线程数；等于并发访问量，超过线程数的申请间接触发回绝策略；（默认 fixed 线程池最大 200 个线程）
    

3. dubbo.protocol.dispatcher=message，配置 dispatcher 调度模式；【个别状况下倡议配置调度模式为message】，其余调度模式如下：

   1. all 所有音讯都派发到线程池，包含申请，响应，连贯事件，断开事件，心跳等；
   2. direct 所有音讯都不派发到线程池，全副在 IO 线程上间接执行；
   3. message 只有申请响应音讯派发到线程池，其它连贯断开事件，心跳等音讯，间接在 IO 线程上执行；
   4. execution 只有申请音讯派发到线程池，不含响应，响应和其它连贯断开事件，心跳等音讯，间接在 IO 线程上执行；
   5. connection 在 IO 线程上，将连贯断开事件放入队列，有序一一执行，其它音讯派发到线程池。

4. dubbo.provider.actives=10，每个服务消费者，个办法最大并发调用数；从生产端管制，并发数是业务线程池大小的子集。
    
5. dubbo.provider.executes=10，每个服务提供者各办法最大可并行执行申请数；从提供端管制，并发数是业务线程池大小的子集（小于等于业务线程池大小）。

四、主动 stack dump

  当业务线程池满时，咱们须要晓得线程都在期待哪些资源、条件，以找到零碎的瓶颈点或异样点。dubbo 通过 Jstack 主动导出线程堆栈来保留现场，不便排查问题。

默认策略:

• 导出门路，user.home 标识的用户主目录
• 导出距离，最短距离容许每隔 10 分钟导出一次

指定导出门路：
配置 dubbo.properties 文件，批改dubbo.application.dump.directory=/tmp