transfer服務并發優化的方法是什么

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

一、背景

業務反饋Java的Transfer服務有調用超時情況。

二、問題排查與優化

閱讀代碼發現，數據來了之后，循環處理，消息放到本地隊列，是同步的方式，這里并發肯定會影響性能，果斷優化；

三、優化過程

四、經驗總結

1、盡量減少IO操作

    尤其是網絡IO，尤其是在for循環中使用網絡IO，如果必須要使用，考慮使用緩存替代。

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

• 案例二：循環中會往kafka投遞數據，這個也是網絡IO，可能比調用hbs快很多，但是還是網絡IO，還是影響性能的，所以后面改成了本地IO，并使用基于樂觀鎖的ConcurrentLinkedQueue。

2、異步處理

    業務如果不關心服務響應內容，可考慮將接口修改成異步，這樣業務的請求立即返回，服務端需要考慮的就是如何快速處理服務。

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

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

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

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

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

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

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

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

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

    本地緩存

        優點：速度快，不需要經過建立遠程連接，網絡傳輸過程等消耗；

        缺點：占用本地內存，當系統處理速度慢的時候，造成本地數據積壓，從而消耗本地內存，導致頻繁的GC

    第三方緩存 

        優點：不占用本地緩存

        缺點：速度慢，需要經過建立遠程連接，網絡傳輸過程等消耗；

    本系統采集兩種方式結合：在offer數據的時候使用本地ConcurrentLinkedQueue存儲，消費ConcurrentLinkedQueue數據投遞到平臺服務端的時候使用kafka進行緩沖，使用flink進行消費kafka數據發送到平臺服務端。

為什么這么做呢？

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

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

5、計算密集型服務與IO密集型服務分離

    合理申請相關配置咨詢，提高并發能力。

    本服務是兩種操作都有，如循環遍歷的時候是計算密集型；

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

    計算機的并發瓶頸怎么估算？

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

到此，關于“transfer服務并發優化的方法是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！