說(shuō)到“秒殺”，恐怕大多數(shù)人想到的就是“雙 11”，“促銷(xiāo)”，“買(mǎi)買(mǎi)買(mǎi)”等火爆的場(chǎng)面吧。

圖片來(lái)自 Pexels

大家為了打折商品蜂擁而至，造成

技術(shù)隔離架構(gòu)圖

前面有了準(zhǔn)備工作，那么從技術(shù)上需要有以下幾個(gè)方面的考慮：

客戶(hù)端，前端秒殺頁(yè)面使用專(zhuān)門(mén)的頁(yè)面，這些頁(yè)面包括靜態(tài)的 HTML 和動(dòng)態(tài)的 JS，他們都需要在

秒殺系統(tǒng)前端設(shè)計(jì)簡(jiǎn)圖

代理層設(shè)計(jì)

說(shuō)完了秒殺系統(tǒng)的前端設(shè)計(jì)，請(qǐng)求自然地來(lái)到了代理層。由于用戶(hù)的請(qǐng)求量大，我們需要用負(fù)載均衡加上服務(wù)器集群，來(lái)面對(duì)如此空前的壓力。

代理層三大功能簡(jiǎn)圖

在這一層是可以做緩存，過(guò)濾和限流的：

• 緩存，以 Nginx 為例，它可以緩存用戶(hù)的信息。假設(shè)用戶(hù)信息的修改沒(méi)有那么頻繁，即使有類(lèi)似的修改也可以通過(guò)更新服務(wù)來(lái)刷新。總比從服務(wù)器上獲取效率要高得多。
• 過(guò)濾，既然緩存了用戶(hù)信息，這里就可以過(guò)濾掉一些不滿(mǎn)足條件的用戶(hù)。注意，這里的用戶(hù)信息的過(guò)濾和緩存只是一個(gè)例子。

主要想表達(dá)的意思是，可以將一些變化不頻繁的數(shù)據(jù)，提到代理層來(lái)緩存，提高響應(yīng)的效率。

同時(shí)，還可以根據(jù)風(fēng)控系統(tǒng)返回的信息，過(guò)濾一些疑似機(jī)器人或者惡意請(qǐng)求。例如：從固定 IP 過(guò)來(lái)的，頻率過(guò)高的請(qǐng)求。最重要的就是在這一層，可以識(shí)別來(lái)自秒殺系統(tǒng)的請(qǐng)求。

如果是帶有秒殺系統(tǒng)的參數(shù)，就要把請(qǐng)求路由到秒殺系統(tǒng)的服務(wù)器集群。這樣才能和正常的業(yè)務(wù)系統(tǒng)分割開(kāi)來(lái)。

• 限流，每個(gè)服務(wù)器集群能夠承受的壓力都是有限的。代理層可以根據(jù)服務(wù)器集群能夠承受的大壓力，設(shè)置流量的閥值。

閥值的設(shè)置可以是動(dòng)態(tài)調(diào)整的。例如：集群服務(wù)器中有 10 個(gè)服務(wù)器，其中一臺(tái)由于壓力過(guò)大掛掉了。

此時(shí)就需要調(diào)整代理層的流量閥值，將能夠處理的請(qǐng)求流量減少，保護(hù)后端的應(yīng)用服務(wù)器。

當(dāng)服務(wù)器恢復(fù)以后，又可以將閥值調(diào)回原位?？梢酝ㄟ^(guò) Nginx+Lua 合作完成，Lua 從服務(wù)注冊(cè)中心讀取服務(wù)健康狀態(tài)，動(dòng)態(tài)調(diào)整流量。

應(yīng)用層設(shè)計(jì)

“秒殺系統(tǒng)”秒殺的是什么?無(wú)非是商品。對(duì)于系統(tǒng)來(lái)說(shuō)就是商品的庫(kù)存，購(gòu)買(mǎi)的商品一旦超過(guò)了庫(kù)存就不能再賣(mài)了。

防止超賣(mài)

超過(guò)了庫(kù)存還可以賣(mài)給用戶(hù)，這就是“超賣(mài)”，也是系統(tǒng)設(shè)計(jì)需要避免的。為了承受大流量的訪(fǎng)問(wèn)，我們用了水平擴(kuò)展的服務(wù)，但是對(duì)于他們消費(fèi)的資源“庫(kù)存”來(lái)說(shuō)，卻只有一個(gè)。

為了提高效率，會(huì)將這個(gè)庫(kù)存信息放到緩存中。以流行的 Redis 為例，用它存放庫(kù)存信息，由多個(gè)線(xiàn)程來(lái)訪(fǎng)問(wèn)就會(huì)出現(xiàn)資源爭(zhēng)奪的情況。也就是分布式程序爭(zhēng)奪唯一資源，為了解決這個(gè)問(wèn)題我們需要實(shí)現(xiàn)分布式鎖。

