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

在洪雅等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都做網(wǎng)站、成都網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè) 網(wǎng)站設(shè)計制作按需定制網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站設(shè)計,成都全網(wǎng)營銷,成都外貿(mào)網(wǎng)站建設(shè),洪雅網(wǎng)站建設(shè)費用合理。

一、背景

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

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

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

三、優(yōu)化過程

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

1、盡量減少IO操作

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

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

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

2、異步處理

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

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

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

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

• --》接收請求，多線程異步處理

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

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

• --》多線程處理，當list達到200時，push到kafka

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

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

    本地緩存

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

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

    第三方緩存 

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

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

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

為什么這么做呢？

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

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

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

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

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

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

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

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

到此，關(guān)于“transfer服務(wù)并發(fā)優(yōu)化的方法是什么”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
本文名稱：transfer服務(wù)并發(fā)優(yōu)化的方法是什么
文章轉(zhuǎn)載：http://weahome.cn/article/pigice.html