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