雙 11 購物節(jié) ing，除了剁手黨們已經(jīng)展開敗家行動(dòng)外，雙 11 也對(duì)各大電商平臺(tái)的服務(wù)支撐提出了更高挑戰(zhàn)。如何保證買家在購物過程中的流暢體驗(yàn)十分重要，再具性價(jià)比的商品在碰到網(wǎng)站無法響應(yīng)時(shí)也會(huì)失去吸引力。因此，在各位買家開啟買買買血拼模式的同時(shí)，各大電商平臺(tái)也嚴(yán)陣以待，為一年中最繁忙的一天提供更強(qiáng)有力的 IT 技術(shù)保障。 我們注意到，雖然京東、淘寶、蘇寧等大型電商已經(jīng)憑借自身過硬的技術(shù)實(shí)力解決了高峰期間的 IT 壓力，但是更多的中小型電商面對(duì)如此大的業(yè)務(wù)波動(dòng)時(shí)還顯得無能為力。在本次雙 11 期間，我們將從技術(shù)角度出發(fā)，推出一系列專題文章，為大家解密電商平臺(tái)的 IT 技術(shù)架構(gòu)在面臨秒殺搶購、消費(fèi)者人物畫像、商品推薦及搜索、業(yè)務(wù)高可用和多地訪問、非結(jié)構(gòu)化數(shù)據(jù)處理等業(yè)務(wù)場(chǎng)景的具體應(yīng)對(duì)之策和技術(shù)實(shí)現(xiàn)。 今天的內(nèi)容主要集中在秒殺及搶購背后的 IT 架構(gòu)及實(shí)現(xiàn)。 電商秒殺活動(dòng)的業(yè)務(wù)特點(diǎn) 1、活動(dòng)波峰波谷狀態(tài)明顯 電商通過秒殺活動(dòng)為其經(jīng)營產(chǎn)品造勢(shì)，秒殺活動(dòng)一般時(shí)間較為固定，活動(dòng)通常需要經(jīng)歷產(chǎn)品發(fā)布、秒殺倒計(jì)時(shí)、到點(diǎn)秒殺、用戶付款等一系列流程，在秒殺點(diǎn)前后服務(wù)器負(fù)載成峰值狀態(tài)，服務(wù)器負(fù)載隨著活動(dòng)退卻而減少。 2、秒殺通常涉及不止一個(gè)業(yè)務(wù) 電商秒殺活動(dòng)，用戶在等待秒殺的過程中也為電商網(wǎng)站帶來了流量，當(dāng)秒殺活動(dòng)進(jìn)行過程中，用戶身份認(rèn)證、支付業(yè)務(wù)、積分業(yè)務(wù)也會(huì)同時(shí)發(fā)生。 3、時(shí)間短、瞬時(shí)并發(fā)量高 秒殺活動(dòng)是一個(gè)特別考驗(yàn)后臺(tái)數(shù)據(jù)庫、緩存服務(wù)的業(yè)務(wù)，對(duì)于數(shù)據(jù)庫、緩存的性能要求特別嚴(yán)格。一旦后臺(tái)數(shù)據(jù)服務(wù)沒有跟上，秒殺活動(dòng)將成為空談。 秒殺背后的技術(shù)挑戰(zhàn) 1、突增的服務(wù)器及網(wǎng)絡(luò)需求 雙 11 這個(gè)萬眾狂歡的節(jié)日，對(duì)于電商員工來說，每個(gè)環(huán)節(jié)都面臨前所未有的考驗(yàn)。 對(duì) IT 運(yùn)維部門來講，需要備足充分的服務(wù)器和網(wǎng)絡(luò)帶寬資源來應(yīng)付這一挑戰(zhàn)。通常情況下，雙 11 的服務(wù)器使用是平時(shí)的 3-5 倍，網(wǎng)絡(luò)帶寬是平時(shí) 2-4 倍，如何在短時(shí)間應(yīng)付這些問題，如何讓 IT 投資利用最大化，是擺在電商 IT 們面前一大難題。 2、業(yè)務(wù)高并發(fā)，服務(wù)負(fù)載重 我們通常衡量一個(gè) Web 系統(tǒng)的吞吐率的指標(biāo)是 QPS(Query Per Second，每秒處理請(qǐng)求數(shù))，解決每秒數(shù)萬次的高并發(fā)場(chǎng)景，這個(gè)指標(biāo)非常關(guān)鍵。 假設(shè)處理一個(gè)業(yè)務(wù)請(qǐng)求平均響應(yīng)時(shí)間為 100 ms，同時(shí)，系統(tǒng)內(nèi)有 20 臺(tái) Web 服務(wù)器，配置最大連接數(shù)為 500 個(gè)，Web 系統(tǒng)的理論峰值 QPS 為 (理想化的計(jì)算方式)：100000 (10 萬 QPS) 意味著 1 秒鐘可以處理完 10 萬的請(qǐng)求，而“秒殺”的那 5w/s 的秒殺似乎是“紙老虎”。 實(shí)際情況，在高并發(fā)的實(shí)際場(chǎng)景下，服務(wù)器處于高負(fù)載的狀態(tài)，網(wǎng)絡(luò)帶寬被擠滿，在這個(gè)時(shí)候平均響應(yīng)時(shí)間會(huì)被大大增加。隨著用戶數(shù)量的增加，數(shù)據(jù)庫連接進(jìn)程增加，需要處理的上下文切換也越多，服務(wù)器造成負(fù)載壓力越來越重。 3、業(yè)務(wù)耦合度高，引起系統(tǒng)“雪崩” 更可怕的問題是，當(dāng)系統(tǒng)上某個(gè)應(yīng)用因?yàn)檠舆t而變得不可用，用戶的點(diǎn)擊越頻繁，惡性循環(huán)最終導(dǎo)致“雪崩”，因?yàn)槠渲幸慌_(tái)服務(wù)器掛了，導(dǎo)致流量分散到其他正常工作的機(jī)器上，再導(dǎo)致正常的機(jī)器也掛，然后惡性循環(huán)，將整個(gè)系統(tǒng)拖垮。 電商秒殺活動(dòng)應(yīng)對(duì)策略 1、彈性資源伸縮，快速響應(yīng) 不像傳統(tǒng) IT 模式，企業(yè) IT 部門需要預(yù)先先采購大量的服務(wù)器及網(wǎng)絡(luò)帶寬資源，用戶在青云 QingCloud 上可即點(diǎn)即用服務(wù)器資源，隨時(shí)滿足電商用戶的計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)需求。通過靈活的公網(wǎng) IP 策略，用戶可以按照帶寬和流量策略調(diào)整計(jì)費(fèi)模式，隨時(shí)擴(kuò)縮資源情況。 除此之外，利用青云自動(dòng)伸縮 (AutoScaling) 功能可以幫助用戶基于資源的監(jiān)控告警規(guī)則動(dòng)態(tài)調(diào)節(jié)配置或集群規(guī)模，比如調(diào)整帶寬上限，擴(kuò)容關(guān)系型數(shù)據(jù)庫的存儲(chǔ)空間，增加或減少負(fù)載均衡器后端數(shù)量。 2、系統(tǒng)模塊有效切分 為了防止系統(tǒng)應(yīng)用過于耦合，我們一般建議用戶在系統(tǒng)架構(gòu)上做到有效切分，以防業(yè)務(wù)之間因?yàn)橘Y源的爭(zhēng)搶帶來的相互影響： · 用戶請(qǐng)求分發(fā)模塊： 通過青云的負(fù)載均衡器集群 (Load Balancer Cluster) 可以將一個(gè)公網(wǎng) IP 的流量，分散到多個(gè)負(fù)載均衡器節(jié)點(diǎn)做并發(fā)處理，突破單負(fù)載均衡器節(jié)點(diǎn)的能力瓶頸，提供可擴(kuò)展的轉(zhuǎn)發(fā)帶寬和 HTTPS 卸載能力。 · 用戶請(qǐng)求預(yù)處理模塊： 在內(nèi)網(wǎng)開通多臺(tái)主機(jī)，主機(jī)上盡量使用無狀態(tài)服務(wù)器，主機(jī)上可以預(yù)處理用戶請(qǐng)求，通過后端 IO 監(jiān)控，隨時(shí)增減主機(jī)數(shù)量。 · 用戶請(qǐng)求處理模塊： 把通過預(yù)處理的請(qǐng)求封裝成事務(wù)提交給數(shù)據(jù)庫，并返回是否成功。 · 數(shù)據(jù)庫接口模塊： 該模塊是數(shù)據(jù)庫的唯一接口，負(fù)責(zé)與數(shù)據(jù)庫交互，提供 RPC 接口供查詢是否秒殺結(jié)束、剩余數(shù)量等信息。另外 QingCloud 提供關(guān)系型數(shù)據(jù)庫服務(wù)，包括主從節(jié)點(diǎn)、高可用服務(wù)、讀寫分離、自動(dòng)備份、在線擴(kuò)容以及監(jiān)控告警等各種管理功能。 3、充分利用緩存服務(wù) 緩存 (Cache) 可以提供高性能的緩存集群。一個(gè)集群包含多個(gè)緩存節(jié)點(diǎn)，支持主從、一主多從和多主多從架構(gòu)，確保高可用。 另外，QingCloud 提供在線擴(kuò)容，自動(dòng)備份，監(jiān)控告警和圖形化操作等功能來管理集群; 集群將運(yùn)行于私有網(wǎng)絡(luò)內(nèi)，結(jié)合 QingCloud 提供的高性能硬盤，在保障高性能的同時(shí)兼顧您的數(shù)據(jù)安全。青云目前支持 Redis standalone、Redis cluster 和 Memcached 緩存。 電商秒殺活動(dòng)架構(gòu)部署 1、電商活動(dòng)常見架構(gòu)： 2、電商電商用戶在青云上的架構(gòu)展示： 3、重構(gòu)經(jīng)驗(yàn) · 盡量將請(qǐng)求攔截在系統(tǒng)上游 傳統(tǒng)秒殺系統(tǒng)之所以宕機(jī)，是因?yàn)榉?wù)請(qǐng)求都?jí)旱沽撕蠖藬?shù)據(jù)層，數(shù)據(jù)讀寫鎖沖突嚴(yán)重，并發(fā)高響應(yīng)慢，幾乎所有請(qǐng)求都超時(shí)，流量雖大，下單成功的有效流量甚小。所以用戶在做系統(tǒng)重構(gòu)時(shí)候，根據(jù)業(yè)務(wù)特點(diǎn)首先在前端對(duì)數(shù)據(jù)進(jìn)行請(qǐng)求攔截，以減少數(shù)據(jù)層面壓力。 · 數(shù)據(jù)層擴(kuò)展 構(gòu)建數(shù)據(jù)庫 Slave 集群，從單節(jié)點(diǎn) MySQL 數(shù)據(jù)庫轉(zhuǎn)變?yōu)橐恢鞫鄰牡臄?shù)據(jù)庫集群; 創(chuàng)建內(nèi)網(wǎng) LB，對(duì) Slave 集群做負(fù)載均衡，將數(shù)據(jù)庫讀請(qǐng)求分散到多個(gè) Slave 節(jié)點(diǎn)上; 根據(jù)功能做數(shù)據(jù)庫讀寫分離。 · 讀多寫少的常用多使用緩存處理 (推薦使用 Redis) Redis 是一個(gè) key-value 存儲(chǔ)系統(tǒng)。和 Memcached 類似，它支持存儲(chǔ)的 Value 類型相對(duì)更多，包括 String (字符串)、List(鏈表)、Set (集合) 和 Zset (有序集合)。這些數(shù)據(jù)類型都支持 Push/Pop、Add/Remove 及取交集并集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎(chǔ)上，Redis 支持各種不同方式的排序。
|
|
|
