一天清晨，我被一個(gè)客戶電話驚醒，客戶異常焦急，尋問(wèn)CDN能不能幫助他們解決“秒殺”的問(wèn)題，他們昨天剛剛進(jìn)行了“整點(diǎn)秒殺活動(dòng)”，結(jié)果并發(fā)量過(guò)大，導(dǎo)致服務(wù)宕機(jī)，用戶投訴。

　　為了理清思路，我問(wèn)了對(duì)方三個(gè)問(wèn)題：

　　（1）服務(wù)宕機(jī)的表現(xiàn)是什么？

　?。?）業(yè)務(wù)的基本架構(gòu)什么樣？

　?。?）秒殺的峰值并發(fā)到多少？

　　順著這些線索，我們先一起還原了應(yīng)用場(chǎng)景：

　　某電商業(yè)務(wù)架構(gòu)圖

　　該公司是一家P2P理財(cái)網(wǎng)站，常有用戶在整點(diǎn)搶購(gòu)高利率理財(cái)產(chǎn)品的“整點(diǎn)秒殺活動(dòng)”。如上圖所示，終端用戶請(qǐng)求先通過(guò)前端負(fù)載均衡，然后到達(dá)運(yùn)行實(shí)際電商邏輯的Web Server；再下層是運(yùn)行在VM上的8臺(tái)Redis，負(fù)責(zé)存儲(chǔ)與業(yè)務(wù)相關(guān)的Cache數(shù)據(jù)，如用戶Profile、理財(cái)產(chǎn)品信息、用戶賬單信息等。實(shí)際落地?cái)?shù)據(jù)存儲(chǔ)在MySQL中，該MySQL只進(jìn)行了簡(jiǎn)單的分庫(kù)分表及讀寫(xiě)分離。

　　進(jìn)行“秒殺”時(shí)，先由風(fēng)控和運(yùn)營(yíng)人員選好理財(cái)產(chǎn)品，然后標(biāo)記到數(shù)據(jù)庫(kù)中；活動(dòng)開(kāi)始由產(chǎn)品人員放開(kāi)，終端用戶搶購(gòu)。

　　該公司的業(yè)務(wù)主要來(lái)自移動(dòng)端，平時(shí)流量較少，但“秒殺”活動(dòng)時(shí)會(huì)瞬間產(chǎn)生大量流量，峰值并發(fā)達(dá)到10萬(wàn)以上（其中可能包括bot），如此大的并發(fā)主要是集中在以下兩類(lèi)接口：

　　對(duì)于理財(cái)產(chǎn)品的刷新接口，類(lèi)似GET /get_fprod.php？uid={$1}&pid={$2}&sid={$3}，此類(lèi)接口的請(qǐng)求量最多，占比90%。

　　對(duì)于理財(cái)產(chǎn)品的下單接口，類(lèi)似 GET /order_fprod？uid={$1}&pid={$2}&oid={$3}&sid={$4}，此類(lèi)接口的請(qǐng)求量較少，占比不到1%，但存在大量504超時(shí)。

　　其中uid是用戶ID，pid是理財(cái)產(chǎn)品ID，oid是訂單號(hào)，sid是隨著客戶端用戶變化的隨機(jī)token標(biāo)識(shí)。

　　場(chǎng)景解讀

　　根據(jù)與客戶溝通得到的場(chǎng)景，初步得到了以下結(jié)論：

　?。?）客戶以移動(dòng)業(yè)務(wù)為主，產(chǎn)品通過(guò)API在客戶端渲染UI，產(chǎn)品中幾乎沒(méi)有靜態(tài)資源，帶寬流量不高，傳統(tǒng)CDN無(wú)法達(dá)到卸載壓力的作用；

　?。?）秒殺時(shí)，產(chǎn)生大量502/504超時(shí)請(qǐng)求，說(shuō)明此時(shí)用戶請(qǐng)求已超過(guò)服務(wù)端的業(yè)務(wù)承載能力，急需擴(kuò)容。

　　基于以上兩點(diǎn)，我沒(méi)有建議該公司采購(gòu)CDN服務(wù)，而是推薦服務(wù)擴(kuò)容，但隨著我方對(duì)于業(yè)務(wù)更深層次的分析，逐漸發(fā)現(xiàn)了一些詭異的事情。

　　“詭異”現(xiàn)象

　?。?） 數(shù)據(jù)庫(kù)主從負(fù)載極不均衡，通過(guò)MySQL管理工具，發(fā)現(xiàn)主庫(kù)的Query量高達(dá)80%；

　?。?）Redis Cache節(jié)點(diǎn)負(fù)載極不均衡，通過(guò)查看redis info發(fā)現(xiàn)，秒殺時(shí)，其中一臺(tái)Redis請(qǐng)求量極大，占比達(dá)90%以上，其他Redis請(qǐng)求量卻很低。

　　上述反?，F(xiàn)象激起了雙方技術(shù)人員的興趣，這也許就是問(wèn)題的關(guān)鍵！隨著分析深入，第一個(gè)現(xiàn)象的原因浮出水面：該公司在使用數(shù)據(jù)庫(kù)時(shí)，并未如某些大型電商平臺(tái)一樣使用數(shù)據(jù)庫(kù)中間件層進(jìn)行MySQL請(qǐng)求的路由分發(fā)，而是在業(yè)務(wù)代碼端，使用語(yǔ)言層面的框架完成讀寫(xiě)分離工作。這帶來(lái)了兩個(gè)弊端：

　　程序員繞過(guò)語(yǔ)言層框架開(kāi)發(fā)，并未真正實(shí)施讀寫(xiě)分離；

　　產(chǎn)品人員要求展現(xiàn)效果實(shí)時(shí)，倒逼開(kāi)發(fā)人員修改業(yè)務(wù)邏輯，會(huì)犧牲讀寫(xiě)分離，使數(shù)據(jù)都在主庫(kù)讀寫(xiě)。

相關(guān)電子資料下載

• Pipeline中throwIt的用法 62
• Python怎么使用漫威庫(kù) 62
• 如何實(shí)現(xiàn)RTOS、中間件和芯片廠商API的跟蹤可觀察性？ 178
• 深入探討Granite Rapids和Sierra Forest處理器架構(gòu)技術(shù) 20
• 基于OpenVINO Python API部署RT-DETR模型 107
• MaaS，云廠商在打一場(chǎng)“翻身仗” 525
• Nginx常用配置與命令 20
• 愛(ài)立信消費(fèi)者實(shí)驗(yàn)室報(bào)告：差異化的5G連接為運(yùn)營(yíng)商帶來(lái)商機(jī) 230
• 緩存的好處和類(lèi)型 84
• 工程師分享的7個(gè)編程習(xí)慣 103