首先了解一下dubbo线程模型
- 如果事件处理的逻辑能迅速完成，并且不会发起新的IO请求，比如只是在内存中记个标识。则直接在IO线程上处理更快，因为减少了线程池调度。
- 但如果事件处理逻辑较慢，或者需要发起新的IO请求，比如需要查询数据库，则必须派发到线程池，否则IO线程阻塞，将导致不能接收其他请求。
- 如果用IO线程处理事件，又在事件处理过程中发起新的IO请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。
对于Dubbo集群中的Provider角色，有IO线程池（默认无界）和业务处理线程池（默认200）两个线程池，所以当业务的并发比较高，或者某些业务处理变慢，而且此时我们没给Provider的线程池配置等待Queue，业务线程池就很容易被“打满”，抛出“RejectedExecutionException: Thread pool is EXHAUSTED! ”异常。
既然Provider端已经抛出异常，表明自己已经受不了了，但线上我们却发现，Consumer无动于衷，发出的那笔请求还在一直等待直到超时。这样极其容易导致整个系统的“雪崩”，因为它违背了fail-fast原则。我们希望一旦Provider由于线程池被打满而无法收到请求，Consumer应该立即感知然后快速失败来释放线程。这是因为Dispatcher配置得不对，默认是all，我们应该配置成message。
所以，为了减少在Provider线程池打满时整个系统雪崩的风险，将dispatcher设置成message；适当扩大dubbo 接口线程池大小配置 threads；此外，根据系统该接口的低频调用特点，配置ThreadPool为缓存线程池，避免线程使用完后继续持有。
