1.應用背景
短信使用kafka實作異步發送,kafka消費者配置兩台機器共32個線程來發送短信,短信供應商有夢網和大漢三通兩家,消費線程接收到短信請求後會在兩個供應商之間随機選擇一個來進行發送。
2.問題出現
市場反應短信收不到或短信延遲問題,應用伺服器上報錯誤日志。
其中,大漢三通報密碼錯誤異常、夢網報Axisfault異常。
3.分析問題
由于異常是偶發異常,而且短信發送子產品一直沒有更新,是以初步懷疑是不是因為業務上升,短信并發提高,造成部分短信發送失敗。
有了懷疑之後,找兩個短信供應商進行溝通,了解其在大并發條件下的承載能力,其中問題主要集中在以下幾個:
1)你們在大量并發時,會不會将建立的連接配接釋放?
2)你們有沒有進行壓力測試,可不可以給我們一個我們可以同時建立連接配接的門檻值?
3)一個帳号100個線程(當時考慮業務高峰時我們差不多起6台機器100個線程進行短信支援)同時發起短信發送請求是不是會出現問題?
得到的答複:
夢網:将原因歸于未使用長連接配接來進行短信的發送,對問題1、3沒有正面回答,2問題的回答為沒有進行過壓力測試。
大漢三通:承認并發量大的時候确實存在短信的異常問題,重新給了我們一個新的jar包(包更新時為何沒有通知到我們未可知),對問題1、2、3都進行了回答,新版本可以支援大并發。
溝通之後,仍不放心,根據兩家供應商的使用者手冊結合我們使用的情況分析兩家服務商背景實作,可以确認,在短連結的時候,夢網使用同步操作處理請求(這種方式如何承受巨大的壓力),發送短信之後直接傳回結果。
大漢三通使用異步方式處理請求,結果必須通過報告的方式從額外的接口來擷取。
4.解決問題
當晚将短信發送改成新的jar包方式,單起一台機器隻使用大漢三通來處理短信發送請求,同時在,dubbo平台将新加的機器權重調高,問題解決。