前言
之前我們有一個(gè)業(yè)務(wù)在負(fù)載大的情況下超時(shí)多，領(lǐng)導(dǎo)下令消滅超時(shí)交易。義不容辭干吧。
問(wèn)題描述
我們這個(gè)業(yè)務(wù)輸出形式類似芝麻評(píng)分，部署架構(gòu)是 接入層-》業(yè)務(wù)邏輯-》評(píng)分服務(wù)層。每個(gè)層對(duì)應(yīng)一個(gè)物理進(jìn)程。真正計(jì)算分?jǐn)?shù)的就是評(píng)分服務(wù)層。我想按照這樣的步驟依次查詢問(wèn)題：1 評(píng)分服務(wù)是否達(dá)到性能上線 2 是否業(yè)務(wù)邏輯層訪問(wèn)評(píng)分服務(wù)條件苛刻
1 評(píng)分服務(wù)是否達(dá)到性能上線
我對(duì)評(píng)分服務(wù)的交易時(shí)間做了一個(gè)統(tǒng)計(jì)，樣本量95w：
- 平均響耗時(shí)時(shí)間 301ms
- 標(biāo)準(zhǔn)查 238ms
- 最小耗時(shí)時(shí)間 6ms
- 前25%耗時(shí)時(shí)間 176ms
- 前75%耗時(shí)時(shí)間 372ms
- 前90%耗時(shí)時(shí)間 511ms
- 前99%耗時(shí)時(shí)間 993ms
- 最大耗時(shí)時(shí)間 15000ms
- 高于10秒的數(shù)量 26筆
沒(méi)有處理失敗的交易，但是有耗時(shí)比較長(zhǎng)的交易，評(píng)分服務(wù)并沒(méi)有達(dá)到上限。
為什么有的交易耗時(shí)超過(guò)10s？從業(yè)務(wù)的角度說(shuō)，可能某個(gè)人的數(shù)據(jù)量大，計(jì)算占用io和cpu都比較大。
2 是否業(yè)務(wù)邏輯層訪問(wèn)評(píng)分服務(wù)條件苛刻
業(yè)務(wù)邏輯訪問(wèn)評(píng)分服務(wù)是通過(guò)nginx做反向代理的，最終請(qǐng)求是負(fù)載到多個(gè)服務(wù)器上。我們觀察當(dāng)時(shí)的nginx訪問(wèn)日志，發(fā)現(xiàn)有499的情況。
nginx 499 CLIENT CLOSED REQUEST
nginx引入的非標(biāo)準(zhǔn)的狀態(tài)碼，來(lái)表示當(dāng)nginx正在處理請(qǐng)求時(shí)，客戶端關(guān)閉了連接
我查詢了業(yè)務(wù)邏輯層訪問(wèn)評(píng)分服務(wù)的時(shí)間：連接2秒，讀取10秒。問(wèn)題找到，當(dāng)評(píng)分服務(wù)負(fù)載比較大時(shí)，處理某些請(qǐng)求的時(shí)間可能會(huì)超過(guò)10秒。因?yàn)闃I(yè)務(wù)邏輯層設(shè)置的讀取超時(shí)時(shí)間10s，所以主動(dòng)斷開了連接。
方案
方案1，修改業(yè)務(wù)邏輯層訪問(wèn)評(píng)分服務(wù)和接入層訪問(wèn)業(yè)務(wù)邏輯層的讀取時(shí)間，大于評(píng)分服務(wù)正常處理請(qǐng)求的最大時(shí)間。缺點(diǎn)：這是治標(biāo)不治本的方法，客戶的體驗(yàn)比較差。
方案2，在評(píng)分服務(wù)層解決，找出消耗時(shí)間比較大的代碼位置，考慮優(yōu)化。缺點(diǎn)，周期比較長(zhǎng)
方案3，橫向拓展評(píng)分服務(wù)層。缺點(diǎn)，消耗機(jī)器資源（沒(méi)那多的錢買機(jī)器）
潛在的問(wèn)題
增大客戶端的讀取時(shí)間，是否會(huì)影響整體系統(tǒng)的吞吐量
我們統(tǒng)計(jì)了評(píng)分服務(wù)耗時(shí)時(shí)間相關(guān)指標(biāo)，百分之99的交易均能在993ms，即1s內(nèi)完成，真正耗時(shí)長(zhǎng)的交易非常少，所以對(duì)整體的系統(tǒng)吞吐量基本構(gòu)不成影響。
后記
遇到問(wèn)題，分析問(wèn)題，以事實(shí)說(shuō)話。
stay hungry, stay foolish