假設(shè)這里有多個(gè)應(yīng)用響應(yīng)用戶(hù)的訂單請(qǐng)求，他們同時(shí)會(huì)去訪(fǎng)問(wèn) Redis 中存放的庫(kù)存信息，每接受用戶(hù)一次請(qǐng)求，都會(huì)從 Redis 的庫(kù)存中減去 1 個(gè)商品庫(kù)存量。

當(dāng)任何一個(gè)進(jìn)程訪(fǎng)問(wèn) Redis 中的庫(kù)存資源時(shí)，其他進(jìn)程是不能訪(fǎng)問(wèn)的，所以這里需要考慮鎖的情況(樂(lè)觀(guān)，悲觀(guān))。

Redis 緩存承載庫(kù)存變量

如果鎖長(zhǎng)期沒(méi)有釋放，需要考慮鎖的過(guò)期時(shí)間，需要設(shè)置兩個(gè)超時(shí)時(shí)間：

• 資源本身的超時(shí)時(shí)間，一旦資源被使用一段時(shí)間還沒(méi)有被釋放，Redis 會(huì)自動(dòng)釋放掉該資源給其他服務(wù)使用。
• 服務(wù)獲取資源的超時(shí)時(shí)間，一旦一個(gè)服務(wù)獲取資源一段時(shí)間后，不管該服務(wù)是否處理完這個(gè)資源，都需要釋放該資源給其他服務(wù)使用。

訂單處理流程

這里的“扣減服務(wù)”完成了最簡(jiǎn)單的扣減庫(kù)存工作，并沒(méi)有和其他項(xiàng)目服務(wù)打交道，更沒(méi)有訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)。

訂單流程示意圖

后面的流程相對(duì)比較復(fù)雜，我們先看圖，根據(jù)圖示來(lái)講解：

• 首先，扣減服務(wù)作為下單流程的入口，會(huì)先對(duì)商品的庫(kù)存做扣減。同樣它會(huì)檢查商品是否還有庫(kù)存?
• 由于訂單對(duì)應(yīng)的操作步驟比較多，為了讓流量變得平滑，這里使用隊(duì)列存放每個(gè)訂單請(qǐng)求，等待訂單處理服務(wù)完成具體業(yè)務(wù)。
• 訂單處理服務(wù)實(shí)現(xiàn)多線(xiàn)程，或者水平擴(kuò)展的服務(wù)陣列，它們不斷監(jiān)聽(tīng)隊(duì)列中的消息。一旦發(fā)現(xiàn)有新訂單請(qǐng)求，就取出訂單進(jìn)行后續(xù)處理。

注意，這里可以加入類(lèi)似 ZooKeeper 這樣的服務(wù)調(diào)度來(lái)幫助，協(xié)調(diào)服務(wù)調(diào)度和任務(wù)分配。

• 訂單處理服務(wù)，處理完訂單以后會(huì)把結(jié)果寫(xiě)到數(shù)據(jù)庫(kù)。寫(xiě)數(shù)據(jù)庫(kù)是 IO 操作，耗時(shí)長(zhǎng)。
• 所以，在寫(xiě)數(shù)據(jù)庫(kù)的同時(shí)，會(huì)把結(jié)果先寫(xiě)入緩存中，這樣用戶(hù)是可以第一時(shí)間查詢(xún)自己是否下單成功了。
• 結(jié)果寫(xiě)入數(shù)據(jù)庫(kù)，這個(gè)操作有可能成功也有可能失敗。
• 為了保證數(shù)據(jù)的最終一致性，我們用訂單結(jié)果同步的服務(wù)不斷的對(duì)比，緩存和數(shù)據(jù)庫(kù)中的訂單結(jié)果信息。

一旦發(fā)現(xiàn)不一致，會(huì)去做重試操作。如果重試依舊不成功，會(huì)重寫(xiě)信息到緩存，讓用戶(hù)知道失敗原因。

• 用戶(hù)下單以后，焦慮地刷新頁(yè)面查看下單的結(jié)果，實(shí)際上是讀到的緩存上的下單結(jié)果信息。

雖然，這個(gè)信息和最終結(jié)果有偏差，但是在秒殺的場(chǎng)景，要求高性能是前提，結(jié)果的一致性，可以后期補(bǔ)償。

數(shù)據(jù)庫(kù)設(shè)計(jì)

講完了秒殺的處理流程，來(lái)談?wù)剶?shù)據(jù)庫(kù)設(shè)計(jì)要注意的點(diǎn)。

數(shù)據(jù)估算

