摘要：?最初的秒殺系統(tǒng)的原型是淘寶詳情上的定時上架功能，由于有些賣家為了吸引眼球，把價格壓得很低。但這給的詳情系統(tǒng)帶來了很大壓力，為了將這種突發(fā)流量隔離，才設(shè)計了秒殺系統(tǒng)，文章主要介紹大秒系統(tǒng)以及這種典型讀數(shù)據(jù)的熱點問題的解決思路和實踐經(jīng)驗。

一些數(shù)據(jù)

大家還記得2013年的小米秒殺嗎？三款小米手機各11萬臺開賣，走的都是大秒系統(tǒng)，3分鐘后成為雙十一第一家也是最快破億的旗艦店。經(jīng)過日志統(tǒng)計，前端系統(tǒng)雙11峰值有效請求約60w以上的QPS ，而后端cache的集群峰值近2000w/s、單機也近30w/s，但到真正的寫時流量要小很多了，當時最高下單減庫存tps是紅米創(chuàng)造，達到1500/s。

熱點隔離

秒殺系統(tǒng)設(shè)計的第一個原則就是將這種熱點數(shù)據(jù)隔離出來，不要讓1%的請求影響到另外的99%，隔離出來后也更方便對這1%的請求做針對性優(yōu)化。針對秒殺我們做了多個層次的隔離：

• 業(yè)務(wù)隔離。把秒殺做成一種營銷活動，賣家要參加秒殺這種營銷活動需要單獨報名，從技術(shù)上來說，賣家報名后對我們來說就是已知熱點，當真正開始時我們可以提前做好預熱。
• 系統(tǒng)隔離。系統(tǒng)隔離更多是運行時的隔離，可以通過分組部署的方式和另外99%分開。秒殺還申請了單獨的域名，目的也是讓請求落到不同的集群中。
• 數(shù)據(jù)隔離。秒殺所調(diào)用的數(shù)據(jù)大部分都是熱數(shù)據(jù)，比如會啟用單獨cache集群或MySQL數(shù)據(jù)庫來放熱點數(shù)據(jù)，目前也是不想0.01%的數(shù)據(jù)影響另外99.99%。

當然實現(xiàn)隔離很有多辦法，如可以按照用戶來區(qū)分，給不同用戶分配不同cookie，在接入層路由到不同服務(wù)接口中；還有在接入層可以對URL的不同Path來設(shè)置限流策略等。服務(wù)層通過調(diào)用不同的服務(wù)接口；數(shù)據(jù)層可以給數(shù)據(jù)打上特殊的標來區(qū)分。目的都是把已經(jīng)識別出來的熱點和普通請求區(qū)分開來。

動靜分離

前面介紹在系統(tǒng)層面上的原則是要做隔離，接下去就是要把熱點數(shù)據(jù)進行動靜分離，這也是解決大流量系統(tǒng)的一個重要原則。如何給系統(tǒng)做動靜分離的靜態(tài)化改造我以前寫過一篇《高訪問量系統(tǒng)的靜態(tài)化架構(gòu)設(shè)計》詳細介紹了淘寶商品系統(tǒng)的靜態(tài)化設(shè)計思路，感興趣的可以在《程序員》雜志上找一下。我們的大秒系統(tǒng)是從商品詳情系統(tǒng)發(fā)展而來，所以本身已經(jīng)實現(xiàn)了動靜分離，如圖1。

?

圖1 大秒系統(tǒng)動靜分離

除此之外還有如下特點：

• 把整個頁面Cache在用戶瀏覽器
• 如果強制刷新整個頁面，也會請求到CDN
• 實際有效請求只是“刷新?lián)寣殹卑粹o

?

