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