簡(jiǎn)單來(lái)說(shuō)，秒殺就是在同一時(shí)刻大量請(qǐng)求爭(zhēng)搶購(gòu)買(mǎi)同一商品并完成交易的過(guò)程。

從架構(gòu)視角來(lái)看，秒殺系統(tǒng)本質(zhì)上是一個(gè)高性能、高一致、高可用的三高系統(tǒng)。而打造并維護(hù)一個(gè)超大流量的秒殺系統(tǒng)需要進(jìn)行哪些關(guān)注，就是本文討論的話題。

整體思考

首先從高維度出發(fā)，整體思考問(wèn)題。秒殺無(wú)外乎解決兩個(gè)核心問(wèn)題，一是并發(fā)讀，一是并發(fā)寫(xiě)，對(duì)應(yīng)到架構(gòu)設(shè)計(jì)，就是高可用、一致性和高性能的要求。

關(guān)于秒殺系統(tǒng)的設(shè)計(jì)思考，本文即基于此 3 層依次推進(jìn)，簡(jiǎn)述如下：

高性能。

秒殺涉及高讀和高寫(xiě)的支持，如何支撐高并發(fā)，如何抵抗高 IOPS？核心優(yōu)化理念其實(shí)是類(lèi)似的：高讀就是盡量“少讀”或"讀少"，高寫(xiě)就是數(shù)據(jù)拆分。本文將從動(dòng)靜分離、熱點(diǎn)優(yōu)化以及服務(wù)端性能優(yōu)化 3 個(gè)方面展開(kāi)。

一致性。

秒殺的核心關(guān)注是商品庫(kù)存，有限的商品在同一時(shí)間被多個(gè)請(qǐng)求同時(shí)扣減，而且要保證準(zhǔn)確性，顯而易見(jiàn)是一個(gè)難題。如何做到既不多又不少？本文將從業(yè)界通用的幾種減庫(kù)存方案切入，討論一致性設(shè)計(jì)的核心邏輯。

高可用。

大型分布式系統(tǒng)在實(shí)際運(yùn)行過(guò)程中面對(duì)的工況是非常復(fù)雜的，業(yè)務(wù)流量的突增、依賴(lài)服務(wù)的不穩(wěn)定、應(yīng)用自身的瓶頸、物理資源的損壞等方方面面都會(huì)對(duì)系統(tǒng)的運(yùn)行帶來(lái)大大小小的的沖擊。如何保障應(yīng)用在復(fù)雜工況環(huán)境下還能高效穩(wěn)定運(yùn)行，如何預(yù)防和面對(duì)突發(fā)問(wèn)題，系統(tǒng)設(shè)計(jì)時(shí)應(yīng)該從哪些方面著手？本文將從架構(gòu)落地的全景視角進(jìn)行關(guān)注思考。高性能

動(dòng)靜分離

大家可能會(huì)注意到，秒殺過(guò)程中你是不需要刷新整個(gè)頁(yè)面的，只有時(shí)間在不停跳動(dòng)。

這是因?yàn)橐话愣紩?huì)對(duì)大流量的秒殺系統(tǒng)做系統(tǒng)的靜態(tài)化改造，即數(shù)據(jù)意義上的動(dòng)靜分離。

動(dòng)靜分離三步走：

數(shù)據(jù)拆分

靜態(tài)緩存

數(shù)據(jù)整合

①數(shù)據(jù)拆分

動(dòng)靜分離的首要目的是將動(dòng)態(tài)頁(yè)面改造成適合緩存的靜態(tài)頁(yè)面。因此第一步就是分離出動(dòng)態(tài)數(shù)據(jù)，主要從以下 2 個(gè)方面進(jìn)行：

用戶(hù)。

用戶(hù)身份信息包括登錄狀態(tài)以及登錄畫(huà)像等，相關(guān)要素可以單獨(dú)拆分出來(lái)，通過(guò)動(dòng)態(tài)請(qǐng)求進(jìn)行獲??；與之相關(guān)的廣平推薦，如用戶(hù)偏好、地域偏好等，同樣可以通過(guò)異步方式進(jìn)行加載。

時(shí)間。

秒殺時(shí)間是由服務(wù)端統(tǒng)一管控的，可以通過(guò)動(dòng)態(tài)請(qǐng)求進(jìn)行獲取。

這里你可以打開(kāi)電商平臺(tái)的一個(gè)秒殺頁(yè)面，看看這個(gè)頁(yè)面里都有哪些動(dòng)靜數(shù)據(jù)。

②靜態(tài)緩存

分離出動(dòng)靜態(tài)數(shù)據(jù)之后，第二步就是將靜態(tài)數(shù)據(jù)進(jìn)行合理的緩存，由此衍生出兩個(gè)問(wèn)題：

怎么緩存

哪里緩存

怎么緩存：

靜態(tài)化改造的一個(gè)特點(diǎn)是直接緩存整個(gè) HTTP 連接而不是僅僅緩存靜態(tài)數(shù)據(jù)。

如此一來(lái)，Web 代理服務(wù)器根據(jù)請(qǐng)求 URL，可以直接取出對(duì)應(yīng)的響應(yīng)體然后直接返回，響應(yīng)過(guò)程無(wú)需重組 HTTP 協(xié)議，也無(wú)需解析 HTTP 請(qǐng)求頭。

而作為緩存鍵，URL 唯一化是必不可少的，只是對(duì)于商品系統(tǒng)，URL 天然是可以基于商品 ID 來(lái)進(jìn)行唯一標(biāo)識(shí)的，比如淘寶的：

https://item.taobao.com/item.htm?id=xxxx

哪里緩存：

靜態(tài)數(shù)據(jù)緩存到哪里呢？

可以有三種方式：

瀏覽器

CDN

服務(wù)端

瀏覽器當(dāng)然是第一選擇，但用戶(hù)的瀏覽器是不可控的，主要體現(xiàn)在如果用戶(hù)不主動(dòng)刷新，系統(tǒng)很難主動(dòng)地把消息推送給用戶(hù)（注意，當(dāng)討論靜態(tài)數(shù)據(jù)時(shí)，潛臺(tái)詞是 “相對(duì)不變”，言外之意是 “可能會(huì)變”）。

