【秒殺】1、系統設計要點，從賣病鵝提及

原創：小姐姐味道（微信公衆號ID：xjjdog），歡迎分享，轉載請保留出處。

秒殺，就像是計劃經濟的菜市場，過客匆匆，你來我往。熙熙攘攘一陣子，事後只留下冷清寂寞的大街。

且看一個賣鵝的故事。↓↓↓

就在昨天。天剛矇矇亮，大概是早晨五六點鐘，幾個程序員頂着蓬鬆的頭髮，下班結伴而行。這個時候，街上的路燈尚未滅的乾脆。幾個鍛鍊的老大爺，叉着腰，身體前傾，彎成一張弓。

因此，衚衕岔口裏一個賣鵝的小販，就顯得特別的顯眼。就見一大羣鵝被關在諾大的籠子裏，撲棱着翅膀。有幾隻精力旺盛的，伸長脖子呱呱叫着，小販聽得心煩，就用手中的樹枝敲它們的腦殼。

小販歪了歪嘴，又用眼角餘光掃了下手機，已經五點六十了。就在這時，四面八方就圍上來一羣大媽，就像是從地底冒出來同樣。剛開始還悠然的靠攏，等看到籠子果真有一羣鵝，就捏着手裏的小包，爭先恐後的小跑起來。

這來勢洶洶的陣勢，嚇了你們一跳，程序員們站住不動了。大爺的腰也不彎了，就連那些聒噪的鵝，也不叫了。

很快就有大媽幫小販打開了籠子，不容分說，扯住一隻鵝的脖子就拖了出來。接着就有另一隻手扯住了另外一隻鵝的翅膀。一會兒人喊鵝嘶，吵吵嚷嚷，下起了鵝毛大雪。不一下子，全部的鵝就都在大媽們手裏了。但也有更多沒獲得鵝的大媽，用手絹在一旁抹着悔恨嫉妒的淚水。

王大媽最高興了，她手大，抓了三隻，其中兩隻倒黴的鵝被她握在一隻手裏，脖子擰成一根麻花。也有被捏死的鵝，犯了鵝命的大媽就不想要了，但有更多的大媽根本就不嫌棄。

小販長吁一口氣，招數確實有效，就搞了個秒殺，這羣犯了瘟病的鵝，瞬間被低價處理了。

這一切全落在了躲在一旁的程序員們眼裏。等人散的差很少了，他們把小販圍上，其中一個眼尖，喊了出來：」這賣鵝的，不是xjjdog麼？「

「xjjdog正是在下。咱們不如找個油條館子，坐下來等我給大家，慢慢道來。」

秒殺難點

秒殺，這麼酷炫的詞語，註定了不是小綿羊，而是洪水猛獸。3w塊錢和3000w的系統差異，想要了解一下麼？

任何不對等的狀況，都會產生危機，對業務系統來講一樣的道理。秒殺系統難，主要集中在如下幾點。

一、流量超出承載範圍
秒殺，通常歸做 突發流量，日常一天的請求量，可能集中在幾秒以內就能完成。秒殺資源的稀缺，也會形成資源成爲熱點，發生多人爭搶的局面。想象一下小長假的高速公路收費站，就可以瞭解到一無所獲的參與者有多火大。

二、資源衝突
若是採用傳統的數據庫進行數據存儲，對同一資源的爭搶，就會面臨嚴重的鎖衝突問題。通常是經過一個前置的，速度更快的存儲頂在前面，這就涉及到源庫和目標庫的數據同步問題。

從商品資源的上架，到秒殺的完成，會經歷一個短暫的混沌狀態，出現數據不一致的狀況。在請求量很是集中的狀況下，還會產生併發問題，個體的行爲和結果，是不可預測的。

三、難度高 秒殺對基礎設施和技術的要求也是比較高的，從接入層到緩存到存儲層，以及安全方面的考慮，須要多個組件的參與，並且每一個組件都須要進行優化。

總之，吵吵鬧鬧一場，最終會歸於平靜。爲了秒殺而準備的硬件資源，不能就放在那裏閒置了吧，因此通常還會有一個資源釋放階段，這是後話，咱們不作過多關注。

