參考鏈接：http://www.taodudu.cc/news/show-5770725.html?action=onClick

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

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

2. 熱點(diǎn)隔離

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

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

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

3. 動(dòng)靜分離

前面介紹在系統(tǒng)層面上的原則是要做隔離，接下去就是要把熱點(diǎn)數(shù)據(jù)進(jìn)行動(dòng)靜分離，這也是解決大流量系統(tǒng)的一個(gè)重要原則。我們的大秒系統(tǒng)是從商品詳情系統(tǒng)發(fā)展而來(lái)，所以本身已經(jīng)實(shí)現(xiàn)了動(dòng)靜分離，如下圖所示

大秒系統(tǒng)動(dòng)靜分離
除此之外還有如下特點(diǎn)：

1. 把整個(gè)頁(yè)面Cache在用戶瀏覽器
2. 如果強(qiáng)制刷新整個(gè)頁(yè)面，也會(huì)請(qǐng)求到CDN
3. 實(shí)際有效請(qǐng)求只是“刷新?lián)寣殹卑粹o

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

4. 基于時(shí)間分片削峰

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

秒答題頁(yè)面

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

除了在前端通過(guò)答題在用戶端進(jìn)行流量削峰外，在服務(wù)端一般通過(guò)鎖或者隊(duì)列來(lái)控制瞬間請(qǐng)求。

5. 數(shù)據(jù)分層校驗(yàn)

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

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

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

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

6. 實(shí)時(shí)熱點(diǎn)發(fā)現(xiàn)

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

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

實(shí)時(shí)熱點(diǎn)數(shù)據(jù)后臺(tái)
重要的幾個(gè)：其中關(guān)鍵部分包括：

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

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

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

7.1 Java處理大并發(fā)動(dòng)態(tài)請(qǐng)求優(yōu)化

？？？

7.2 同一商品大并發(fā)讀問(wèn)題

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

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

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

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

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

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

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

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

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

你可能會(huì)問(wèn)排隊(duì)和鎖競(jìng)爭(zhēng)不要等待嗎？有啥區(qū)別？如果熟悉MySQL會(huì)知道，InnoDB內(nèi)部的死鎖檢測(cè)以及MySQL Server和InnoDB的切換會(huì)比較耗性能，淘寶的MySQL核心團(tuán)隊(duì)還做了很多其他方面的優(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ò)的等待時(shí)間（平均約0.7ms）。據(jù)我所知，目前阿里MySQL團(tuán)隊(duì)已將這些patch及提交給MySQL官方評(píng)審。

8. 大促熱點(diǎn)問(wèn)題思考

以秒殺這個(gè)典型系統(tǒng)為代表的熱點(diǎn)問(wèn)題根據(jù)多年經(jīng)驗(yàn)我總結(jié)了些通用原則：隔離、動(dòng)態(tài)分離、分層校驗(yàn)，必須從整個(gè)全鏈路來(lái)考慮和優(yōu)化每個(gè)環(huán)節(jié)，除了優(yōu)化系統(tǒng)提升性能，做好限流和保護(hù)也是必備的功課文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-706106.html

到了這里，關(guān)于大秒殺系統(tǒng)設(shè)計(jì)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！