如此可能會(huì)導(dǎo)致用戶(hù)端在很長(zhǎng)一段時(shí)間內(nèi)看到的信息都是錯(cuò)誤的。對(duì)于秒殺系統(tǒng)，保證緩存可以在秒級(jí)時(shí)間內(nèi)失效是不可或缺的。

服務(wù)端主要進(jìn)行動(dòng)態(tài)邏輯計(jì)算及加載，本身并不擅長(zhǎng)處理大量連接，每個(gè)連接消耗內(nèi)存較多，同時(shí) Servlet 容器解析 HTTP 較慢，容易侵占邏輯計(jì)算資源；另外，靜態(tài)數(shù)據(jù)下沉至此也會(huì)拉長(zhǎng)請(qǐng)求路徑。

因此通常將靜態(tài)數(shù)據(jù)緩存在 CDN，其本身更擅長(zhǎng)處理大并發(fā)的靜態(tài)文件請(qǐng)求，既可以做到主動(dòng)失效，又離用戶(hù)盡可能近，同時(shí)規(guī)避 JAVA 語(yǔ)言層面的弱點(diǎn)。

需要注意的是，上 CDN 有以下幾個(gè)問(wèn)題需要解決：

失效問(wèn)題。

任何一個(gè)緩存都應(yīng)該是有時(shí)效的，尤其對(duì)于一個(gè)秒殺場(chǎng)景。所以，系統(tǒng)需要保證全國(guó)各地的 CDN 在秒級(jí)時(shí)間內(nèi)失效掉緩存信息，這實(shí)際對(duì) CDN 的失效系統(tǒng)要求是很高的。

命中率問(wèn)題。

高命中是緩存系統(tǒng)最為核心的性能要求，不然緩存就失去了意義。如果將數(shù)據(jù)放到全國(guó)各地的 CDN ，勢(shì)必會(huì)導(dǎo)致請(qǐng)求命中同一個(gè)緩存的可能性降低，那么命中率就成為一個(gè)問(wèn)題。

因此，將數(shù)據(jù)放到全國(guó)所有的 CDN 節(jié)點(diǎn)是不太現(xiàn)實(shí)的，失效問(wèn)題、命中率問(wèn)題都會(huì)面臨比較大的挑戰(zhàn)。

更為可行的做法是選擇若干 CDN 節(jié)點(diǎn)進(jìn)行靜態(tài)化改造，節(jié)點(diǎn)的選取通常需要滿(mǎn)足以下幾個(gè)條件：

臨近訪問(wèn)量集中的地區(qū)

距離主站較遠(yuǎn)的地區(qū)

節(jié)點(diǎn)與主站間網(wǎng)絡(luò)質(zhì)量良好的地區(qū)

基于以上因素，選擇 CDN 的二級(jí)緩存比較合適，因?yàn)槎?jí)緩存數(shù)量偏少，容量也更大，訪問(wèn)量相對(duì)集中。

這樣就可以較好解決緩存的失效問(wèn)題以及命中率問(wèn)題，是當(dāng)前比較理想的一種 CDN 化方案。

部署方式如下圖所示：

③數(shù)據(jù)整合

分離出動(dòng)靜態(tài)數(shù)據(jù)之后，前端如何組織數(shù)據(jù)頁(yè)就是一個(gè)新的問(wèn)題，主要在于動(dòng)態(tài)數(shù)據(jù)的加載處理，通常有兩種方案：

ESI 方案：

Web 代理服務(wù)器上請(qǐng)求動(dòng)態(tài)數(shù)據(jù)，并將動(dòng)態(tài)數(shù)據(jù)插入到靜態(tài)頁(yè)面中，用戶(hù)看到頁(yè)面時(shí)已經(jīng)是一個(gè)完整的頁(yè)面。這種方式對(duì)服務(wù)端性能要求高，但用戶(hù)體驗(yàn)較好。

CSI 方案：

Web 代理服務(wù)器上只返回靜態(tài)頁(yè)面，前端單獨(dú)發(fā)起一個(gè)異步 JS 請(qǐng)求動(dòng)態(tài)數(shù)據(jù)。這種方式對(duì)服務(wù)端性能友好，但用戶(hù)體驗(yàn)稍差。

小結(jié)：

動(dòng)靜分離對(duì)于性能的提升，抽象起來(lái)只有兩點(diǎn)，一是數(shù)據(jù)要盡量少，以便減少?zèng)]必要的請(qǐng)求；二是路徑要盡量短，以便提高單次請(qǐng)求的效率。具體方法其實(shí)就是基于這個(gè)大方向進(jìn)行的。

熱點(diǎn)優(yōu)化

熱點(diǎn)分為熱點(diǎn)操作和熱點(diǎn)數(shù)據(jù)，以下分開(kāi)進(jìn)行討論。

①熱點(diǎn)操作

零點(diǎn)刷新、零點(diǎn)下單、零點(diǎn)添加購(gòu)物車(chē)等都屬于熱點(diǎn)操作。熱點(diǎn)操作是用戶(hù)的行為，不好改變，但可以做一些限制保護(hù)，比如用戶(hù)頻繁刷新頁(yè)面時(shí)進(jìn)行提示阻斷。

②熱點(diǎn)數(shù)據(jù)

熱點(diǎn)數(shù)據(jù)的處理分三步走，一是熱點(diǎn)識(shí)別，二是熱點(diǎn)隔離，三是熱點(diǎn)優(yōu)化。

熱點(diǎn)識(shí)別：

熱點(diǎn)數(shù)據(jù)分為靜態(tài)熱點(diǎn)和動(dòng)態(tài)熱點(diǎn)。

具體如下：

靜態(tài)熱點(diǎn)：

能夠提前預(yù)測(cè)的熱點(diǎn)數(shù)據(jù)。大促前夕，可以根據(jù)大促的行業(yè)特點(diǎn)、活動(dòng)商家等緯度信息分析出熱點(diǎn)商品，或者通過(guò)賣(mài)家報(bào)名的方式提前篩選。另外，還可以通過(guò)技術(shù)手段提前預(yù)測(cè)，例如對(duì)買(mǎi)家每天訪問(wèn)的商品進(jìn)行大數(shù)據(jù)計(jì)算，然后統(tǒng)計(jì)出 TOP N 的商品，即可視為熱點(diǎn)商品

