表現(xiàn)問題說明
-
用戶信息顯示配置問題說明
-
簡要說明
-
詳細過程
-
臨時解決方案
-
問題跟進處理
-
后期優(yōu)化方案
-
21:43分補充
-
IM問題解析
-
代碼走查結果：
-
對服務端壓力描述：
-
結論：
-
pc客戶端改進：
-
關系認證服務端問題分析
-
問題描述:
-
過程分析：
-
代碼走查：
-
整改初步方案
表現(xiàn)問題說明
IM列表頁面無法顯示用戶擴展信息，有些頁面只顯示UID
用戶信息顯示配置問題分析及解決方案
簡要說明
經(jīng)排查發(fā)現(xiàn)是關系認證服務端報500錯誤，導致的連鎖反應
詳細過程
-
表單模板服務在早上9點36分時出現(xiàn)假死，見下圖：
圖1
排查發(fā)現(xiàn)請求用戶關系認證出現(xiàn)超時，查看日志發(fā)現(xiàn)關系認證服務請求超時，在99U上使用建立關系無響應。近兩天請求數(shù)據(jù)，見下圖：
圖2 -
在上周PC端接入后，Nginx請求數(shù)量從100萬一下升到500萬，見下圖：
圖3
另外查看日志發(fā)現(xiàn)PC端請求在同一時間內(nèi)存在頻繁的重復請求，見下圖：
圖4 - 表單模板服務在請求關系認證超時的情況下，也產(chǎn)生了超時情況，目前確認是在請求關系認證時，關系認證超時后，表單請求端口占滿卻沒有及時釋放，導致用戶信息顯示新的請求全部超時響應。
臨時解決方案
- 先移除關系認證數(shù)據(jù)源，保證用戶信息顯示配置服務正常
問題跟進處理
- PC端請求過多問題需要優(yōu)化
- 關系認證服務掛死問題需要排查
- 表單模板服務減少并發(fā)線程數(shù)，對數(shù)據(jù)源參數(shù)進行預檢，對緩存穿透進行攔截
后期優(yōu)化方案
- 架構調整：表單模板服務數(shù)據(jù)源聲明、數(shù)據(jù)獲取分離
- 提供根據(jù)數(shù)據(jù)源聲明獲取數(shù)據(jù)的SDK（服務端、Android、iOS、JS），各業(yè)務使用SDK獲取數(shù)據(jù)，從而防止出現(xiàn)Single Point of Failure(SPoF)
- 同時使用第二點提供的SDK實現(xiàn)一個有限并發(fā)的服務端，給一些并發(fā)量低的組件使用，減少開發(fā)量
21:43分補充
- 壓力部分可能來自自動建群（7.1上線）。
IM問題分析及解決方案
今天過來看了下代碼,pc客戶端代碼實現(xiàn)上面。
代碼走查結果：
- 好友列表、群成員列表、群成員聊天的沒有批量請求，只是單個請求（這個下周版本做成批量請求，客戶端需要優(yōu)化）。最近聯(lián)系人、組織樹、查找等模板都有批量請求。
- 如果服務端返回錯誤，客戶端不會重復去嘗試。
對服務端壓力描述：
- 對關系服務有壓力的點：就是好友列表模板（這個包含了關系信息）請求可以做成獲取批量的。但是即使沒有批量也不會有非常大的壓力。
因為只有登錄成功的情況下，會根據(jù)這個登陸賬號的好友數(shù)量來發(fā)單挑請求信息，這個其實只有一次，并且好友人數(shù)一般不會太多。 - 請求B06群模板會對信息配置服務造成壓力。但是從服務端設計上面看，是以模板+群id作為標識的；所以這個壓力最終還是很大。
結論：
昨天仙鐘發(fā)的文檔上面的 這塊，說PC端會失敗后重復請求的結論,和我理解的不一致。原因如下：
- 不是重復請求，從截圖上面看是同一個人同一時間，對不同的人去進行B06模板請求（這個截圖信息上只體現(xiàn)了suid表示的是請求者）；
- 請求的是群B06的模板,而B06模板上面是沒有好友關系配置的。從設計上對關系服務端不會有壓力，會對信息配置服務有壓力。
pc客戶端改進：
- 將好友列表、群成員列表、群成員聊天的做成批量請求。
- 不再按照服務端設計的群模板+群號來請求以及對照客戶端的緩存數(shù)據(jù)，要做降級處理。群信息模板在客戶端數(shù)據(jù)結構上面去掉群號key。（按照目前的需求實現(xiàn)上，群模板只有vip，和群號無關）
關系認證服務端問題分析及解決方案
問題描述:
昨天出現(xiàn)服務器無響應的情況經(jīng)過排查,是由于關系認證服務端數(shù)據(jù)庫鏈接耗盡。無法處理新的數(shù)據(jù)庫相關的請求。
下圖為連接耗盡時的情況（此時關系認證服務端無法處理新的請求）:
過程分析：
在9點04分開始 請求量開始增大，最多增加到每秒接近40個請求，到9點34分 數(shù)據(jù)庫連接池達到最大3000個。連接池耗盡。無法及時處理新的請求，造成請求阻塞和超時。
通過分析nginx日志和服務端的錯誤日志發(fā)現(xiàn)有如下問題。
-
有較多的無效請求到關系認證服務端：這個問題需要業(yè)務方排查一下。
Paste_Image.png -
請求量同周四和周五來看有明顯的增加，在平均在一秒內(nèi)收到的請求數(shù)峰值增加2-4倍。
Paste_Image.png - 獲取關系的接口業(yè)務邏輯較復雜，流程較長（響應時間在請求量大時會有明顯的增加）在代碼走查中會進行詳細描述。
代碼走查：
對關系認證接口實現(xiàn)邏輯進行走查結果如下:
-
獲取關系顯示的流程（下圖）
Paste_Image.png - 代碼中沒有對關鍵信息部分進行緩存處理，每次請求均直接穿透到數(shù)據(jù)庫，導致數(shù)據(jù)庫壓力 較大。
- 業(yè)務流程較長，耗用的數(shù)據(jù)庫資源較多。
整改初步方案
1、優(yōu)化關系認證的業(yè)務邏輯，減少數(shù)據(jù)庫查詢。
2、關系認證增加關系信息的緩存，減少數(shù)據(jù)庫訪問，增加吞吐量。
3、用戶信息話配置優(yōu)化處理邏輯，避免因為某個數(shù)據(jù)源出現(xiàn)問題導致整個服務出現(xiàn)問題。
