transfer服務(wù)并發(fā)優(yōu)化的方法是什么

這篇文章主要介紹“transfer服務(wù)并發(fā)優(yōu)化的方法是什么”，在日常操作中，相信很多人在transfer服務(wù)并發(fā)優(yōu)化的方法是什么問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”transfer服務(wù)并發(fā)優(yōu)化的方法是什么”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

一、背景

業(yè)務(wù)反饋Java的Transfer服務(wù)有調(diào)用超時(shí)情況。

二、問(wèn)題排查與優(yōu)化

閱讀代碼發(fā)現(xiàn)，數(shù)據(jù)來(lái)了之后，循環(huán)處理，消息放到本地隊(duì)列，是同步的方式，這里并發(fā)肯定會(huì)影響性能，果斷優(yōu)化；

三、優(yōu)化過(guò)程

四、經(jīng)驗(yàn)總結(jié)

1、盡量減少I(mǎi)O操作

    尤其是網(wǎng)絡(luò)IO，尤其是在for循環(huán)中使用網(wǎng)絡(luò)IO，如果必須要使用，考慮使用緩存替代。

• 案例一：本次調(diào)用hbs獲取uuid，其實(shí)可以從DB獲取，只有獲取不到的情況才從接口獲取；這個(gè)調(diào)用接口問(wèn)題也是服務(wù)慢的最主要原因，每次請(qǐng)求如果list的size是1000，且不帶uuid，那么就要訪問(wèn)1000次接口，怎么快？

• 案例二：循環(huán)中會(huì)往kafka投遞數(shù)據(jù)，這個(gè)也是網(wǎng)絡(luò)IO，可能比調(diào)用hbs快很多，但是還是網(wǎng)絡(luò)IO，還是影響性能的，所以后面改成了本地IO，并使用基于樂(lè)觀鎖的ConcurrentLinkedQueue。

2、異步處理

    業(yè)務(wù)如果不關(guān)心服務(wù)響應(yīng)內(nèi)容，可考慮將接口修改成異步，這樣業(yè)務(wù)的請(qǐng)求立即返回，服務(wù)端需要考慮的就是如何快速處理服務(wù)。

    如本次優(yōu)化，異步后最起碼可以解決客戶端等待問(wèn)題，避免由于服務(wù)端問(wèn)題影響客戶端。

3、NIO理念，分段處理，減少等待

    先說(shuō)下優(yōu)化之后的邏輯（分四段處理），每一段一個(gè)線程池，每個(gè)線程池用不同的名稱，方便觀察：

• --》接收請(qǐng)求，多線程異步處理

• --》循環(huán)中往ConcurrentLinkedQueue添加數(shù)據(jù)的時(shí)候，采用多線程異步（雖然樂(lè)觀鎖，但是也會(huì)碰到自旋情況）

• --》新增個(gè)定時(shí)任務(wù)，一秒鐘一次消費(fèi)ConcurrentLinkedQueue的數(shù)據(jù)，并將數(shù)據(jù)放到list

• --》多線程處理，當(dāng)list達(dá)到200時(shí)，push到kafka

然后對(duì)每一段的線程池的緩沖隊(duì)列增加監(jiān)控，觀察哪一步有積壓，說(shuō)明那一步可能比較慢，可以適當(dāng)增加線程的數(shù)量。

4、第三方緩存與本地緩存合理使用

    本地緩存

        優(yōu)點(diǎn)：速度快，不需要經(jīng)過(guò)建立遠(yuǎn)程連接，網(wǎng)絡(luò)傳輸過(guò)程等消耗；

        缺點(diǎn)：占用本地內(nèi)存，當(dāng)系統(tǒng)處理速度慢的時(shí)候，造成本地?cái)?shù)據(jù)積壓，從而消耗本地內(nèi)存，導(dǎo)致頻繁的GC

    第三方緩存 

        優(yōu)點(diǎn)：不占用本地緩存

        缺點(diǎn)：速度慢，需要經(jīng)過(guò)建立遠(yuǎn)程連接，網(wǎng)絡(luò)傳輸過(guò)程等消耗；

    本系統(tǒng)采集兩種方式結(jié)合：在offer數(shù)據(jù)的時(shí)候使用本地ConcurrentLinkedQueue存儲(chǔ)，消費(fèi)ConcurrentLinkedQueue數(shù)據(jù)投遞到平臺(tái)服務(wù)端的時(shí)候使用kafka進(jìn)行緩沖，使用flink進(jìn)行消費(fèi)kafka數(shù)據(jù)發(fā)送到平臺(tái)服務(wù)端。

為什么這么做呢？

1、在offer數(shù)據(jù)的時(shí)候使用本地ConcurrentLinkedQueue存儲(chǔ)，主要考慮這種數(shù)據(jù)消費(fèi)起來(lái)比較快，不會(huì)造成本地積壓；

2、投遞到平臺(tái)服務(wù)，由于是要建立http連接，有可能受到此服務(wù)穩(wěn)定性的影響，所以為了保障本服務(wù)的穩(wěn)定性，使用flink做這個(gè)事情。

5、計(jì)算密集型服務(wù)與IO密集型服務(wù)分離

    合理申請(qǐng)相關(guān)配置咨詢，提高并發(fā)能力。

    本服務(wù)是兩種操作都有，如循環(huán)遍歷的時(shí)候是計(jì)算密集型；

    將數(shù)據(jù)推送到遠(yuǎn)端是網(wǎng)絡(luò)IO密集型，如果放到一個(gè)服務(wù)，尤其是一個(gè)線程邏輯的時(shí)候很容易造成等待，所以此處需要分離，然后對(duì)于計(jì)算密集型的，申請(qǐng)cpu性能好的，對(duì)于IO密集型的選擇磁盤(pán)或者網(wǎng)卡好的

    計(jì)算機(jī)的并發(fā)瓶頸怎么估算？

    對(duì)于一個(gè)2GHZ的CPU，運(yùn)輸速度是20億次/秒，意味著如果是純CPU密集型操作，對(duì)于簡(jiǎn)單的請(qǐng)求，理論上能達(dá)到20億次并發(fā)，當(dāng)然這當(dāng)然是不可能的，因?yàn)榫W(wǎng)絡(luò)請(qǐng)求還有很多因素的影響，如線程切換消耗，網(wǎng)絡(luò)IO開(kāi)銷，連接建立過(guò)程等，僅供評(píng)估使用。

到此，關(guān)于“transfer服務(wù)并發(fā)優(yōu)化的方法是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！