動(dòng)態(tài)熱點(diǎn)：

無(wú)法提前預(yù)測(cè)的熱點(diǎn)數(shù)據(jù)。冷熱數(shù)據(jù)往往是隨實(shí)際業(yè)務(wù)場(chǎng)景發(fā)生交替變化的，尤其是如今直播賣(mài)貨模式的興起——帶貨商臨時(shí)做一個(gè)廣告，就有可能導(dǎo)致一件商品在短時(shí)間內(nèi)被大量購(gòu)買(mǎi)。由于此類(lèi)商品日常訪問(wèn)較少，即使在緩存系統(tǒng)中一段時(shí)間后也會(huì)被逐出或過(guò)期掉，甚至在 DB 中也是冷數(shù)據(jù)。瞬時(shí)流量的涌入，往往導(dǎo)致緩存被擊穿，請(qǐng)求直接到達(dá) DB，引發(fā) D B壓力過(guò)大。

因此秒殺系統(tǒng)需要實(shí)現(xiàn)熱點(diǎn)數(shù)據(jù)的動(dòng)態(tài)發(fā)現(xiàn)能力，一個(gè)常見(jiàn)的實(shí)現(xiàn)思路是：

異步采集交易鏈路各個(gè)環(huán)節(jié)的熱點(diǎn) Key 信息，如 Nginx 采集訪問(wèn) URL 或 Agent 采集熱點(diǎn)日志（一些中間件本身已具備熱點(diǎn)發(fā)現(xiàn)能力），提前識(shí)別潛在的熱點(diǎn)數(shù)據(jù)。聚合分析熱點(diǎn)數(shù)據(jù)，達(dá)到一定規(guī)則的熱點(diǎn)數(shù)據(jù)，通過(guò)訂閱分發(fā)推送到鏈路系統(tǒng)，各系統(tǒng)根據(jù)自身需求決定如何處理熱點(diǎn)數(shù)據(jù)，或限流或緩存，從而實(shí)現(xiàn)熱點(diǎn)保護(hù)。

需要注意的是：

熱點(diǎn)數(shù)據(jù)采集最好采用異步方式，一方面不會(huì)影響業(yè)務(wù)的核心交易鏈路，一方面可以保證采集方式的通用性。熱點(diǎn)發(fā)現(xiàn)最好做到秒級(jí)實(shí)時(shí)，這樣動(dòng)態(tài)發(fā)現(xiàn)才有意義，實(shí)際上也是對(duì)核心節(jié)點(diǎn)的數(shù)據(jù)采集和分析能力提出了較高的要求。

熱點(diǎn)隔離：

熱點(diǎn)數(shù)據(jù)識(shí)別出來(lái)之后，第一原則就是將熱點(diǎn)數(shù)據(jù)隔離出來(lái)，不要讓 1% 影響到另外的 99%。

可以基于以下幾個(gè)層次實(shí)現(xiàn)熱點(diǎn)隔離：

業(yè)務(wù)隔離。

秒殺作為一種營(yíng)銷(xiāo)活動(dòng)，賣(mài)家需要單獨(dú)報(bào)名，從技術(shù)上來(lái)說(shuō)，系統(tǒng)可以提前對(duì)已知熱點(diǎn)做緩存預(yù)熱。

系統(tǒng)隔離。

系統(tǒng)隔離是運(yùn)行時(shí)隔離，通過(guò)分組部署和另外 99% 進(jìn)行分離，另外秒殺也可以申請(qǐng)單獨(dú)的域名，入口層就讓請(qǐng)求落到不同的集群中。

數(shù)據(jù)隔離。

秒殺數(shù)據(jù)作為熱點(diǎn)數(shù)據(jù)，可以啟用單獨(dú)的緩存集群或者 DB 服務(wù)組，從而更好的實(shí)現(xiàn)橫向或縱向能力擴(kuò)展。

當(dāng)然，實(shí)現(xiàn)隔離還有很多種辦法。比如，可以按照用戶(hù)來(lái)區(qū)分，為不同的用戶(hù)分配不同的 Cookie，入口層路由到不同的服務(wù)接口中。

再比如，域名保持一致，但后端調(diào)用不同的服務(wù)接口；又或者在數(shù)據(jù)層給數(shù)據(jù)打標(biāo)進(jìn)行區(qū)分等等，這些措施的目的都是把已經(jīng)識(shí)別的熱點(diǎn)請(qǐng)求和普通請(qǐng)求區(qū)分開(kāi)來(lái)。

熱點(diǎn)優(yōu)化：

熱點(diǎn)數(shù)據(jù)隔離之后，也就方便對(duì)這 1% 的請(qǐng)求做針對(duì)性的優(yōu)化。

方式無(wú)外乎兩種：

緩存：

熱點(diǎn)緩存是最為有效的辦法。如果熱點(diǎn)數(shù)據(jù)做了動(dòng)靜分離，那么可以長(zhǎng)期緩存靜態(tài)數(shù)據(jù)。

限流：

流量限制更多是一種保護(hù)機(jī)制。需要注意的是，各服務(wù)要時(shí)刻關(guān)注請(qǐng)求是否觸發(fā)限流并及時(shí)進(jìn)行 Review。

小結(jié)：

數(shù)據(jù)的熱點(diǎn)優(yōu)化與動(dòng)靜分離是不一樣的，熱點(diǎn)優(yōu)化是基于二八原則對(duì)數(shù)據(jù)進(jìn)行了縱向拆分，以便進(jìn)行針對(duì)性地處理。

熱點(diǎn)識(shí)別和隔離不僅對(duì)“秒殺”這個(gè)場(chǎng)景有意義，對(duì)其他的高性能分布式系統(tǒng)也非常有參考價(jià)值。

系統(tǒng)優(yōu)化