前面說(shuō)了秒殺場(chǎng)景需要注意隔離，這里的隔離包括“業(yè)務(wù)隔離”。就是說(shuō)我們?cè)诿霘⒅?，需要通過(guò)業(yè)務(wù)的手段，例如：熱場(chǎng)活動(dòng)，問(wèn)卷調(diào)查，歷史數(shù)據(jù)分析。通過(guò)他們?nèi)ス浪氵@次秒殺可能需要存儲(chǔ)的數(shù)據(jù)量。

這里有兩部分的數(shù)據(jù)需要考慮：

• 業(yè)務(wù)數(shù)據(jù)
• 日志數(shù)據(jù)

前者不言而喻是給業(yè)務(wù)系統(tǒng)用的。后者，是用來(lái)分析和后續(xù)處理問(wèn)題訂單用的，秒殺完畢以后還可以用來(lái)復(fù)盤(pán)。

分表分庫(kù)

對(duì)于這些數(shù)據(jù)的存放，需要分情況討論，例如，MySQL 單表推薦的存儲(chǔ)量是 500W 條記錄(經(jīng)驗(yàn)數(shù)字)。

如果估算的時(shí)候超過(guò)了這個(gè)數(shù)據(jù)，建議做分表。如果服務(wù)的連接數(shù)較多，建議進(jìn)行分庫(kù)的操作。

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

由于大量的數(shù)據(jù)操作是插入，有少部分的修改操作。如果使用關(guān)系型數(shù)據(jù)來(lái)存儲(chǔ)，建議用專(zhuān)門(mén)的表來(lái)存放，不建議使用業(yè)務(wù)系統(tǒng)正在使用的表。

這個(gè)開(kāi)頭提到了，數(shù)據(jù)隔離是必須的，一旦秒殺系統(tǒng)掛了，不會(huì)影響到正常業(yè)務(wù)系統(tǒng)，這個(gè)風(fēng)險(xiǎn)意識(shí)要有。表的設(shè)計(jì)除了 ID 以外，最好不要設(shè)置其他主鍵，保證能夠快速地插入。

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

由于是用的專(zhuān)用表存儲(chǔ)，在秒殺活動(dòng)完畢以后，需要將其和現(xiàn)有的數(shù)據(jù)做合并。其實(shí)，交易已經(jīng)完成，合并的目的也就是查詢(xún)。

這個(gè)合并需要根據(jù)具體情況來(lái)分析，如果對(duì)于那些“只讀”的數(shù)據(jù)，對(duì)于做了讀寫(xiě)分離的公司，可以導(dǎo)入到專(zhuān)門(mén)負(fù)責(zé)讀的數(shù)據(jù)庫(kù)或者 NoSQL 數(shù)據(jù)庫(kù)中。

壓力測(cè)試

構(gòu)建了秒殺系統(tǒng)，一定會(huì)面臨上線(xiàn)，那么在上線(xiàn)之前壓力測(cè)試是必不可少的。

我們做壓力測(cè)試的目的是檢驗(yàn)系統(tǒng)崩潰的邊緣在哪里?系統(tǒng)的極限在哪里?

這樣才能合理地設(shè)置流量的上限，為了保證系統(tǒng)的穩(wěn)定性，多余的流量需要被拋棄。

壓力測(cè)試的方法

合理的測(cè)試方法可以幫助我們對(duì)系統(tǒng)有深入的了解，這里介紹兩種壓力測(cè)試的方法：

• 正壓力測(cè)試
• 負(fù)壓力測(cè)試

正壓力測(cè)試。每次秒殺活動(dòng)都會(huì)計(jì)劃，使用多少服務(wù)器資源，承受多少的請(qǐng)求量。

可以在這個(gè)請(qǐng)求量上面不斷加壓，直到系統(tǒng)接近崩潰或者真正崩潰。簡(jiǎn)單的說(shuō)就是做加法。

正壓力測(cè)試示意圖

負(fù)壓力測(cè)試。在系統(tǒng)正常運(yùn)行的情況下，逐步減少支撐系統(tǒng)的資源(服務(wù)器)，看什么時(shí)候系統(tǒng)無(wú)法支撐正常的業(yè)務(wù)請(qǐng)求。

例如：在系統(tǒng)正常運(yùn)行的情況下，逐步減少服務(wù)器或者微服務(wù)的數(shù)量，觀(guān)察業(yè)務(wù)請(qǐng)求的情況。說(shuō)白了就是做減法。

負(fù)壓力測(cè)試示意圖

壓力測(cè)試的步驟

測(cè)試步驟

有了測(cè)試方法的加持，我們來(lái)看看需要遵循哪些測(cè)試步驟。下面的操作偏套路化，大家在其他系統(tǒng)的壓力測(cè)試也可以這么做，給大家做個(gè)參考。

