前面已經(jīng)寫(xiě)了很多億級(jí)流量的文章, 中間講了各種處理思路, 這兒將這些思路與業(yè)務(wù)綜合起來(lái), 情形一就是秒殺, 提到秒殺, 很多人都會(huì)覺(jué)得這是一件技術(shù)要求很高的事情, 因?yàn)檫@涉及到超大訪問(wèn)量(可能瞬間千萬(wàn)倍的用戶訪問(wèn)商品)、維護(hù)數(shù)據(jù)一致性(不能超賣(mài)), 前者對(duì)性能有極高的要求, 而后者又正好拉低了性能,本文談?wù)劽霘⒌脑O(shè)計(jì)思路, 并在最后給出秒殺設(shè)計(jì)的簡(jiǎn)單模型圖。

01 

秒殺的場(chǎng)景

生活中有很多秒殺的情景, 例如商家促銷(xiāo), 像一元搶茅臺(tái), 五毛錢(qián)搶寶馬(這兒只是一個(gè)例子), 假如一百萬(wàn)人來(lái)?yè)屖棵┡_(tái), 這時(shí)候肯定不能多賣(mài)出, 也就是不能被大于10的人數(shù)搶到, 通常最后時(shí)間會(huì)有一個(gè)倒計(jì)時(shí)按鈕, 30...29...28......3...2...1 GO! 之后躍躍欲試的人們開(kāi)始搶。這時(shí)候有以下問(wèn)題需要被考慮 :第一是多個(gè)客戶端的時(shí)間如何保持同步, 也就是讓大家看到時(shí)間是一致的, 不能你顯示3, 而我這還顯示 30 。第二是如何保證有沒(méi)有黃牛用機(jī)器人搶 。第三是如何確保后端服務(wù)器可以支撐住這巨大的流量。......

02 

秒殺的解決思路

有了上面的情景以及引出來(lái)的問(wèn)題, 來(lái)看看秒殺方案的設(shè)計(jì)思路, 我們服務(wù)器如何應(yīng)對(duì)這一百萬(wàn)的TPS呢?

首先想到的是擴(kuò)容, 詳情可以參考服務(wù)器擴(kuò)容思路及問(wèn)題分析 , 但這是不現(xiàn)實(shí)的, 因?yàn)閿U(kuò)容需要很多很多機(jī)器, TPS增加一萬(wàn)倍對(duì)物理服務(wù)器的性能要求遠(yuǎn)遠(yuǎn)不止一萬(wàn)倍, 另外對(duì)于一個(gè)商家來(lái)說(shuō), 為了這一次促銷(xiāo)活動(dòng)購(gòu)置服務(wù)器是不劃算的, 平時(shí)勢(shì)必有眾多的機(jī)器處于閑置狀態(tài)。

沒(méi)法擴(kuò)容, 那么也就意味著要使用其他方法, 如果所有請(qǐng)求訪問(wèn)一臺(tái)物理機(jī)器肯定不行, 一百萬(wàn)的數(shù)據(jù)訪問(wèn)無(wú)論如何分庫(kù)分表都無(wú)濟(jì)于事, 因?yàn)槊鎸?duì)的每一條都是熱點(diǎn)數(shù)據(jù), 所以要用到分布式架構(gòu)的思路。

03

秒殺的技術(shù)方案

分布式, 可以降低服務(wù)器的壓力, 下面開(kāi)始講述秒殺的設(shè)計(jì)思路。

方案一

很明顯, 要讓一百萬(wàn)用戶能夠同時(shí)打開(kāi)搶貨的網(wǎng)頁(yè), 勢(shì)必要用要到CDN(內(nèi)容分發(fā)網(wǎng)絡(luò), 對(duì)這個(gè)概念不清楚的話可以參考:全局負(fù)載均衡與CDN內(nèi)容分發(fā)), CDN主要作用有兩個(gè), 一方面是將一些不會(huì)改變的靜態(tài)資源放到離客戶端較近的邊緣服務(wù)器上, 這樣客戶端請(qǐng)求數(shù)據(jù)的時(shí)候可以直接從邊緣服務(wù)器獲取, 降低中心服務(wù)器的壓力；另外一方面，可以把小服務(wù)部署到 CDN 結(jié)點(diǎn)上去。這樣，當(dāng)前端頁(yè)面來(lái)問(wèn)開(kāi)沒(méi)開(kāi)始時(shí)，這個(gè)小服務(wù)除了告訴前端開(kāi)沒(méi)開(kāi)始外，它還可以統(tǒng)計(jì)下有多少人在線。每個(gè)小服務(wù)會(huì)把當(dāng)前在線等待秒殺的人數(shù)每隔一段時(shí)間就回傳給我們的數(shù)據(jù)中心，于是我們就知道全網(wǎng)總共在線的人數(shù)有多少。