對(duì)于一個(gè)軟件系統(tǒng)，提高性能可以有很多種手段，如提升硬件水平、調(diào)優(yōu) JVM 性能，這里主要關(guān)注代碼層面的性能優(yōu)化。

①減少序列化：

減少 Java 中的序列化操作可以很好的提升系統(tǒng)性能。序列化大部分是在 RPC 階段發(fā)生，因此應(yīng)該盡量減少 RPC 調(diào)用。

一種可行的方案是將多個(gè)關(guān)聯(lián)性較強(qiáng)的應(yīng)用進(jìn)行 “合并部署”，從而減少不同應(yīng)用之間的 RPC 調(diào)用（微服務(wù)設(shè)計(jì)規(guī)范）。

②直接輸出流數(shù)據(jù)：

只要涉及字符串的 I/O 操作，無(wú)論是磁盤(pán) I/O 還是網(wǎng)絡(luò) I/O，都比較耗費(fèi) CPU 資源，因?yàn)樽址枰D(zhuǎn)換成字節(jié)，而這個(gè)轉(zhuǎn)換又必須查表編碼。

所以對(duì)于常用數(shù)據(jù)，比如靜態(tài)字符串，推薦提前編碼成字節(jié)并緩存，具體到代碼層面就是通過(guò) OutputStream() 類(lèi)函數(shù)從而減少數(shù)據(jù)的編碼轉(zhuǎn)換。

另外，熱點(diǎn)方法 toString() 不要直接調(diào)用 ReflectionToString 實(shí)現(xiàn)，推薦直接硬編碼，并且只打印 DO 的基礎(chǔ)要素和核心要素。

裁剪日志異常堆棧：

無(wú)論是外部系統(tǒng)異常還是應(yīng)用本身異常，都會(huì)有堆棧打出，超大流量下，頻繁的輸出完整堆棧，只會(huì)加劇系統(tǒng)當(dāng)前負(fù)載。可以通過(guò)日志配置文件控制異常堆棧輸出的深度。

去組件框架：

極致優(yōu)化要求下，可以去掉一些組件框架，比如去掉傳統(tǒng)的 MVC 框架，直接使用 Servlet 處理請(qǐng)求。

這樣可以繞過(guò)一大堆復(fù)雜且用處不大的處理邏輯，節(jié)省毫秒級(jí)的時(shí)間，當(dāng)然，需要合理評(píng)估你對(duì)框架的依賴(lài)程度。

總結(jié)一下

性能優(yōu)化需要一個(gè)基準(zhǔn)值，所以系統(tǒng)還需要做好應(yīng)用基線，比如性能基線（何時(shí)性能突然下降）、成本基線（去年大促用了多少機(jī)器）、鏈路基線（核心流程發(fā)生了哪些變化）。

通過(guò)基線持續(xù)關(guān)注系統(tǒng)性能，促使系統(tǒng)在代碼層面持續(xù)提升編碼質(zhì)量、業(yè)務(wù)層面及時(shí)下掉不合理調(diào)用、架構(gòu)層面不斷優(yōu)化改進(jìn)。

一致性

秒殺系統(tǒng)中，庫(kù)存是個(gè)關(guān)鍵數(shù)據(jù)，賣(mài)不出去是個(gè)問(wèn)題，超賣(mài)更是個(gè)問(wèn)題。秒殺場(chǎng)景下的一致性問(wèn)題，主要就是庫(kù)存扣減的準(zhǔn)確性問(wèn)題。

減庫(kù)存的方式

電商場(chǎng)景下的購(gòu)買(mǎi)過(guò)程一般分為兩步：下單和付款?！疤峤挥唵巍奔礊橄聠危爸Ц队唵巍奔礊楦犊?。

基于此設(shè)定，減庫(kù)存一般有以下幾個(gè)方式：

下單減庫(kù)存。

買(mǎi)家下單后，扣減商品庫(kù)存。下單減庫(kù)存是最簡(jiǎn)單的減庫(kù)存方式，也是控制最為精確的一種。

付款減庫(kù)存。

買(mǎi)家下單后，并不立即扣減庫(kù)存，而是等到付款后才真正扣減庫(kù)存。但因?yàn)楦犊顣r(shí)才減庫(kù)存，如果并發(fā)比較高，可能出現(xiàn)買(mǎi)家下單后付不了款的情況，因?yàn)樯唐芬呀?jīng)被其他人買(mǎi)走了。

預(yù)扣庫(kù)存。

這種方式相對(duì)復(fù)雜一些，買(mǎi)家下單后，庫(kù)存為其保留一定的時(shí)間（如 15 分鐘），超過(guò)這段時(shí)間，庫(kù)存自動(dòng)釋放，釋放后其他買(mǎi)家可以購(gòu)買(mǎi)。

能夠看到，減庫(kù)存方式是基于購(gòu)物過(guò)程的多階段進(jìn)行劃分的，但無(wú)論是在下單階段還是付款階段，都會(huì)存在一些問(wèn)題，下面進(jìn)行具體分析。

減庫(kù)存的問(wèn)題

①下單減庫(kù)存

優(yōu)勢(shì)：

用戶(hù)體驗(yàn)最好。下單減庫(kù)存是最簡(jiǎn)單的減庫(kù)存方式，也是控制最精確的一種。

下單時(shí)可以直接通過(guò)數(shù)據(jù)庫(kù)事務(wù)機(jī)制控制商品庫(kù)存，所以一定不會(huì)出現(xiàn)已下單卻付不了款的情況。

劣勢(shì)：

可能賣(mài)不出去。正常情況下，買(mǎi)家下單后付款概率很高，所以不會(huì)有太大問(wèn)題。

但有一種場(chǎng)景例外，就是當(dāng)賣(mài)家參加某個(gè)促銷(xiāo)活動(dòng)時(shí)，競(jìng)爭(zhēng)對(duì)手通過(guò)惡意下單的方式將該商品全部下單，導(dǎo)致庫(kù)存清零，那么這就不能正常售賣(mài)了——要知道，惡意下單的人是不會(huì)真正付款的，這正是 “下單減庫(kù)存” 的不足之處。

②付款減庫(kù)存

優(yōu)勢(shì)：