這樣把90%的靜態(tài)數(shù)據(jù)緩存在用戶端或者CDN上，當真正秒殺時用戶只需要點擊特殊的按鈕“刷新?lián)寣殹奔纯?#xff0c;而不需要刷新整個頁面，這樣只向服務(wù)端請求很少的有效數(shù)據(jù)，而不需要重復請求大量靜態(tài)數(shù)據(jù)。秒殺的動態(tài)數(shù)據(jù)和普通的詳情頁面的動態(tài)數(shù)據(jù)相比更少，性能也比普通的詳情提升3倍以上。所以“刷新?lián)寣殹边@種設(shè)計思路很好地解決了不刷新頁面就能請求到服務(wù)端最新的動態(tài)數(shù)據(jù)。

基于時間分片削峰

熟悉淘寶秒殺的都知道，第一版的秒殺系統(tǒng)本身并沒有答題功能，后面才增加了秒殺答題，當然秒殺答題一個很重要的目的是為了防止秒殺器，2011年秒殺非常火的時候，秒殺器也比較猖獗，而沒有達到全民參與和營銷的目的，所以增加的答題來限制秒殺器。增加答題后，下單的時間基本控制在2s后，秒殺器的下單比例也下降到5%以下。新的答題頁面如圖2。

圖2 秒答題頁面

其實增加答題還有一個重要的功能，就是把峰值的下單請求給拉長了，從以前的1s之內(nèi)延長到2~10s左右，請求峰值基于時間分片了，這個時間的分片對服務(wù)端處理并發(fā)非常重要，會減輕很大壓力，另外由于請求的先后，靠后的請求自然也沒有庫存了，也根本到不了最后的下單步驟，所以真正的并發(fā)寫就非常有限了。其實這種設(shè)計思路目前也非常普遍，如支付寶的“咻一咻”已及微信的搖一搖。

除了在前端通過答題在用戶端進行流量削峰外，在服務(wù)端一般通過鎖或者隊列來控制瞬間請求。

數(shù)據(jù)分層校驗

圖3 分層校驗

對大流量系統(tǒng)的數(shù)據(jù)做分層校驗也是最重要的設(shè)計原則，所謂分層校驗就是對大量的請求做成“漏斗”式設(shè)計，如圖3所示：在不同層次盡可能把無效的請求過濾，“漏斗”的最末端才是有效的請求，要達到這個效果必須對數(shù)據(jù)做分層的校驗，下面是一些原則：

• 先做數(shù)據(jù)的動靜分離
• 將90%的數(shù)據(jù)緩存在客戶端瀏覽器
• 將動態(tài)請求的讀數(shù)據(jù)Cache在Web端
• 對讀數(shù)據(jù)不做強一致性校驗
• 對寫數(shù)據(jù)進行基于時間的合理分片
• 對寫請求做限流保護
• 對寫數(shù)據(jù)進行強一致性校驗

?

秒殺系統(tǒng)正是按照這個原則設(shè)計的系統(tǒng)架構(gòu)，如圖4所示。

圖4 秒殺系統(tǒng)分層架構(gòu)

把大量靜態(tài)不需要檢驗的數(shù)據(jù)放在離用戶最近的地方；在前端讀系統(tǒng)中檢驗一些基本信息，如用戶是否具有秒殺資格、商品狀態(tài)是否正常、用戶答題是否正確、秒殺是否已經(jīng)結(jié)束等；在寫數(shù)據(jù)系統(tǒng)中再校驗一些如是否是非法請求，營銷等價物是否充足（淘金幣等），寫的數(shù)據(jù)一致性如檢查庫存是否還有等；最后在數(shù)據(jù)庫層保證數(shù)據(jù)最終準確性，如庫存不能減為負數(shù)。

實時熱點發(fā)現(xiàn)

其實秒殺系統(tǒng)本質(zhì)是還是一個數(shù)據(jù)讀的熱點問題，而且是最簡單一種，因為在文提到通過業(yè)務(wù)隔離，我們已能提前識別出這些熱點數(shù)據(jù)，我們可以提前做一些保護，提前識別的熱點數(shù)據(jù)處理起來還相對簡單，比如分析歷史成交記錄發(fā)現(xiàn)哪些商品比較熱門，分析用戶的購物車記錄也可以發(fā)現(xiàn)那些商品可能會比較好賣，這些都是可以提前分析出來的熱點。比較困難的是那種我們提前發(fā)現(xiàn)不了突然成為熱點的商品成為熱點，這種就要通過實時熱點數(shù)據(jù)分析了，目前我們設(shè)計可以在3s內(nèi)發(fā)現(xiàn)交易鏈路上的實時熱點數(shù)據(jù)，然后根據(jù)實時發(fā)現(xiàn)的熱點數(shù)據(jù)每個系統(tǒng)做實時保護。 具體實現(xiàn)如下：

