API加速的業(yè)務(wù)邏輯實例分析
一天清晨，我被一個客戶電話驚醒，客戶異常焦急，尋問CDN能不能幫助他們解決“秒殺”的問題，他們昨天剛剛進行了“整點秒殺活動”，結(jié)果并發(fā)量過大，導(dǎo)致服務(wù)宕機，用戶投訴。
為了理清思路，我問了對方三個問題：
（1）服務(wù)宕機的表現(xiàn)是什么？
（2）業(yè)務(wù)的基本架構(gòu)什么樣？
（3）秒殺的峰值并發(fā)到多少？
順著這些線索，我們先一起還原了應(yīng)用場景：
某電商業(yè)務(wù)架構(gòu)圖
該公司是一家P2P理財網(wǎng)站，常有用戶在整點搶購高利率理財產(chǎn)品的“整點秒殺活動”。如上圖所示，終端用戶請求先通過前端負載均衡，然后到達運行實際電商邏輯的Web Server；再下層是運行在VM上的8臺Redis，負責存儲與業(yè)務(wù)相關(guān)的Cache數(shù)據(jù)，如用戶Profile、理財產(chǎn)品信息、用戶賬單信息等。實際落地數(shù)據(jù)存儲在MySQL中，該MySQL只進行了簡單的分庫分表及讀寫分離。
進行“秒殺”時，先由風控和運營人員選好理財產(chǎn)品，然后標記到數(shù)據(jù)庫中；活動開始由產(chǎn)品人員放開，終端用戶搶購。
該公司的業(yè)務(wù)主要來自移動端，平時流量較少，但“秒殺”活動時會瞬間產(chǎn)生大量流量，峰值并發(fā)達到10萬以上（其中可能包括bot），如此大的并發(fā)主要是集中在以下兩類接口：
對于理財產(chǎn)品的刷新接口，類似GET /get_fprod.php？uid={$1}&pid={$2}&sid={$3}，此類接口的請求量最多，占比90%。
對于理財產(chǎn)品的下單接口，類似 GET /order_fprod？uid={$1}&pid={$2}&oid={$3}&sid={$4}，此類接口的請求量較少，占比不到1%，但存在大量504超時。
其中uid是用戶ID，pid是理財產(chǎn)品ID，oid是訂單號，sid是隨著客戶端用戶變化的隨機token標識。
場景解讀
根據(jù)與客戶溝通得到的場景，初步得到了以下結(jié)論：
（1）客戶以移動業(yè)務(wù)為主，產(chǎn)品通過API在客戶端渲染UI，產(chǎn)品中幾乎沒有靜態(tài)資源，帶寬流量不高，傳統(tǒng)CDN無法達到卸載壓力的作用；
?。?）秒殺時，產(chǎn)生大量502/504超時請求，說明此時用戶請求已超過服務(wù)端的業(yè)務(wù)承載能力，急需擴容。
基于以上兩點，我沒有建議該公司采購CDN服務(wù)，而是推薦服務(wù)擴容，但隨著我方對于業(yè)務(wù)更深層次的分析，逐漸發(fā)現(xiàn)了一些詭異的事情。
“詭異”現(xiàn)象
?。?） 數(shù)據(jù)庫主從負載極不均衡，通過MySQL管理工具，發(fā)現(xiàn)主庫的Query量高達80%；
?。?）Redis Cache節(jié)點負載極不均衡，通過查看redis info發(fā)現(xiàn)，秒殺時，其中一臺Redis請求量極大，占比達90%以上，其他Redis請求量卻很低。
上述反?，F(xiàn)象激起了雙方技術(shù)人員的興趣，這也許就是問題的關(guān)鍵！隨著分析深入，第一個現(xiàn)象的原因浮出水面：該公司在使用數(shù)據(jù)庫時，并未如某些大型電商平臺一樣使用數(shù)據(jù)庫中間件層進行MySQL請求的路由分發(fā)，而是在業(yè)務(wù)代碼端，使用語言層面的框架完成讀寫分離工作。這帶來了兩個弊端：
程序員繞過語言層框架開發(fā)，并未真正實施讀寫分離；
產(chǎn)品人員要求展現(xiàn)效果實時，倒逼開發(fā)人員修改業(yè)務(wù)邏輯，會犧牲讀寫分離，使數(shù)據(jù)都在主庫讀寫。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%