一定實(shí)際售賣(mài)?！跋聠螠p庫(kù)存” 可能導(dǎo)致惡意下單，從而影響賣(mài)家的商品銷(xiāo)售， “付款減庫(kù)存” 由于需要付出真金白銀，可以有效避免。

劣勢(shì)：

用戶(hù)體驗(yàn)較差。用戶(hù)下單后，不一定會(huì)實(shí)際付款，假設(shè)有 100 件商品，就可能出現(xiàn) 200 人下單成功的情況。

因?yàn)橄聠螘r(shí)不會(huì)減庫(kù)存，所以也就可能出現(xiàn)下單成功數(shù)遠(yuǎn)遠(yuǎn)超過(guò)真正庫(kù)存數(shù)的情況，這尤其會(huì)發(fā)生在大促的熱門(mén)商品上。

如此一來(lái)就會(huì)導(dǎo)致很多買(mǎi)家下單成功后卻付不了款，購(gòu)物體驗(yàn)自然是比較差的。

③預(yù)扣庫(kù)存

優(yōu)勢(shì)：

緩解了以上兩種方式的問(wèn)題。預(yù)扣庫(kù)存實(shí)際就是“下單減庫(kù)存”和 “付款減庫(kù)存”兩種方式的結(jié)合，將兩次操作進(jìn)行了前后關(guān)聯(lián)，下單時(shí)預(yù)扣庫(kù)存，付款時(shí)釋放庫(kù)存。

劣勢(shì)：

并沒(méi)有徹底解決以上問(wèn)題。比如針對(duì)惡意下單的場(chǎng)景，雖然可以把有效付款時(shí)間設(shè)置為 10 分鐘，但惡意買(mǎi)家完全可以在 10 分鐘之后再次下單。

小結(jié)：

減庫(kù)存的問(wèn)題主要體現(xiàn)在用戶(hù)體驗(yàn)和商業(yè)訴求兩方面，其本質(zhì)原因在于購(gòu)物過(guò)程存在兩步甚至多步操作，在不同階段減庫(kù)存，容易存在被惡意利用的漏洞。

實(shí)際如何減庫(kù)存

業(yè)界最為常見(jiàn)的是預(yù)扣庫(kù)存。無(wú)論是外賣(mài)點(diǎn)餐還是電商購(gòu)物，下單后一般都有個(gè) “有效付款時(shí)間”，超過(guò)該時(shí)間訂單自動(dòng)釋放，這就是典型的預(yù)扣庫(kù)存方案。

但如上所述，預(yù)扣庫(kù)存還需要解決惡意下單的問(wèn)題，保證商品賣(mài)的出去；另一方面，如何避免超賣(mài)，也是一個(gè)痛點(diǎn)。

賣(mài)的出去：

惡意下單的解決方案主要還是結(jié)合安全和反作弊措施來(lái)制止。比如，識(shí)別頻繁下單不付款的買(mǎi)家并進(jìn)行打標(biāo)，這樣可以在打標(biāo)買(mǎi)家下單時(shí)不減庫(kù)存。

再比如為大促商品設(shè)置單人最大購(gòu)買(mǎi)件數(shù)，一人最多只能買(mǎi) N 件商品；又或者對(duì)重復(fù)下單不付款的行為進(jìn)行次數(shù)限制阻斷等。

避免超賣(mài)：

庫(kù)存超賣(mài)的情況實(shí)際分為兩種。對(duì)于普通商品，秒殺只是一種大促手段，即使庫(kù)存超賣(mài)，商家也可以通過(guò)補(bǔ)貨來(lái)解決。

而對(duì)于一些商品，秒殺作為一種營(yíng)銷(xiāo)手段，完全不允許庫(kù)存為負(fù)，也就是在數(shù)據(jù)一致性上，需要保證大并發(fā)請(qǐng)求時(shí)數(shù)據(jù)庫(kù)中的庫(kù)存字段值不能為負(fù)。

一般有多種方案：

一是通過(guò)事務(wù)來(lái)判斷，即保證減后庫(kù)存不能為負(fù)，否則就回滾。二是直接設(shè)置數(shù)據(jù)庫(kù)字段類(lèi)型為無(wú)符號(hào)整數(shù)，這樣一旦庫(kù)存為負(fù)就會(huì)在執(zhí)行 SQL 時(shí)報(bào)錯(cuò)。三是使用 CASE WHEN 判斷語(yǔ)句。

UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END

業(yè)務(wù)手段保證商品賣(mài)的出去，技術(shù)手段保證商品不會(huì)超賣(mài)，庫(kù)存問(wèn)題從來(lái)就不是簡(jiǎn)單的技術(shù)難題，解決問(wèn)題的視角是多種多樣的。

一致性性能的優(yōu)化

庫(kù)存是個(gè)關(guān)鍵數(shù)據(jù)，更是個(gè)熱點(diǎn)數(shù)據(jù)。對(duì)系統(tǒng)來(lái)說(shuō)，熱點(diǎn)的實(shí)際影響就是 “高讀” 和 “高寫(xiě)”，也是秒殺場(chǎng)景下最為核心的一個(gè)技術(shù)難題。

①高并發(fā)讀

秒殺場(chǎng)景解決高并發(fā)讀問(wèn)題，關(guān)鍵詞是“分層校驗(yàn)”。即在讀鏈路時(shí)，只進(jìn)行不影響性能的檢查操作。

如用戶(hù)是否具有秒殺資格、商品狀態(tài)是否正常、用戶(hù)答題是否正確、秒殺是否已經(jīng)結(jié)束、是否非法請(qǐng)求等，而不做一致性校驗(yàn)等容易引發(fā)瓶頸的檢查操作；直到寫(xiě)鏈路時(shí)，才對(duì)庫(kù)存做一致性檢查，在數(shù)據(jù)層保證最終準(zhǔn)確性。

因此，在分層校驗(yàn)設(shè)定下，系統(tǒng)可以采用分布式緩存甚至LocalCache來(lái)抵抗高并發(fā)讀。