???

假設(shè)，我們知道有大約 100 萬(wàn)的人在線等著搶?zhuān)敲矗谖覀兛煲_(kāi)始的時(shí)候，由數(shù)據(jù)中心向各個(gè)部署在 CDN 結(jié)點(diǎn)上的小服務(wù)上傳遞一個(gè)概率值，這個(gè)概率值為CDN節(jié)點(diǎn)人數(shù)權(quán)重乘以獲獎(jiǎng)概率, 比如說(shuō)是e，于是，當(dāng)秒殺開(kāi)始的時(shí)候，這 100 萬(wàn)用戶都在點(diǎn)下單按鈕，首先他們請(qǐng)求到的是 CDN 上的這些服務(wù)，這些小服務(wù)按照e的量把用戶放到后面的數(shù)據(jù)中心，也就是放過(guò)去人數(shù)*e，剩下的都直接返回秒殺已結(jié)束。

方案二

利用我們分布式中限流、網(wǎng)關(guān)等知識(shí), 將請(qǐng)求層層篩選, 降低最后連接到數(shù)據(jù)庫(kù)的請(qǐng)求。

首先也是利用CDN將靜態(tài)資源分發(fā)在邊緣服務(wù)器上, 當(dāng)進(jìn)行服務(wù)請(qǐng)求時(shí), 先進(jìn)行鑒權(quán), 鑒權(quán)主要是篩選機(jī)器人等非人工搶購(gòu), 根據(jù)實(shí)際經(jīng)驗(yàn), 鑒權(quán)可以篩選很大一部分用戶, 例如是否登錄。

當(dāng)鑒權(quán)確定是真實(shí)有效的用戶之后, 通過(guò)負(fù)載均衡(詳情可以參考LVS負(fù)載均衡理論以及算法概要)也就是LVS+Keepalived 將請(qǐng)求分配到不同的Nginx上,一般會(huì)建立Nginx集群, 然后再通過(guò)網(wǎng)關(guān)集群, 即使這樣還是要增加一些限流措施, 如果到這一步還是有很多請(qǐng)求壓到數(shù)據(jù)庫(kù)勢(shì)必?fù)尾蛔? 那么可以采取服務(wù)限流、服務(wù)降級(jí)等措施,進(jìn)行削峰處理。到這兒理論上流量就不高了, 如果還是很高, 后面就將熱點(diǎn)數(shù)據(jù)放進(jìn)緩存集群中進(jìn)行預(yù)熱, 同時(shí)設(shè)置定時(shí)任務(wù),一方面關(guān)注數(shù)據(jù)庫(kù)與緩存的一致性, 另一方面關(guān)閉超時(shí)未支付的訂單, 當(dāng)訂單提交之后 交給任務(wù)隊(duì)列, 生成訂單、修改數(shù)據(jù)庫(kù)、做好持久化工作。

架構(gòu)圖:

???

這就是整個(gè)“秒殺”的技術(shù)細(xì)節(jié)，是不是有點(diǎn)不敢相信？

與這種秒殺業(yè)務(wù)類(lèi)似的還有12306搶票, 這個(gè)也是瞬間高流量, 但是上面提到的架構(gòu)就不適合了,因?yàn)?2306完全不知道用戶來(lái)是要買(mǎi)哪張火車(chē)票的。不知道這個(gè)信息，很不好過(guò)濾用戶，而且用戶在買(mǎi)票前需要有很多查詢(xún)操作，然后在查詢(xún)中選擇自己的車(chē)票。也就意味著沒(méi)法在開(kāi)始就過(guò)濾用戶。

12306 最好的應(yīng)對(duì)方式，除了不要一次把所有的票放出來(lái)，而是分批在不同的時(shí)間段把票放出來(lái)，這樣可以讓人們不要集中在一個(gè)時(shí)間點(diǎn)來(lái)?yè)屍保龅饺巳夥至鳎梢越档鸵恍┎l(fā)度。

另外，12306 最好是用預(yù)售的方式，讓大家把自己的購(gòu)票先輸入到系統(tǒng)中。系統(tǒng)并不真正放票，而是把大家的需求都收集好，然后做整體統(tǒng)籌安排，該增加車(chē)次的增加車(chē)次，該加車(chē)廂的加車(chē)廂，這樣可以確保大家都能走。實(shí)在不行，就抽簽了。

04

總結(jié)

我們可以看到，解決秒殺這種特定業(yè)務(wù)場(chǎng)景，可以使用 CDN 的邊緣結(jié)點(diǎn)來(lái)扛流量，然后過(guò)濾用戶請(qǐng)求（限流用戶請(qǐng)求），來(lái)保護(hù)數(shù)據(jù)中心的系統(tǒng)，這樣才讓整個(gè)秒殺得以順利進(jìn)行。也可以像方案二那樣逐層過(guò)濾請(qǐng)求, 這種業(yè)務(wù)場(chǎng)景和雙十一相同嗎?