第一，確定測(cè)試目標(biāo)。與性能測(cè)試不同的是，壓力測(cè)試的目標(biāo)是，什么時(shí)候系統(tǒng)會(huì)接近崩潰。比如：需要支撐 500W 訪(fǎng)問(wèn)量。

第二，確定關(guān)鍵功能。壓力測(cè)試其實(shí)是有重點(diǎn)的，根據(jù) 2/8 原則，系統(tǒng)中 20% 的功能被使用的是最多的，我們可以針對(duì)這些核心功能進(jìn)行壓力測(cè)試。例如：下單，庫(kù)存扣減。

關(guān)注核心服務(wù)

第三，確定負(fù)載。這個(gè)和關(guān)鍵服務(wù)的思路一致，不是每個(gè)服務(wù)都有高負(fù)載的，我們的測(cè)試其實(shí)是要關(guān)注那些負(fù)載量大的服務(wù)，或者是一段時(shí)間內(nèi)系統(tǒng)中某些服務(wù)的負(fù)載有波動(dòng)。這些都是測(cè)試目標(biāo)。

第四，選擇環(huán)境，建議搭建和生產(chǎn)環(huán)境一模一樣的環(huán)境進(jìn)行測(cè)試。

第五，確定監(jiān)視點(diǎn)，實(shí)際上就是對(duì)關(guān)注的參數(shù)進(jìn)行監(jiān)視，例如 CPU 負(fù)載，內(nèi)存使用率，系統(tǒng)吞吐量等等。

第六，產(chǎn)生負(fù)載，這里需要從生產(chǎn)環(huán)境去獲取一些真實(shí)的數(shù)據(jù)作為負(fù)載數(shù)據(jù)源，這部分?jǐn)?shù)據(jù)源根據(jù)目標(biāo)系統(tǒng)的承受要求由腳本驅(qū)動(dòng)，對(duì)系統(tǒng)進(jìn)行沖擊。

建議使用往期秒殺系統(tǒng)的數(shù)據(jù)，或者實(shí)際生產(chǎn)系統(tǒng)的數(shù)據(jù)進(jìn)行測(cè)試。

第七，執(zhí)行測(cè)試，這里主要是根據(jù)目標(biāo)系統(tǒng)，關(guān)鍵組件，用負(fù)載進(jìn)行測(cè)試，返回監(jiān)視點(diǎn)的數(shù)據(jù)。

建議團(tuán)隊(duì)可以對(duì)測(cè)試定一個(gè)計(jì)劃，模擬不同的網(wǎng)絡(luò)環(huán)境，硬件條件進(jìn)行有規(guī)律的測(cè)試。

第八，分析數(shù)據(jù)，針對(duì)測(cè)試的目的，對(duì)關(guān)鍵服務(wù)的壓力測(cè)試數(shù)據(jù)進(jìn)行分析得知該服務(wù)的承受上限在哪里。

對(duì)一段時(shí)間內(nèi)有負(fù)載波動(dòng)或者大負(fù)載的服務(wù)進(jìn)行數(shù)據(jù)分析，得出服務(wù)改造的方向。

總結(jié)

秒殺系統(tǒng)的特點(diǎn)，并發(fā)量大，資源有限，操作相對(duì)簡(jiǎn)單，訪(fǎng)問(wèn)的都是熱點(diǎn)數(shù)據(jù)。因此，我們需要把它從業(yè)務(wù)，技術(shù)，數(shù)據(jù)上做隔離，保證不影響到現(xiàn)有的系統(tǒng)。

因此，架構(gòu)設(shè)計(jì)需要分幾層來(lái)考慮，從客戶(hù)請(qǐng)求到數(shù)據(jù)庫(kù)存儲(chǔ)，到最后上線(xiàn)前的壓力測(cè)試。

簡(jiǎn)易的思維導(dǎo)圖送給大家

思考順序如下，客戶(hù)端→代理層→應(yīng)用層→數(shù)據(jù)庫(kù)→壓力測(cè)試：

客戶(hù)端 90% 靜態(tài) HTML+10% 動(dòng)態(tài) JS;配合 CDN 做好緩存工作。

接入層專(zhuān)注于過(guò)濾和限流。

應(yīng)用層利用緩存+隊(duì)列+分布式處理好訂單。

做好數(shù)據(jù)的預(yù)估，隔離，合并。

上線(xiàn)之前記得進(jìn)行壓力測(cè)試。

網(wǎng)站欄目：這一次，徹底弄懂“秒殺系統(tǒng)”
當(dāng)前URL：http://m.rwnh.cn/news18/98718.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App設(shè)計(jì)、營(yíng)銷(xiāo)型網(wǎng)站建設(shè)、響應(yīng)式網(wǎng)站、全網(wǎng)營(yíng)銷(xiāo)推廣、ChatGPT、網(wǎng)站內(nèi)鏈

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)