• 構(gòu)建一個異步的可以收集交易鏈路上各個中間件產(chǎn)品如Tengine、Tair緩存、HSF等本身的統(tǒng)計的熱點key（Tengine和Tair緩存等中間件產(chǎn)品本身已經(jīng)有熱點統(tǒng)計模塊）。
• 建立一個熱點上報和可以按照需求訂閱的熱點服務(wù)的下發(fā)規(guī)范,主要目的是通過交易鏈路上各個系統(tǒng)（詳情、購物車、交易、優(yōu)惠、庫存、物流）訪問的時間差，把上游已經(jīng)發(fā)現(xiàn)的熱點能夠透傳給下游系統(tǒng)，提前做好保護。比如大促高峰期詳情系統(tǒng)是最早知道的，在統(tǒng)計接入層上Tengine模塊統(tǒng)計的熱點URL。
• 將上游的系統(tǒng)收集到熱點數(shù)據(jù)發(fā)送到熱點服務(wù)臺上，然后下游系統(tǒng)如交易系統(tǒng)就會知道哪些商品被頻繁調(diào)用，然后做熱點保護。如圖5所示。

?

圖5 實時熱點數(shù)據(jù)后臺

重要的幾個：其中關(guān)鍵部分包括：

• 這個熱點服務(wù)后臺抓取熱點數(shù)據(jù)日志最好是異步的，一方面便于做到通用性，另一方面不影響業(yè)務(wù)系統(tǒng)和中間件產(chǎn)品的主流程。
• 熱點服務(wù)后臺、現(xiàn)有各個中間件和應(yīng)用在做的沒有取代關(guān)系，每個中間件和應(yīng)用還需要保護自己，熱點服務(wù)后臺提供一個收集熱點數(shù)據(jù)提供熱點訂閱服務(wù)的統(tǒng)一規(guī)范和工具，便于把各個系統(tǒng)熱點數(shù)據(jù)透明出來。
• 熱點發(fā)現(xiàn)要做到實時（3s內(nèi)）。

?

關(guān)鍵技術(shù)優(yōu)化點

前面介紹了一些如何設(shè)計大流量讀系統(tǒng)中用到的原則，但是當這些手段都用了，還是有大流量涌入該如何處理呢？秒殺系統(tǒng)要解決幾個關(guān)鍵問題。

Java處理大并發(fā)動態(tài)請求優(yōu)化

其實Java和通用的Web服務(wù)器相比（Nginx或Apache）在處理大并發(fā)HTTP請求時要弱一點，所以一般我們都會對大流量的Web系統(tǒng)做靜態(tài)化改造，讓大部分請求和數(shù)據(jù)直接在Nginx服務(wù)器或者Web代理服務(wù)器（Varnish、Squid等）上直接返回（可以減少數(shù)據(jù)的序列化與反序列化），不要將請求落到Java層上，讓Java層只處理很少數(shù)據(jù)量的動態(tài)請求，當然針對這些請求也有一些優(yōu)化手段可以使用：

• 直接使用Servlet處理請求。避免使用傳統(tǒng)的MVC框架也許能繞過一大堆復雜且用處不大的處理邏輯，節(jié)省個1ms時間，當然這個取決于你對MVC框架的依賴程度。
• 直接輸出流數(shù)據(jù)。使用resp.getOutputStream()而不是resp.getWriter()可以省掉一些不變字符數(shù)據(jù)編碼，也能提升性能；還有數(shù)據(jù)輸出時也推薦使用JSON而不是模板引擎（一般都是解釋執(zhí)行）輸出頁面。

