多线程处理IO密集型问题

新手上路,请多包涵

1.定时任务查询大量记录,利用多线程将这些记录通过dubbo接口发送给第三方,并且等待第三方的结果,更新这些记录。
2.dubbo的接口普遍都比较慢,大致在30秒以上。
3.数据库分配的最大连接数在200. 利用线程池去处理dubbo接口交互,线程池里面的线程数控制在200以内。
4.在数据库连接池200以内,处理量始终上不去,机器负载也很低,感觉资源浪费很严重。因为第阿勇dubbo接口和连接池绑定再一起,也不能一直无限开启线程数大小。
5,在上面这种情况下 该如何优化,可以最大限度的利用机器负载,短时间内完成大量dubbo交互

阅读 4.7k
2 个回答

看上去是你的dubbo接口是瓶颈,比数据库查询慢多了。

所以你应该用200个线程去数据库查询,把记录放到队列里,然后用大于200的线程(比如400吧)从队列里取记录,负责调用dubbo接口。

如果dubbo接口有批量模式,尽量用批量模式。

其实很想解决你的问题,我最喜欢这种问题的了。但是你表达的,嗯,算我理解能力差。 以我尽力理解的问题后,答案是这样的,你说接口在30s,那么你200个线程同时去处理,那也只是7个TPS那样。依你说所的机器负载低,那我就算你硬盘IO,CPU负载都不高,也可以算出你查询的数据量并不大。我猜你的问题就是在于,网络延迟上。这种延迟要么是,网络的问题,要么就是server方(就是你的第三方)服务处理慢。 而解决这种延迟一般采用以下方式:

  1. 解决网络问题的延迟(是有点废话且困难,但却是最有效)
  2. 定位server方的服务为什么这么慢(跟上面也差不多废话,但却是最有效)
  3. 保持TCP链接,用连接池的方法达到TCP复用。
  4. 加大TCP的连接数,不然你只有200个连接,而你每个连接处理事务都要30S,这种情况,不加大TCP连接数,吞吐量是起不来的。
撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题