dubbo异步调用模式和本地多线程如何取舍？？
0
悬赏园豆：20
[已解决问题]
解决于 2023-01-07 11:49
dubbo的异步调用模式在我看来用的是服务端线程池处理模式，也就是压力在服务端。
如果不用dubbo的异步模式，自己客户端实现，比如使用CompletableFuture在客户端实现多线程异步调用，在我看来就是多线程压力转到客户端。
那么问题来了，我们用dubbo的异步调用的理由是什么，他这样做能带来什么样的好处？为什么不直接自己客户端简单实现个线程池异步调用，这样做有什么坏处？
有没有大神能回答我这个问题，最近在改造一个前同事写的适配自身业务的dubbo异步框架，就是基于dubbo自身的异步功能做的，但我实在找不到放弃我原先直接客户端线程池异步调用的方式，采用dubbo异步框架的理由？？？？？？？
最佳答案
0
首先，在服务端使用线程池来处理异步调用可以提升服务端的吞吐量，因为服务端在处理请求的时候不需要等待响应，而是将请求提交给线程池处理，就可以继续接收新的请求。如果客户端使用CompletableFuture实现多线程异步调用，那么服务端依然需要等待响应，因此不会带来同样的好处。
其次，使用Dubbo的异步调用模式还可以减少客户端的压力。如果客户端使用CompletableFuture实现多线程异步调用，那么客户端需要维护自己的线程池来处理异步调用，这会增加客户端的资源开销，而使用Dubbo的异步调用模式，客户端可以直接调用接口并立即返回，不需要维护自己的线程池。
至于为什么不直接自己实现线程池异步调用，这样做的确可以让服务端和客户端都受益，但是这会增加实现的复杂度，因为需要考虑如何在服务端和客户端之间传递异步调用的结果