API加速的業(yè)務(wù)邏輯實(shí)例分析
推薦 + 挑錯(cuò) + 收藏(0) + 用戶評(píng)論(0)
一天清晨,我被一個(gè)客戶電話驚醒,客戶異常焦急,尋問CDN能不能幫助他們解決“秒殺”的問題,他們昨天剛剛進(jìn)行了“整點(diǎn)秒殺活動(dòng)”,結(jié)果并發(fā)量過大,導(dǎo)致服務(wù)宕機(jī),用戶投訴。
為了理清思路,我問了對(duì)方三個(gè)問題:
(1)服務(wù)宕機(jī)的表現(xiàn)是什么?
(2)業(yè)務(wù)的基本架構(gòu)什么樣?
(3)秒殺的峰值并發(fā)到多少?
順著這些線索,我們先一起還原了應(yīng)用場(chǎng)景:
某電商業(yè)務(wù)架構(gòu)圖
該公司是一家P2P理財(cái)網(wǎng)站,常有用戶在整點(diǎn)搶購高利率理財(cái)產(chǎn)品的“整點(diǎn)秒殺活動(dòng)”。如上圖所示,終端用戶請(qǐng)求先通過前端負(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)行了簡單的分庫分表及讀寫分離。
進(jìn)行“秒殺”時(shí),先由風(fēng)控和運(yùn)營人員選好理財(cái)產(chǎn)品,然后標(biāo)記到數(shù)據(jù)庫中;活動(dòng)開始由產(chǎn)品人員放開,終端用戶搶購。
該公司的業(yè)務(wù)主要來自移動(dòng)端,平時(shí)流量較少,但“秒殺”活動(dòng)時(shí)會(huì)瞬間產(chǎn)生大量流量,峰值并發(fā)達(dá)到10萬以上(其中可能包括bot),如此大的并發(fā)主要是集中在以下兩類接口:
對(duì)于理財(cái)產(chǎn)品的刷新接口,類似GET /get_fprod.php?uid={$1}&pid={$2}&sid={$3},此類接口的請(qǐng)求量最多,占比90%。
對(duì)于理財(cái)產(chǎn)品的下單接口,類似 GET /order_fprod?uid={$1}&pid={$2}&oid={$3}&sid={$4},此類接口的請(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é)論:
(1)客戶以移動(dòng)業(yè)務(wù)為主,產(chǎn)品通過API在客戶端渲染UI,產(chǎn)品中幾乎沒有靜態(tài)資源,帶寬流量不高,傳統(tǒng)CDN無法達(dá)到卸載壓力的作用;
(2)秒殺時(shí),產(chǎn)生大量502/504超時(shí)請(qǐng)求,說明此時(shí)用戶請(qǐng)求已超過服務(wù)端的業(yè)務(wù)承載能力,急需擴(kuò)容。
基于以上兩點(diǎn),我沒有建議該公司采購CDN服務(wù),而是推薦服務(wù)擴(kuò)容,但隨著我方對(duì)于業(yè)務(wù)更深層次的分析,逐漸發(fā)現(xiàn)了一些詭異的事情。
“詭異”現(xiàn)象
(1) 數(shù)據(jù)庫主從負(fù)載極不均衡,通過MySQL管理工具,發(fā)現(xiàn)主庫的Query量高達(dá)80%;
(2)Redis Cache節(jié)點(diǎn)負(fù)載極不均衡,通過查看redis info發(fā)現(xiàn),秒殺時(shí),其中一臺(tái)Redis請(qǐng)求量極大,占比達(dá)90%以上,其他Redis請(qǐng)求量卻很低。
上述反常現(xiàn)象激起了雙方技術(shù)人員的興趣,這也許就是問題的關(guān)鍵!隨著分析深入,第一個(gè)現(xiàn)象的原因浮出水面:該公司在使用數(shù)據(jù)庫時(shí),并未如某些大型電商平臺(tái)一樣使用數(shù)據(jù)庫中間件層進(jìn)行MySQL請(qǐng)求的路由分發(fā),而是在業(yè)務(wù)代碼端,使用語言層面的框架完成讀寫分離工作。這帶來了兩個(gè)弊端:
程序員繞過語言層框架開發(fā),并未真正實(shí)施讀寫分離;
產(chǎn)品人員要求展現(xiàn)效果實(shí)時(shí),倒逼開發(fā)人員修改業(yè)務(wù)邏輯,會(huì)犧牲讀寫分離,使數(shù)據(jù)都在主庫讀寫。
非常好我支持^.^
(0) 0%
不好我反對(duì)
(0) 0%
下載地址
API加速的業(yè)務(wù)邏輯實(shí)例分析下載
相關(guān)電子資料下載
- Pipeline中throwIt的用法 62
- Python怎么使用漫威庫 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
- 愛立信消費(fèi)者實(shí)驗(yàn)室報(bào)告:差異化的5G連接為運(yùn)營商帶來商機(jī) 230
- 緩存的好處和類型 84
- 工程師分享的7個(gè)編程習(xí)慣 103