?

同一商品大并發(fā)讀問題

你會說這個問題很容易解決，無非放到Tair緩存里面就行，集中式Tair緩存為了保證命中率，一般都會采用一致性Hash，所以同一個key會落到一臺機器上，雖然我們的Tair緩存機器單臺也能支撐30w/s的請求，但是像大秒這種級別的熱點商品還遠不夠，那如何徹底解決這種單點瓶頸？答案是采用應(yīng)用層的Localcache，即在秒殺系統(tǒng)的單機上緩存商品相關(guān)的數(shù)據(jù)，如何cache數(shù)據(jù)？也分動態(tài)和靜態(tài)：

• 像商品中的標題和描述這些本身不變的會在秒殺開始之前全量推送到秒殺機器上并一直緩存直到秒殺結(jié)束。
• 像庫存這種動態(tài)數(shù)據(jù)會采用被動失效的方式緩存一定時間（一般是數(shù)秒），失效后再去Tair緩存拉取最新的數(shù)據(jù)。

?

你可能會有疑問，像庫存這種頻繁更新數(shù)據(jù)一旦數(shù)據(jù)不一致會不會導致超賣？其實這就要用到我們前面介紹的讀數(shù)據(jù)分層校驗原則了，讀的場景可以允許一定的臟數(shù)據(jù)，因為這里的誤判只會導致少量一些原本已經(jīng)沒有庫存的下單請求誤認為還有庫存而已，等到真正寫數(shù)據(jù)時再保證最終的一致性。這樣在數(shù)據(jù)的高可用性和一致性做平衡來解決這種高并發(fā)的數(shù)據(jù)讀取問題。

同一數(shù)據(jù)大并發(fā)更新問題

解決大并發(fā)讀問題采用Localcache和數(shù)據(jù)的分層校驗的方式，但是無論如何像減庫存這種大并發(fā)寫還是避免不了，這也是秒殺這個場景下最核心的技術(shù)難題。

同一數(shù)據(jù)在數(shù)據(jù)庫里肯定是一行存儲（MySQL），所以會有大量的線程來競爭InnoDB行鎖，當并發(fā)度越高時等待的線程也會越多，TPS會下降RT會上升，數(shù)據(jù)庫的吞吐量會嚴重受到影響。說到這里會出現(xiàn)一個問題，就是單個熱點商品會影響整個數(shù)據(jù)庫的性能，就會出現(xiàn)我們不愿意看到的0.01%商品影響99.99%的商品，所以一個思路也是要遵循前面介紹第一個原則進行隔離，把熱點商品放到單獨的熱點庫中。但是無疑也會帶來維護的麻煩（要做熱點數(shù)據(jù)的動態(tài)遷移以及單獨的數(shù)據(jù)庫等）。

分離熱點商品到單獨的數(shù)據(jù)庫還是沒有解決并發(fā)鎖的問題，要解決并發(fā)鎖有兩層辦法。

• 應(yīng)用層做排隊。按照商品維度設(shè)置隊列順序執(zhí)行，這樣能減少同一臺機器對數(shù)據(jù)庫同一行記錄操作的并發(fā)度，同時也能控制單個商品占用數(shù)據(jù)庫連接的數(shù)量，防止熱點商品占用太多數(shù)據(jù)庫連接。
• 數(shù)據(jù)庫層做排隊。應(yīng)用層只能做到單機排隊，但應(yīng)用機器數(shù)本身很多，這種排隊方式控制并發(fā)仍然有限，所以如果能在數(shù)據(jù)庫層做全局排隊是最理想的，淘寶的數(shù)據(jù)庫團隊開發(fā)了針對這種MySQL的InnoDB層上的patch，可以做到數(shù)據(jù)庫層上對單行記錄做到并發(fā)排隊，如圖6所示。

?

圖6 數(shù)據(jù)庫層對單行記錄并發(fā)排隊