即允許讀場(chǎng)景下一定的臟數(shù)據(jù)，這樣只會(huì)導(dǎo)致少量原本無(wú)庫(kù)存的下單請(qǐng)求被誤認(rèn)為是有庫(kù)存的，等到真正寫(xiě)數(shù)據(jù)時(shí)再保證最終一致性，由此做到高可用和一致性之間的平衡。

實(shí)際上，分層校驗(yàn)的核心思想是：

不同層次盡可能過(guò)濾掉無(wú)效請(qǐng)求，只在“漏斗” 最末端進(jìn)行有效處理，從而縮短系統(tǒng)瓶頸的影響路徑。

②高并發(fā)寫(xiě)

高并發(fā)寫(xiě)的優(yōu)化方式，一種是更換 DB 選型，一種是優(yōu)化 DB 性能，以下分別進(jìn)行討論。

更換 DB 選型：

秒殺商品和普通商品的減庫(kù)存是有差異的，核心區(qū)別在數(shù)據(jù)量級(jí)小、交易時(shí)間短。

因此能否把秒殺減庫(kù)存直接放到緩存系統(tǒng)中實(shí)現(xiàn)呢，也就是直接在一個(gè)帶有持久化功能的緩存中進(jìn)行減庫(kù)存操作，比如 redis？

如果減庫(kù)存邏輯非常單一的話，比如沒(méi)有復(fù)雜的 SKU 庫(kù)存和總庫(kù)存這種聯(lián)動(dòng)關(guān)系的話，個(gè)人認(rèn)為是完全可以的。

但如果有比較復(fù)雜的減庫(kù)存邏輯，或者需要使用到事務(wù)，那就必須在數(shù)據(jù)庫(kù)中完成減庫(kù)存操作。

優(yōu)化 DB 性能：

庫(kù)存數(shù)據(jù)落地到數(shù)據(jù)庫(kù)實(shí)現(xiàn)其實(shí)是一行存儲(chǔ)（MySQL），因此會(huì)有大量線程來(lái)競(jìng)爭(zhēng) InnoDB 行鎖。

但并發(fā)越高，等待線程就會(huì)越多，TPS 下降，RT 上升，吞吐量會(huì)受到嚴(yán)重影響。注意，這里假設(shè)數(shù)據(jù)庫(kù)已基于上文【性能優(yōu)化】完成數(shù)據(jù)隔離，以便于討論聚焦 。

解決并發(fā)鎖的問(wèn)題，有兩種辦法：

應(yīng)用層排隊(duì)。

通過(guò)緩存加入集群分布式鎖，從而控制集群對(duì)數(shù)據(jù)庫(kù)同一行記錄進(jìn)行操作的并發(fā)度，同時(shí)也能控制單個(gè)商品占用數(shù)據(jù)庫(kù)連接的數(shù)量，防止熱點(diǎn)商品占用過(guò)多的數(shù)據(jù)庫(kù)連接。

數(shù)據(jù)層排隊(duì)。

應(yīng)用層排隊(duì)是有損性能的，數(shù)據(jù)層排隊(duì)是最為理想的。業(yè)界中，阿里的數(shù)據(jù)庫(kù)團(tuán)隊(duì)開(kāi)發(fā)了針對(duì) InnoDB 層上的補(bǔ)丁程序（patch），可以基于 DB 層對(duì)單行記錄做并發(fā)排隊(duì)，從而實(shí)現(xiàn)秒殺場(chǎng)景下的定制優(yōu)化。注意，排隊(duì)和鎖競(jìng)爭(zhēng)是有區(qū)別的，如果熟悉 MySQL 的話，就會(huì)知道 InnoDB 內(nèi)部的死鎖檢測(cè)，以及 MySQL Server 和 InnoDB 的切換都是比較消耗性能的。另外阿里的數(shù)據(jù)庫(kù)團(tuán)隊(duì)還做了很多其他方面的優(yōu)化，如 COMMIT_ON_SUCCESS 和 ROLLBACK_ON_FAIL 的補(bǔ)丁程序，通過(guò)在 SQL 里加入提示（hint），實(shí)現(xiàn)事務(wù)不需要等待實(shí)時(shí)提交，而是在數(shù)據(jù)執(zhí)行完最后一條 SQL 后，直接根據(jù) TARGET_AFFECT_ROW 的結(jié)果進(jìn)行提交或回滾，減少網(wǎng)絡(luò)等待的時(shí)間（毫秒級(jí)）。目前阿里已將包含這些補(bǔ)丁程序的 MySQL 開(kāi)源：AliSQL

https://github.com/alibaba/AliSQL?spm=a2c4e.10696291.0.0.34ba19a415Ghm4

小結(jié)：

高讀和高寫(xiě)的兩種處理方式大相徑庭。讀請(qǐng)求的優(yōu)化空間要大一些，而寫(xiě)請(qǐng)求的瓶頸一般都在存儲(chǔ)層，優(yōu)化思路的本質(zhì)還是基于 CAP 理論做平衡。

總結(jié)一下

當(dāng)然，減庫(kù)存還有很多細(xì)節(jié)問(wèn)題，例如預(yù)扣的庫(kù)存超時(shí)后如何進(jìn)行回補(bǔ)，再比如第三方支付如何保證減庫(kù)存和付款時(shí)的狀態(tài)一致性，這些也是很大的挑戰(zhàn)。

高可用

盯過(guò)秒殺流量監(jiān)控的話，會(huì)發(fā)現(xiàn)它不是一條蜿蜒而起的曲線，而是一條挺拔的直線，這是因?yàn)槊霘⒄?qǐng)求高度集中于某一特定的時(shí)間點(diǎn)。

這樣一來(lái)就會(huì)造成一個(gè)特別高的零點(diǎn)峰值，而對(duì)資源的消耗也幾乎是瞬時(shí)的。所以秒殺系統(tǒng)的可用性保護(hù)是不可或缺的。

流量削峰

對(duì)于秒殺的目標(biāo)場(chǎng)景，最終能夠搶到商品的人數(shù)是固定的，無(wú)論 100 人和 10000 人參加結(jié)果都是一樣的，即有效請(qǐng)求額度是有限的。并發(fā)度越高，無(wú)效請(qǐng)求也就越多。