如果像雙 11 那樣，想盡可能多地賣(mài)出商品，那么就不像秒殺了。這是要盡可能多地收訂單，但又不能超過(guò)庫(kù)存，其中還有大量的銀行支付，各大倉(cāng)庫(kù)的庫(kù)存查詢(xún)和分配，這些都是非常慢的操作。

為了保證一致性，還要能夠扛得住像雙 11 這樣的大規(guī)模并發(fā)訪問(wèn)，那么，應(yīng)該怎么做呢？使用秒殺這樣的解決方案基本上不太科學(xué)了。

這個(gè)時(shí)候就需要認(rèn)認(rèn)真真地做高并發(fā)的架構(gòu)和測(cè)試了，需要各個(gè)系統(tǒng)把自己的性能調(diào)整上去，還要小心地做性能規(guī)劃，更要把分布式的彈力設(shè)計(jì)做好，最后是要不停地做性能測(cè)試，找到整個(gè)架構(gòu)的系統(tǒng)瓶頸，然后不斷地做水平擴(kuò)展，以解決大規(guī)模的并發(fā)。

有些時(shí)候，我們總是在想數(shù)據(jù)中心的解決方案。其實(shí)，我們有時(shí)候也需要換一換思路，也許，在數(shù)據(jù)中心解決并不一定是最好的方式，放在邊緣來(lái)解決可能會(huì)更好一些。尤其是針對(duì)一些有地域特征的業(yè)務(wù)，比如像外賣(mài)、共享單車(chē)、打車(chē)這樣的業(yè)務(wù)。

其實(shí)，把一些簡(jiǎn)單的業(yè)務(wù)邏輯放在邊緣，比放在數(shù)據(jù)中心不但能夠有更好的性能，還有更便宜的成本。我覺(jué)得，隨著請(qǐng)求量越來(lái)越大，數(shù)據(jù)也越來(lái)越多，數(shù)據(jù)中心是有點(diǎn)到瓶頸了，而需要邊緣結(jié)點(diǎn)來(lái)幫忙了。而且，這個(gè)邊緣化解決方案的趨勢(shì)也會(huì)越來(lái)越有優(yōu)勢(shì)。

本文作者：等不到的口琴原文鏈接：https://www.cnblogs.com/Courage129/p/14493931.html

會(huì)議推薦：

隨著云原生技術(shù)的廣泛應(yīng)用與業(yè)務(wù)需求的不斷豐富，企業(yè)對(duì)于系統(tǒng)架構(gòu)的要求越來(lái)越高。如何根據(jù)不同的業(yè)務(wù)特性進(jìn)行系統(tǒng)架構(gòu)的設(shè)計(jì)與技術(shù)選型，成為了架構(gòu)師最為關(guān)心的問(wèn)題。在本屆WOT全球技術(shù)創(chuàng)新大會(huì)“架構(gòu)設(shè)計(jì)與架構(gòu)實(shí)踐”專(zhuān)題中，我們邀請(qǐng)到了來(lái)自不同企業(yè)的數(shù)位技術(shù)專(zhuān)家，為大家分享架構(gòu)設(shè)計(jì)與落地的最佳實(shí)踐，希望能夠給大家提供一些不一樣的思路和方案參考。

☆ WOT全球技術(shù)創(chuàng)新大會(huì)2022 ☆

2022/4/9-4/10

???

WOT全球技術(shù)創(chuàng)新大會(huì)2022是51CTO中國(guó)技術(shù)社區(qū)為廣大技術(shù)從業(yè)者精心打造的WOT2.0升級(jí)版。大會(huì)專(zhuān)題覆蓋包括人工智能、數(shù)據(jù)安全、音視頻、大數(shù)據(jù)、架構(gòu)、開(kāi)源、云原生、前端、研發(fā)管理、算法、金融科技、微服務(wù)等眾多方向。

本屆WOT大會(huì)預(yù)計(jì)1500人參會(huì)，100余家企業(yè)合作，60位專(zhuān)家分享。大會(huì)不僅邀請(qǐng)到騰訊、阿里、百度、58、大搜車(chē)等一線互聯(lián)網(wǎng)大廠的技術(shù)專(zhuān)家，為大家進(jìn)行獨(dú)家技術(shù)干貨的分享。還特別邀請(qǐng)到數(shù)位國(guó)內(nèi)頂尖技術(shù)科學(xué)家，為大家詳細(xì)解讀國(guó)內(nèi)重點(diǎn)技術(shù)創(chuàng)新戰(zhàn)略及相關(guān)政策。