1.定時(shí)任務(wù)查詢大量記錄，利用多線程將這些記錄通過dubbo接口發(fā)送給第三方，并且等待第三方的結(jié)果，更新這些記錄。2.dubbo的接口普遍都比較慢，大致在30秒以上。3.數(shù)據(jù)庫分配的最大連接數(shù)在200. 利用線程池去處理dubbo接口交互，線程池里面的線程數(shù)控制在200以內(nèi)。4.在數(shù)據(jù)庫連接池200以內(nèi)，處理量始終上不去，機(jī)器負(fù)載也很低，感覺資源浪費(fèi)很嚴(yán)重。因?yàn)榈诎⒂耫ubbo接口和連接池綁定再一起，也不能一直無限開啟線程數(shù)大小。5，在上面這種情況下 該如何優(yōu)化，可以最大限度的利用機(jī)器負(fù)載，短時(shí)間內(nèi)完成大量dubbo交互
2 回答
吃雞游戲
TA貢獻(xiàn)1829條經(jīng)驗(yàn) 獲得超7個(gè)贊
看上去是你的dubbo接口是瓶頸，比數(shù)據(jù)庫查詢慢多了。
所以你應(yīng)該用200個(gè)線程去數(shù)據(jù)庫查詢，把記錄放到隊(duì)列里，然后用大于200的線程（比如400吧）從隊(duì)列里取記錄，負(fù)責(zé)調(diào)用dubbo接口。
如果dubbo接口有批量模式，盡量用批量模式。
慕田峪9158850
TA貢獻(xiàn)1794條經(jīng)驗(yàn) 獲得超8個(gè)贊
其實(shí)很想解決你的問題，我最喜歡這種問題的了。但是你表達(dá)的，嗯，算我理解能力差。 以我盡力理解的問題后，答案是這樣的，你說接口在30s，那么你200個(gè)線程同時(shí)去處理，那也只是7個(gè)TPS那樣。依你說所的機(jī)器負(fù)載低，那我就算你硬盤IO，CPU負(fù)載都不高，也可以算出你查詢的數(shù)據(jù)量并不大。我猜你的問題就是在于，網(wǎng)絡(luò)延遲上。這種延遲要么是，網(wǎng)絡(luò)的問題，要么就是server方（就是你的第三方）服務(wù)處理慢。 而解決這種延遲一般采用以下方式：
- 解決網(wǎng)絡(luò)問題的延遲（是有點(diǎn)廢話且困難，但卻是最有效）
- 定位server方的服務(wù)為什么這么慢（跟上面也差不多廢話，但卻是最有效）
- 保持TCP鏈接，用連接池的方法達(dá)到TCP復(fù)用。
- 加大TCP的連接數(shù)，不然你只有200個(gè)連接，而你每個(gè)連接處理事務(wù)都要30S，這種情況，不加大TCP連接數(shù)，吞吐量是起不來的。
添加回答
舉報(bào)
0/150
提交
取消