但秒殺作為一種商業(yè)營(yíng)銷(xiāo)手段，活動(dòng)開(kāi)始之前是希望有更多的人來(lái)刷頁(yè)面，只是真正開(kāi)始后，秒殺請(qǐng)求不是越多越好。

因此系統(tǒng)可以設(shè)計(jì)一些規(guī)則，人為的延緩秒殺請(qǐng)求，甚至可以過(guò)濾掉一些無(wú)效請(qǐng)求。

①答題

早期秒殺只是簡(jiǎn)單的點(diǎn)擊秒殺按鈕，后來(lái)才增加了答題。為什么要增加答題呢？

主要是通過(guò)提升購(gòu)買(mǎi)的復(fù)雜度，達(dá)到兩個(gè)目的：

防止作弊。

早期秒殺器比較猖獗，存在惡意買(mǎi)家或競(jìng)爭(zhēng)對(duì)手使用秒殺器掃貨的情況，商家沒(méi)有達(dá)到營(yíng)銷(xiāo)的目的，所以增加答題來(lái)進(jìn)行限制。

延緩請(qǐng)求。

零點(diǎn)流量的起效時(shí)間是毫秒級(jí)的，答題可以人為拉長(zhǎng)峰值下單的時(shí)長(zhǎng)，由之前的 <1s 延長(zhǎng)到 <10s。這個(gè)時(shí)間對(duì)于服務(wù)端非常重要，會(huì)大大減輕高峰期并發(fā)壓力；另外，由于請(qǐng)求具有先后順序，答題后置的請(qǐng)求到來(lái)時(shí)可能已經(jīng)沒(méi)有庫(kù)存了，因此根本無(wú)法下單，此階段落到數(shù)據(jù)層真正的寫(xiě)也就非常有限了。

需要注意的是，答題除了做正確性驗(yàn)證，還需要對(duì)提交時(shí)間做驗(yàn)證，比如<1s 人為操作的可能性就很小，可以進(jìn)一步防止機(jī)器答題的情況。

答題目前已經(jīng)使用的非常普遍了，本質(zhì)是通過(guò)在入口層削減流量，從而讓系統(tǒng)更好地支撐瞬時(shí)峰值。

②排隊(duì)

最為常見(jiàn)的削峰方案是使用消息隊(duì)列，通過(guò)把同步的直接調(diào)用轉(zhuǎn)換成異步的間接推送緩沖瞬時(shí)流量。

除了消息隊(duì)列，類(lèi)似的排隊(duì)方案還有很多，例如：

線程池加鎖等待

本地內(nèi)存蓄洪等待

本地文件序列化寫(xiě)，再順序讀

排隊(duì)方式的弊端也是顯而易見(jiàn)的，主要有兩點(diǎn)：

請(qǐng)求積壓。

流量高峰如果長(zhǎng)時(shí)間持續(xù)，達(dá)到了隊(duì)列的水位上限，隊(duì)列同樣會(huì)被壓垮，這樣雖然保護(hù)了下游系統(tǒng)，但是和請(qǐng)求直接丟棄也沒(méi)多大區(qū)別。

用戶(hù)體驗(yàn)。

異步推送的實(shí)時(shí)性和有序性自然是比不上同步調(diào)用的，由此可能出現(xiàn)請(qǐng)求先發(fā)后至的情況，影響部分敏感用戶(hù)的購(gòu)物體驗(yàn)。

排隊(duì)本質(zhì)是在業(yè)務(wù)層將一步操作轉(zhuǎn)變成兩步操作，從而起到緩沖的作用，但鑒于此種方式的弊端，最終還是要基于業(yè)務(wù)量級(jí)和秒殺場(chǎng)景做出妥協(xié)和平衡。

③過(guò)濾

過(guò)濾的核心結(jié)構(gòu)在于分層，通過(guò)在不同層次過(guò)濾掉無(wú)效請(qǐng)求，達(dá)到數(shù)據(jù)讀寫(xiě)的精準(zhǔn)觸發(fā)。

常見(jiàn)的過(guò)濾主要有以下幾層：

讀限流：

對(duì)讀請(qǐng)求做限流保護(hù)，將超出系統(tǒng)承載能力的請(qǐng)求過(guò)濾掉。

讀緩存：

對(duì)讀請(qǐng)求做數(shù)據(jù)緩存，將重復(fù)的請(qǐng)求過(guò)濾掉。

寫(xiě)限流：

對(duì)寫(xiě)請(qǐng)求做限流保護(hù)，將超出系統(tǒng)承載能力的請(qǐng)求過(guò)濾掉。

寫(xiě)校驗(yàn)：

對(duì)寫(xiě)請(qǐng)求做一致性校驗(yàn)，只保留最終的有效數(shù)據(jù)。

過(guò)濾的核心目的是通過(guò)減少無(wú)效請(qǐng)求的數(shù)據(jù) IO 保障有效請(qǐng)求的 IO 性能。

小結(jié)：

系統(tǒng)可以通過(guò)入口層的答題、業(yè)務(wù)層的排隊(duì)、數(shù)據(jù)層的過(guò)濾達(dá)到流量削峰的目的，本質(zhì)是在尋求商業(yè)訴求與架構(gòu)性能之間的平衡。

另外，新的削峰手段也層出不窮，以業(yè)務(wù)切入居多，比如零點(diǎn)大促時(shí)同步發(fā)放優(yōu)惠券或發(fā)起抽獎(jiǎng)活動(dòng)，將一部分流量分散到其他系統(tǒng)，這樣也能起到削峰的作用。

Plan B

當(dāng)一個(gè)系統(tǒng)面臨持續(xù)的高峰流量時(shí)，其實(shí)是很難單靠自身調(diào)整來(lái)恢復(fù)狀態(tài)的，日常運(yùn)維沒(méi)有人能夠預(yù)估所有情況，意外總是無(wú)法避免。

尤其在秒殺這一場(chǎng)景下，為了保證系統(tǒng)的高可用，必須設(shè)計(jì)一個(gè) Plan B 方案來(lái)進(jìn)行兜底。

高可用建設(shè)，其實(shí)是一個(gè)系統(tǒng)工程，貫穿在系統(tǒng)建設(shè)的整個(gè)生命周期。