你可能會問排隊和鎖競爭不要等待嗎？有啥區(qū)別？如果熟悉MySQL會知道，InnoDB內(nèi)部的死鎖檢測以及MySQL Server和InnoDB的切換會比較耗性能，淘寶的MySQL核心團隊還做了很多其他方面的優(yōu)化，如COMMIT_ON_SUCCESS和ROLLBACK_ON_FAIL的patch，配合在SQL里面加hint，在事務(wù)里不需要等待應(yīng)用層提交COMMIT而在數(shù)據(jù)執(zhí)行完最后一條SQL后直接根據(jù)TARGET_AFFECT_ROW結(jié)果提交或回滾，可以減少網(wǎng)絡(luò)的等待時間（平均約0.7ms）。據(jù)我所知，目前阿里MySQL團隊已將這些patch及提交給MySQL官方評審。

大促熱點問題思考

以秒殺這個典型系統(tǒng)為代表的熱點問題根據(jù)多年經(jīng)驗我總結(jié)了些通用原則：隔離、動態(tài)分離、分層校驗，必須從整個全鏈路來考慮和優(yōu)化每個環(huán)節(jié)，除了優(yōu)化系統(tǒng)提升性能，做好限流和保護也是必備的功課。

除去前面介紹的這些熱點問題外，淘系還有多種其他數(shù)據(jù)熱點問題：

• 數(shù)據(jù)訪問熱點，比如Detail中對某些熱點商品的訪問度非常高，即使是Tair緩存這種Cache本身也有瓶頸問題，一旦請求量達到單機極限也會存在熱點保護問題。有時看起來好像很容易解決，比如說做好限流就行，但你想想一旦某個熱點觸發(fā)了一臺機器的限流閥值，那么這臺機器Cache的數(shù)據(jù)都將無效，進而間接導致Cache被擊穿，請求落地應(yīng)用層數(shù)據(jù)庫出現(xiàn)雪崩現(xiàn)象。這類問題需要與具體Cache產(chǎn)品結(jié)合才能有比較好的解決方案，這里提供一個通用的解決思路，就是在Cache的client端做本地Localcache，當發(fā)現(xiàn)熱點數(shù)據(jù)時直接Cache在client里，而不要請求到Cache的Server。
• 數(shù)據(jù)更新熱點，更新問題除了前面介紹的熱點隔離和排隊處理之外，還有些場景，如對商品的lastmodifytime字段更新會非常頻繁，在某些場景下這些多條SQL是可以合并的，一定時間內(nèi)只執(zhí)行最后一條SQL就行了，可以減少對數(shù)據(jù)庫的update操作。另外熱點商品的自動遷移，理論上也可以在數(shù)據(jù)路由層來完成，利用前面介紹的熱點實時發(fā)現(xiàn)自動將熱點從普通庫里遷移出來放到單獨的熱點庫中。

按照某種維度建的索引產(chǎn)生熱點數(shù)據(jù)，比如實時搜索中按照商品維度關(guān)聯(lián)評價數(shù)據(jù)，有些熱點商品的評價非常多，導致搜索系統(tǒng)按照商品ID建評價數(shù)據(jù)的索引時內(nèi)存已經(jīng)放不下，交易維度關(guān)聯(lián)訂單信息也同樣有這些問題。這類熱點數(shù)據(jù)需要做數(shù)據(jù)散列，再增加一個維度，把數(shù)據(jù)重新組織。

?

---

分享者簡介：

許令波，滴滴研究員，2009年加入淘寶，目前負責商品詳情業(yè)務(wù)和穩(wěn)定性相關(guān)工作，長期關(guān)注性能優(yōu)化領(lǐng)域，參與了淘寶高訪問量Web系統(tǒng)主要的優(yōu)化項目，著有《深入分析Java Web技術(shù)內(nèi)幕》一書,個人網(wǎng)站?http://xulingbo.net .

本文轉(zhuǎn)載自微信公眾號 中生代技術(shù) freshmanTechnology

from:https://yq.aliyun.com/articles/64762

總結(jié)

以上是生活随笔為你收集整理的淘宝大秒系统设计详解 | 许令波的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。