業務三階段

通常的，秒殺業務會分爲三個階段。其中，搶購階段，就是咱們常說的秒殺業務。

一、準備階段
在準備階段，除了硬件和軟件系統的準備，通常會有一個活動上的預熱，互聯網運營會將相似電線杆上小廣告的東西，廣而發之。從前，有個客戶搞了個秒殺活動，100個庫存99我的參與，99我的有90個內部員工，尷尬呵呵。

若是有本身的app，經過通知、訂閱，會達到比較好的效果。若是涉及的商品多，參與人數巨大，會對數據進行預處理，進行提早預熱。一切準備穩當，就能夠抽根菸，等着倒計時了。

二、搶購
俗話說，臺上一分鐘，臺下十年功。秒殺開始，會有大量的瞬間請求涌入，該到了上臺表演的時候了。這個階段，咱們的每一個系統和模塊，都會迅速輪轉起來，任何一個點考慮不周，都會形成本次秒殺活動的失敗，因此關鍵組件要保證極高可用。

三、結束清算
上面也說過，秒殺會有一個短暫的混沌態。清算階段，就要完成數據的最終一致性，落庫動做可能會持續很多時間。可能有的用戶，在付款的那一刻，後悔了，商品要從新歸位回倉。回倉後的商品通常會再次售賣，好比火車票，30分鐘後能夠再搶一次；有的商品就能夠被鎖定下架，永遠消失了。

制約原理

這裏，咱們大致說一下秒殺系統在技術方面的基本制約原理，詳細的描述和代碼，咱們在後面的章節裏進行說明。

數據預熱

有的系統進行秒殺的，可能就那麼幾件商品，手工錄入都玩得轉。對於平臺類型，或者用戶量巨大的app，秒殺的商品就再也不那麼簡單。

中間，會進行一些數據的合併，或者二維展開，也就是準備秒殺的數據。這些數據進行處理以後，會提早進入到秒殺系統進行數據預熱。

秒殺階段進行的是否順利，得看數據準備的是否合理。

請求承載

這是請求的最外層，屬於接入層。作的好的系統，可以在接入層就屏蔽大部分請求，極大的減輕後端服務的壓力。

鏈接數承載
對於接入層來講，首先一個挑戰就是鏈接數。通常互聯網的接入層，就是lvs+nginx。這裏會涉及到對操做系統的優化，以及對於nginx自己的優化。

併發承載 對於落到某臺機器上的請求，依然會存在併發高的問題。線程池使用要合理，怎麼去進行過濾，合併等，有必定挑戰。

負載均衡
請求要能真正的作到均衡，不能產生熱點問題。好比nginx的ip_hash，雖然能必定程度上規避分佈式session問題，但請求會不均衡。

重試？
秒殺業務不要配置重試，會加重系統負載。請求失敗？那就再來一次。

系統隔離
秒殺業務佔用的系統資源，和正常運行的系統嚴重不對等。若是有條件，秒殺系統的硬件和服務環境，要與正常業務系統進行必定程度的隔離。要提早評估對其餘服務的壓力，避免影響正常業務。

CDN
對於html，js，css，圖片等內容，佔用了大量的帶寬。若是將這些資源都放在本身的服務器上，流量到來時會迅速佔滿帶寬，形成正常的秒殺請求沒法完成。CDN能夠有效解決這個問題。剩下的請求，就是真正的秒殺業務。

減少請求包
對網絡請求包，要進行大量優化。能夠開gzip壓縮，資源自己也進行壓縮，去掉請求包中的無用信息，對網絡報文進行精簡。

請求攔截

秒殺系統一個很是大的原則，就是要把儘可能多的無效請求，攔截在外部。請求攔截，能夠分爲上游攔截和業務攔截。

上游攔截
攔截方面，存在一個全局的設置。當系統判斷以及達到瓶頸階段，就能夠經過全侷限流方式進行服務降級，對於一些次級服務，要進行熔斷處理。對於前端來講，也是須要進行一些優化的。好比瀏覽器緩存，防重入驗證等，可以攔截數量可觀的請求。