具體來(lái)說(shuō)，系統(tǒng)的高可用建設(shè)涉及架構(gòu)階段、編碼階段、測(cè)試階段、發(fā)布階段、運(yùn)行階段，以及故障發(fā)生時(shí)，逐一進(jìn)行分析：

架構(gòu)階段：

考慮系統(tǒng)的可擴(kuò)展性和容錯(cuò)性，避免出現(xiàn)單點(diǎn)問(wèn)題。例如多地單元化部署，即使某個(gè) IDC 甚至地市出現(xiàn)故障，仍不會(huì)影響系統(tǒng)運(yùn)轉(zhuǎn)。

編碼階段：

保證代碼的健壯性，例如 RPC 調(diào)用時(shí)，設(shè)置合理的超時(shí)退出機(jī)制，防止被其他系統(tǒng)拖垮，同時(shí)也要對(duì)無(wú)法預(yù)料的返回錯(cuò)誤進(jìn)行默認(rèn)的處理。

測(cè)試階段：

保證 CI 的覆蓋度以及 Sonar 的容錯(cuò)率，對(duì)基礎(chǔ)質(zhì)量進(jìn)行二次校驗(yàn)，并定期產(chǎn)出整體質(zhì)量的趨勢(shì)報(bào)告。

發(fā)布階段：

系統(tǒng)部署最容易暴露錯(cuò)誤，因此要有前置的 Checklist 模版、中置的上下游周知機(jī)制以及后置的回滾機(jī)制。

運(yùn)行階段：

系統(tǒng)多數(shù)時(shí)間處于運(yùn)行態(tài)，最重要的是運(yùn)行時(shí)的實(shí)時(shí)監(jiān)控，及時(shí)發(fā)現(xiàn)問(wèn)題、準(zhǔn)確報(bào)警并能提供詳細(xì)數(shù)據(jù)，以便排查問(wèn)題。

故障發(fā)生：

首要目標(biāo)是及時(shí)止損，防止影響面擴(kuò)大，然后定位原因、解決問(wèn)題，最后恢復(fù)服務(wù)。

對(duì)于日常運(yùn)維而言，高可用更多是針對(duì)運(yùn)行階段而言的，此階段需要額外進(jìn)行加強(qiáng)建設(shè)。

主要有以下幾種手段：

預(yù)防：

建立常態(tài)壓測(cè)體系，定期對(duì)服務(wù)進(jìn)行單點(diǎn)壓測(cè)以及全鏈路壓測(cè)，摸排水位。

管控：

做好線上運(yùn)行的降級(jí)、限流和熔斷保護(hù)。需要注意的是，無(wú)論是限流、降級(jí)還是熔斷，對(duì)業(yè)務(wù)都是有損的，所以在進(jìn)行操作前，一定要和上下游業(yè)務(wù)確認(rèn)好再進(jìn)行。就拿限流來(lái)說(shuō)，哪些業(yè)務(wù)可以限、什么情況下限、限流時(shí)間多長(zhǎng)、什么情況下進(jìn)行恢復(fù)，都要和業(yè)務(wù)方反復(fù)確認(rèn)。

監(jiān)控：

建立性能基線，記錄性能的變化趨勢(shì)；建立報(bào)警體系，發(fā)現(xiàn)問(wèn)題及時(shí)預(yù)警。

恢復(fù)：

遇到故障能夠及時(shí)止損，并提供快速的數(shù)據(jù)訂正工具，不一定要好，但一定要有。

在系統(tǒng)建設(shè)的整個(gè)生命周期中，每個(gè)環(huán)節(jié)中都可能犯錯(cuò)，甚至有些環(huán)節(jié)犯的錯(cuò)，后面是無(wú)法彌補(bǔ)的或者成本極高的。

所以高可用是一個(gè)系統(tǒng)工程，必須放到整個(gè)生命周期中進(jìn)行全面考慮。同時(shí)，考慮到服務(wù)的增長(zhǎng)性，高可用更需要長(zhǎng)期規(guī)劃并進(jìn)行體系化建設(shè)。

總結(jié)一下

高可用其實(shí)是在說(shuō) “穩(wěn)定性”，穩(wěn)定性是一個(gè)平時(shí)不重要，但出了問(wèn)題就要命的事情，然而它的落地又是一個(gè)問(wèn)題——平時(shí)業(yè)務(wù)發(fā)展良好，穩(wěn)定性建設(shè)就會(huì)降級(jí)給業(yè)務(wù)讓路。

解決這個(gè)問(wèn)題必須在組織上有所保障，比如讓業(yè)務(wù)負(fù)責(zé)人背上穩(wěn)定性績(jī)效指標(biāo)，同時(shí)在部門(mén)中建立穩(wěn)定性建設(shè)小組，小組成員由每條線的核心力量兼任，績(jī)效由穩(wěn)定性負(fù)責(zé)人來(lái)打分，這樣就可以把體系化的建設(shè)任務(wù)落實(shí)到具體的業(yè)務(wù)系統(tǒng)中了。

1.《電商網(wǎng)站的設(shè)計(jì) 大型電商網(wǎng)站分布式秒殺系統(tǒng)設(shè)計(jì)三種姿勢(shì)》援引自互聯(lián)網(wǎng)，旨在傳遞更多網(wǎng)絡(luò)信息知識(shí)，僅代表作者本人觀點(diǎn)，與本網(wǎng)站無(wú)關(guān)，侵刪請(qǐng)聯(lián)系頁(yè)腳下方聯(lián)系方式。

2.《電商網(wǎng)站的設(shè)計(jì) 大型電商網(wǎng)站分布式秒殺系統(tǒng)設(shè)計(jì)三種姿勢(shì)》僅供讀者參考，本網(wǎng)站未對(duì)該內(nèi)容進(jìn)行證實(shí)，對(duì)其原創(chuàng)性、真實(shí)性、完整性、及時(shí)性不作任何保證。

3.文章轉(zhuǎn)載時(shí)請(qǐng)保留本站內(nèi)容來(lái)源地址，http://f99ss.com/keji/346837.html