業務攔截
除了一些全局的限制，對於大部分請求來講，和用戶是息息相關的。一個用戶，可能會頻繁的刷新，或者繞過前端，直接使用軟件調用後端接口。這些用戶的非法請求，也要進行攔截。

同時，用戶對資源的爭奪，也不該該無限等待。好比100個庫存的商品，第1w個請求到來的時候，就不須要再排隊等待了，直接返回秒殺完畢就ok了。

排隊方面，會用到jvm內排隊，也會用到外部的消息隊列，mq，進行請求的緩衝。

數據緩存

緩存，多是秒殺系統中最重要的一個組件了。從前端緩存，到jvm緩存，再到分佈式緩存，都會對系統性能產生數量級的提高。值得注意的是，因爲秒殺系統嚴重依賴緩存系統，因此緩存系統須要作高可用。

緩存的讀操做，要考慮數據的加載和同步。寫請求，就要考慮數據的合併與併發寫入，數據的一致性等。雖然緩存的速度比起DB來，快了不少不少，但它的性能老是有瓶頸的，相關代碼要着重優化。

安全

技術的門檻愈來愈低，二年級的小學生都開課教swift了，寫個秒殺插件什麼的，不費吹灰之力。秒殺系統的安全性比較重要，應該說和錢打交道的系統，都是容易出問題的。你要是想薅羊毛，認準營銷、秒殺業務，準沒錯。

要儘可能提升做弊門檻，好比url動態化，從入口就隔絕了大部分攻擊；驗證碼，只會增長攻擊者的成本。有些安全性級別較高的，還會增長風控規則，好比同一ip請求過多封禁、帳號註冊日期三天以內不容許參與、秒殺的門檻必須是金牌會員等。

我曾經經歷過一次，對方原本是一個算加減乘除的驗證碼，腳本都寫好了。結果秒殺前5分鐘，驗證碼12306附體，xjjdog直接放棄了。

躲在幕後的DB

在整個秒殺系統中，傳統的DB，只能灰溜溜的躲在幕後（小流量除外）。我要是DB，也會躲在後面瑟瑟發抖。

DB的數據，要提早載入到秒殺系統中進行運算，秒殺完畢，還要把狼藉的數據進行落地與清算。在筆者見過的很多秒殺場景中，甚至不須要DB的參與，真是藝高人膽大。

這就引伸出另一個問題。假如緩存系統出現問題，請求要不要穿透呢？個人建議是，不須要。非正常的請求，會瞬間壓垮DB，產生更加嚴重的數據錯亂問題，假如沒有作隔離，後果會更狂野。與其錯了，不如認慫，乖乖的覆盤寫故障報告吧。

End

秒殺，奪寶，p2p，是互聯網創造的，錢袋子三大殺手。

我要說一些隱祕的事情。前不久，個人這羣鵝原本好好的，結果混進一隻長了瘟病的雞，沒幾天就病懨懨的不行了，要是扔了怪惋惜的。這賣鵝的時間線，也搞的十分緊湊。

就在昨天，我就放出了有一批廉價鵝要處理的消息。爲了讓更多的大媽相信，我按照市面價格打了個五折，其實打一折都能出手（抖音上那種鵝不敢賣）。5點多我就給幾隻快不成的鵝，注射了興奮劑，但願它們能多撐一會，還拿了根樹枝敲它們的腦殼進行確認。不是我自信，這種場景，就是死鵝也賣得出去。但死的多了，畢竟很差。爲了限制擁擠的人流，我特地把籠子口的鐵絲角給漏出來，很多大媽劃破了手都沒把鵝抓到，我也搞不清她們是不幸，仍是幸運。

是誰首先創造的秒殺？真是天才。和飢餓營銷同樣，收的是智商稅吧。哈哈哈~

做者簡介：小姐姐味道 (xjjdog)，一個不容許程序員走彎路的公衆號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高併發世界，給你不同的味道。個人我的微信xjjdog0，歡迎添加好友，​進一步交流。​