秒殺系統(tǒng)設(shè)計(jì)探析

發(fā)布日期：2022/9/25 23:51:49      瀏覽量：

一、秒殺是什么？

秒殺系統(tǒng)的業(yè)務(wù)邏輯和復(fù)雜程度都被大眾熟知，其實(shí)主要解決的問(wèn)題有兩個(gè)——高并發(fā)和一致性。其中高并發(fā)又分為讀和寫(xiě)，要減少用戶從服務(wù)端讀取數(shù)據(jù)，控制數(shù)據(jù)的傳輸大??；寫(xiě)則需要獨(dú)立處理數(shù)據(jù)庫(kù)。一致性是指保證庫(kù)存數(shù)據(jù)的準(zhǔn)確，超賣和超買(mǎi)都是不能出現(xiàn)的。至于高可用會(huì)在最后介紹，通過(guò)高可用可以保證流量超出預(yù)期或其他外情況發(fā)生時(shí)，秒殺活動(dòng)的順利完成。

 綜上所述，秒殺系統(tǒng)是一個(gè)要滿足高并發(fā)、強(qiáng)一致、高可用的分布式系統(tǒng)。

二、秒殺架構(gòu)的設(shè)計(jì)要素

針對(duì)秒殺系統(tǒng)的架構(gòu)設(shè)計(jì)需要考慮以下幾個(gè)要素：

1.減少讀的次數(shù)

這里提到的讀不止是數(shù)據(jù)，還有靜態(tài)資源的讀取。

為什么要減少讀的次數(shù)呢，因?yàn)榫W(wǎng)絡(luò)傳輸是需要時(shí)間的，無(wú)論是請(qǐng)求、處理、響應(yīng)都需要服務(wù)器處理。如果存在必須讀取的情況，要減小數(shù)據(jù)請(qǐng)求和響應(yīng)的大小，數(shù)據(jù)在數(shù)據(jù)庫(kù)和各種服務(wù)之間調(diào)用的過(guò)程中存在序列化和反序列化的過(guò)程，這是很消耗資源的。

靜態(tài)資源的讀取比較常見(jiàn)的優(yōu)化手段就是合并CSS和JS文件，要保證請(qǐng)求的靜態(tài)文件在統(tǒng)一域名中，并減少訪問(wèn)次數(shù)。每次HTTP請(qǐng)求都存在網(wǎng)絡(luò)傳輸，減少耗時(shí)是很有必要的。

2.減少服務(wù)調(diào)用節(jié)點(diǎn)

這里提到的節(jié)點(diǎn)是指用戶請(qǐng)求后，直至響應(yīng)完成所經(jīng)歷的服務(wù)節(jié)點(diǎn)。不同節(jié)點(diǎn)間，尤其是不同機(jī)架，不同機(jī)房節(jié)點(diǎn)間的服務(wù)調(diào)用不僅僅耗時(shí)，還會(huì)降低秒殺的可靠性。

3.減少不必要的秒殺非核心業(yè)務(wù)

秒殺業(yè)務(wù)可以根據(jù)重要程度賦予權(quán)重，減少低權(quán)重服務(wù)的調(diào)用，以防止高權(quán)重系統(tǒng)被拖垮。秒殺活動(dòng)進(jìn)行時(shí)，有很多不是秒殺核心業(yè)務(wù)的數(shù)據(jù)可以通過(guò)降低優(yōu)先級(jí)進(jìn)行優(yōu)化，例如支付、通知等功能。

以上的原則并不是絕對(duì)的，只是在設(shè)計(jì)中努力優(yōu)化的方向。 

三、秒殺架構(gòu)的搭建思路

對(duì)于并發(fā)量訪問(wèn)較大的秒殺架構(gòu)，為了提高架構(gòu)性能和穩(wěn)定性，需要注意幾點(diǎn)：秒殺要獨(dú)立于其他系統(tǒng)，無(wú)論在研發(fā)和部署環(huán)節(jié)都要獨(dú)立，這樣有助于整體平臺(tái)的穩(wěn)定性，也有利于秒殺系統(tǒng)的優(yōu)化。秒殺的數(shù)據(jù)，尤其是核心數(shù)據(jù)單獨(dú)放到緩存系統(tǒng)中，提高并發(fā)，對(duì)于非核心數(shù)據(jù)可以放到本地，減少請(qǐng)求服務(wù)的次數(shù)。秒殺的頁(yè)面要實(shí)現(xiàn)動(dòng)靜分離，把頁(yè)面刷新頻率降低。

另外，從安全性角度考慮，秒殺的驗(yàn)證必不可少，限流保護(hù)更是重中之重。

這次要解決的是秒殺活動(dòng)中的動(dòng)靜分離方案。分離后的數(shù)據(jù)處理就簡(jiǎn)單了許多。

---

 

一、動(dòng)靜分離是什么？

動(dòng)靜分離就是并不是傳統(tǒng)意義的靜態(tài)頁(yè)面和動(dòng)態(tài)頁(yè)面，而是指是否需要根據(jù)發(fā)送請(qǐng)求的用戶進(jìn)行個(gè)性化數(shù)據(jù)的推送。舉個(gè)例子，在訪問(wèn)一些商城時(shí)，會(huì)針對(duì)不同用戶進(jìn)行商品的推薦，那么這樣的數(shù)據(jù)就是動(dòng)態(tài)數(shù)據(jù)；商城中有一些熱門(mén)的活動(dòng)，會(huì)針對(duì)所有用戶進(jìn)行推送，那么這樣的數(shù)據(jù)就是靜態(tài)數(shù)據(jù)，盡管這里的數(shù)據(jù)是動(dòng)態(tài)生成的。

二、優(yōu)化靜態(tài)數(shù)據(jù)：

首先，我們要做的就是優(yōu)化靜態(tài)數(shù)據(jù)，那就是通過(guò)緩存來(lái)提高靜態(tài)數(shù)據(jù)的讀取可以有效提高數(shù)據(jù)的訪問(wèn)，除此之外還要考慮將緩存服務(wù)根據(jù)業(yè)務(wù)需要放到用戶本地或CDN上。如何實(shí)現(xiàn)緩存將會(huì)在后續(xù)提到，我們現(xiàn)在可以認(rèn)為這里的緩存是一個(gè)Redis集群或其他緩存系統(tǒng)。

三、優(yōu)化動(dòng)態(tài)數(shù)據(jù)：

動(dòng)態(tài)數(shù)據(jù)主要包括服務(wù)端的時(shí)間，用戶數(shù)據(jù)等。我常用的方法是通過(guò)發(fā)起一個(gè)Ajax的異步請(qǐng)求，獲取動(dòng)態(tài)數(shù)據(jù)，這樣做的缺點(diǎn)是頁(yè)面存在延遲的話，體驗(yàn)不好。為了解決這個(gè)問(wèn)題，可以通過(guò)提前在頁(yè)面中的動(dòng)態(tài)數(shù)據(jù)展示部分做一個(gè)插槽，類似vue中的slot，緩解數(shù)據(jù)加載中的突兀感。

四、選擇適合的分離架構(gòu)：

接下來(lái)要介紹兩種分離架構(gòu)，一種是秒殺活動(dòng)不頻繁，秒殺商品數(shù)量少的場(chǎng)景，一種是秒殺活動(dòng)頻繁，秒殺商品數(shù)量多的場(chǎng)景。這里說(shuō)的兩種架構(gòu)需要結(jié)合自身業(yè)務(wù)作取舍，不要一味的追求高并發(fā)。

1.單機(jī)部署

這里提到的單機(jī)是將緩存在一臺(tái)性能較高的實(shí)體機(jī)中進(jìn)行分組，采用Hash算法。由于商品數(shù)量不多，緩存的命中率會(huì)大大提高。這既是有點(diǎn)也是缺點(diǎn)，提高命中的同時(shí)可能會(huì)存在緩存擊穿的風(fēng)險(xiǎn)。在訪問(wèn)量較大時(shí)，可以通過(guò)修改緩存算法或添加相同的緩存分組來(lái)緩解。

單機(jī)部署有效的回避了分布式網(wǎng)絡(luò)傳輸?shù)膯?wèn)題，提高了緩存的命中率。這樣做有效的降低了運(yùn)維的復(fù)雜程度，對(duì)于沒(méi)有分布式緩存系統(tǒng)的業(yè)務(wù)來(lái)說(shuō)，是一個(gè)很好的選擇。

2.緩存集群

在一些業(yè)務(wù)復(fù)雜、數(shù)據(jù)龐大的機(jī)構(gòu)中，可以考慮建立獨(dú)立的緩存系統(tǒng)，減少運(yùn)維成本，提高復(fù)用。這樣做的可以使開(kāi)發(fā)人員將重心放在業(yè)務(wù)中，不需要考慮緩存數(shù)據(jù)的處理；同時(shí)可以通過(guò)zookeeper實(shí)現(xiàn)配置自動(dòng)化；在不同秒殺活動(dòng)中，共享內(nèi)存，降低資源浪費(fèi)。

除此之外，CDN的優(yōu)化以后也會(huì)介紹。

五、緩存中的數(shù)據(jù)：

數(shù)據(jù)處理除了以上提到的動(dòng)靜分離，還需要進(jìn)行隔離。這么做的原因是不能讓秒殺活動(dòng)影響了其他業(yè)務(wù)，在秒殺期間減少對(duì)其他業(yè)務(wù)資源的占用。要做到這一點(diǎn)，除了要進(jìn)行系統(tǒng)隔離，還需要進(jìn)行數(shù)據(jù)的隔離，就像我們上一篇中提到的，要有獨(dú)立的數(shù)據(jù)存儲(chǔ)。實(shí)現(xiàn)數(shù)據(jù)隔離的方式有很多種，可以根據(jù)區(qū)域劃分、可以根據(jù)URL劃分等。

秒殺請(qǐng)求在高度集中在某一個(gè)時(shí)間點(diǎn)。這樣一來(lái)，就會(huì)導(dǎo)致一 個(gè)特別高的流量峰值，它對(duì)資源的消耗是瞬時(shí)的 。能夠搶到商品的人數(shù)是有限的，也就是說(shuō)10人和1000人發(fā) 起請(qǐng)求的結(jié)果都是一樣的。也就是說(shuō)真正開(kāi)始下單時(shí)，秒殺請(qǐng)求并不是越多越好。

---

一、秒殺中的削峰

由于服務(wù)器的處理資源是恒定的，用或者不用它的處理能力都是一樣的，出現(xiàn)峰值的話，很容易導(dǎo)致忙到處理不過(guò)來(lái)，閑的時(shí)候卻又沒(méi)有什么要處理。為了保證服務(wù)質(zhì)量，很多處理資源只能按照忙時(shí)預(yù)估，而這會(huì)導(dǎo)致資源浪費(fèi)。 削峰可以讓服務(wù)端處理變得更加平穩(wěn)，還可以節(jié)省服務(wù)器的資源成本。針對(duì)秒殺這一場(chǎng)景，削峰從本質(zhì)上來(lái)說(shuō)就是更多地延緩用戶請(qǐng)求的發(fā)出，以便減少和過(guò)濾掉一些無(wú)效請(qǐng)求。

常見(jiàn)秒殺流量削峰的一些操作思路：消息隊(duì)列、答題器、數(shù)據(jù)過(guò)濾。

1.消息隊(duì)列

其中最容易想到的解決方案就是用消息隊(duì)列來(lái)緩沖瞬時(shí)流量，把同步的直接調(diào)用轉(zhuǎn)換成異步的間接推送，通過(guò)隊(duì)列在一端承接瞬時(shí)的流量洪峰，在另一端平滑地將消息推送出去，在這里，消息隊(duì)列就像“水庫(kù)"一樣，攔蓄上游的洪水，削減進(jìn)入下游的洪峰流量。

但是，如果流量峰值持續(xù)時(shí)間達(dá)到了消息隊(duì)列的處理上限，消息隊(duì)列同樣也會(huì)被壓垮，這樣雖然保護(hù)了下游的系統(tǒng)，但是和直接把請(qǐng)求丟棄也沒(méi)多大的區(qū)別。就像遇到洪水爆發(fā)時(shí)，即使是有水庫(kù)恐怕也無(wú)濟(jì)于事。在這種情況下，我們要把“一步的操作”變成“兩步的操作”，其中增加的操作用來(lái)起到緩沖的作用，例如利用線程池加鎖等待、采用先進(jìn)先出、先進(jìn)后出等常用的內(nèi)存排隊(duì)算法。

2.答題器

添加答題器第一個(gè)目的是防止部分買(mǎi)家使用秒殺器在參加秒殺時(shí)作弊，第二個(gè)目的就是延緩請(qǐng)求，起到削峰的作用。把請(qǐng)求的時(shí)間從瞬時(shí)延長(zhǎng)到了幾秒，這樣會(huì)大大減輕對(duì)服務(wù)器的壓力。而且后續(xù)請(qǐng)求到達(dá)服務(wù)器時(shí)已經(jīng)沒(méi)有庫(kù)存了，真正的并發(fā)處理就很有限了。

答題器生成的題目不需要很復(fù)雜，為了防止被破解可以添加圖片噪點(diǎn)。同時(shí)在CDN上緩存圖片，避免成為秒殺活動(dòng)中的短板，影響用戶體驗(yàn)。

3.數(shù)據(jù)過(guò)濾

這里提到的數(shù)據(jù)過(guò)濾有點(diǎn)像某些企業(yè)在招聘時(shí)，把簡(jiǎn)歷隨機(jī)抽出一部分扔掉一樣，只不過(guò)抽取的過(guò)程可以設(shè)置一定的規(guī)則，過(guò)濾掉那些無(wú)效的請(qǐng)求。在不同的處理層根據(jù)不同的規(guī)則有效的過(guò)濾，例如對(duì)寫(xiě)數(shù)據(jù)進(jìn)行基于時(shí)間的合理分片，過(guò)濾掉過(guò)期的失效請(qǐng)求；對(duì)寫(xiě)數(shù)據(jù)進(jìn)行強(qiáng)一致性校驗(yàn)，只保留最后有效的數(shù)據(jù)。

這么做的目的是在讀系統(tǒng)中，盡量減少由于一致性校驗(yàn)帶來(lái)的系統(tǒng)瓶頸，但是盡量將不影響性能的檢查條件提前，如用戶是否具有秒殺資格、商品狀態(tài)是否正常、用戶答題是否正確、秒殺是否已經(jīng)結(jié)束、是否非法請(qǐng)求等；在寫(xiě)數(shù)據(jù)系統(tǒng)中，主要對(duì)寫(xiě)的數(shù)據(jù)做一致性檢查，最后在數(shù)據(jù)庫(kù)層保證數(shù)據(jù)的最終準(zhǔn)確性。

二、秒殺中的服務(wù)性能優(yōu)化

服務(wù)端性能， 一般用QPS來(lái)衡量， 還有一個(gè)和QPS息息相關(guān)的是響應(yīng)時(shí)間， 它可以理解為服務(wù)器處理響應(yīng)的耗時(shí)。

正常情況下響應(yīng)時(shí)間越短， 一秒鐘處理的請(qǐng)求數(shù)(QPS) 自然也就會(huì)越多， 這在單線程處理的情況下看起來(lái)是線性的關(guān)系，即我們只要把每個(gè)請(qǐng)求的響應(yīng)時(shí)間降到最低，那么性能就會(huì)最高。

這個(gè)兩個(gè)因素到底會(huì)造成什么樣的影響？首先， 我們先來(lái)看看響應(yīng)時(shí)間和QPS的關(guān)系，對(duì)于大部分的Web系統(tǒng)而言響應(yīng)時(shí)間一般都是由CPU執(zhí)行時(shí)間和線程等待時(shí)間組成，也許你會(huì)說(shuō)為什么不去減少這種等待時(shí)間，其實(shí)減少線程等待時(shí)間對(duì)提升性能的影響沒(méi)有我們想象得那么大， 這點(diǎn)在很多代理服務(wù)器上可以做驗(yàn)證，如果代理服務(wù)器本身沒(méi)有CPU消耗， 我們?cè)诿看谓o代理服務(wù)器代理的請(qǐng)求加個(gè)延時(shí)， 即增加響應(yīng)時(shí)間，這對(duì)代理服務(wù)器本身的吞吐量并沒(méi)有多大的影響，因?yàn)榇矸?wù)器本身的資源并沒(méi)有被消耗。

真正對(duì)性能有影響的是CPU的執(zhí)行時(shí)間， 因?yàn)镃PU的執(zhí)行真正消耗了服務(wù)器的資源， 我們應(yīng)該致力于減少CPU的執(zhí)行時(shí)間。

對(duì)于Java系統(tǒng)可優(yōu)化的地方很多，除了常見(jiàn)的代碼優(yōu)化外，以下的內(nèi)容值得注意。

Java和通用的Web服務(wù)器相比，在處理大并發(fā)的HTTP請(qǐng)求時(shí)要弱一點(diǎn)， 所以一般我們都會(huì)對(duì)大流量的Web系統(tǒng)做靜態(tài)化改造，讓大部分請(qǐng)求和數(shù)據(jù)直接在Nginx服務(wù)器或者Web代理服務(wù)器上直接返回 ， 而Java層只需處理少量數(shù)據(jù)的動(dòng)態(tài)請(qǐng)求。

針對(duì)這些請(qǐng)求， 我們可以使用以下手段進(jìn)行優(yōu)化：

1.直接使用Servlet處理請(qǐng)求， 避免使用傳統(tǒng)的MVC框架， 這樣可以繞過(guò)一大堆復(fù)雜且用處不大的處理邏輯， 直接輸出流數(shù)據(jù)。使用resp.getOutputStream)而不是resp.get Writer函數(shù)， 可以省掉一些不變字符數(shù)據(jù)的編碼， 從而提升性能。

2.數(shù)據(jù)輸出時(shí)推薦使用JSON而不是模板引擎來(lái)輸出頁(yè)面。

3.集中式緩存為了保證命中率一般都會(huì)采用一致性Hash， 所以同一個(gè)key會(huì)落到同一臺(tái)機(jī)器上。那么，該如何徹底解決單點(diǎn)的瓶頸呢? 答案是采用應(yīng)用層的Local Cache。你需要?jiǎng)澐殖蓜?dòng)態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)。

像商品中的標(biāo)題和描述這些本身不變的數(shù)據(jù)，會(huì)在秒殺開(kāi)始之前全量推送到緩存直到到秒殺結(jié)束。

像庫(kù)存這類動(dòng)態(tài)數(shù)據(jù)的方式緩存一定時(shí)間，失效后再去緩存拉取最新的。你可能還會(huì)有疑問(wèn)：像庫(kù)存這種頻繁更新的數(shù)據(jù)，一旦數(shù)據(jù)不一致，會(huì)不會(huì)導(dǎo)致超賣? 這就要用到前面介紹的讀數(shù)據(jù)的分層原則了，讀的場(chǎng)景可以允許一定的臟數(shù)據(jù)，因?yàn)檫@里的誤判只會(huì)導(dǎo)致少量原本無(wú)庫(kù)存的下單請(qǐng)求被誤認(rèn)為有庫(kù)存，可以等到真正寫(xiě)數(shù)據(jù)時(shí)再保證最終的一致性。 

如果你第一次接觸秒殺，可能還不太理解，庫(kù)存100件就賣100件，在數(shù)據(jù)庫(kù)里減到0就好了，這有什么麻煩的?理論上是這樣，但是具體到業(yè)務(wù)場(chǎng)景中就沒(méi)那么簡(jiǎn)單了。今天就聊聊減庫(kù)存的設(shè)計(jì)，之后以高可用方案來(lái)結(jié)束秒殺設(shè)計(jì)的全部?jī)?nèi)容。

---

一、秒殺中的減庫(kù)存

減庫(kù)存操作一般有如下幾個(gè)方式：

1.下單減庫(kù)存：下單后，在商品的總庫(kù)存中減去購(gòu)買(mǎi)數(shù)量，下單減庫(kù)存是最簡(jiǎn)單的減庫(kù)存方式，也是控制最精確的一種，下單時(shí)直接通過(guò)數(shù)據(jù)庫(kù)的事務(wù)機(jī)制控制商品庫(kù)存，這樣一定不會(huì)出現(xiàn)超賣的情況。

2.付款減庫(kù)存：下單后，并不立即減庫(kù)存，而是等到付款后才真正減庫(kù)存，否則庫(kù)存一直保留給其他買(mǎi)家，但因?yàn)楦犊顣r(shí)才減庫(kù)存，如果并發(fā)比較高，有可能出現(xiàn)買(mǎi)家下單后付不了款的情況，可能商品已經(jīng)被其他人買(mǎi)走了。

3.預(yù)扣庫(kù)存：下單后，庫(kù)存為其保留一定的時(shí)間， 超過(guò)這個(gè)時(shí)間，庫(kù)存將會(huì)自動(dòng)釋放，釋放后其他買(mǎi)家就可以繼續(xù)購(gòu)買(mǎi)，在買(mǎi)家付款前，系統(tǒng)會(huì)校驗(yàn)該庫(kù)存是否還有保留，如果沒(méi)有保留，則再次嘗試預(yù)扣；如果庫(kù)存不足則不允許繼續(xù)付款；如果預(yù)扣成功，則完成付款并實(shí)際地減去庫(kù)存，這種方式相對(duì)復(fù)雜一些。

以上這幾種減庫(kù)存的方式都會(huì)存在一些問(wèn)題。  假如我們采用“下單減庫(kù)存”的方式，正常情況下，買(mǎi)家下單后付款的概率會(huì)很高，所以不會(huì)有太大問(wèn)題，但是有一種場(chǎng)景例外，就是當(dāng)賣家參加某個(gè)活動(dòng)時(shí)，此時(shí)活動(dòng)的有效時(shí)間是商品的黃金售賣時(shí)間，通過(guò)惡意下單的方式將該賣家的商品全部下單，那么這款商品就不能正常售賣了。要知道，這些惡意下單的人是不會(huì)真正付款的。

既然“下單減庫(kù)存”可能導(dǎo)致惡意下單，從而影響賣家的商品銷售，那么有沒(méi)有辦法解決呢?你可能會(huì)想，采用“付款減庫(kù)存”的方式是不是就可以了?的確可以，但是 “付款減庫(kù)存”又會(huì) 導(dǎo)致另外一個(gè)問(wèn)題：庫(kù)存超賣。假如有10件商品，因?yàn)橄聠螘r(shí)不會(huì)減庫(kù)存，就可能出現(xiàn)100人下單成功的情況，這樣一 來(lái)，就會(huì)導(dǎo)致很多買(mǎi)家下單成功但是付不了款，購(gòu)物體驗(yàn)自然比較差。

既然“下單減庫(kù)存”和“付款減庫(kù)存”都有缺點(diǎn)，我們能否采用“預(yù)扣庫(kù)存”這種方式呢? 這種方案確實(shí)可以在一定程度上緩解上面的問(wèn)題，但是否就徹底解決了呢?針對(duì)惡意 下單這種情況，雖然把有效的付款時(shí)間設(shè)置為10分鐘，但是惡意買(mǎi)家完全可以在10分鐘后再次下單。

針對(duì)這種情況，解決辦法還是要結(jié)合反作弊的措施來(lái)制止， 例如，設(shè)置最大購(gòu)買(mǎi)件數(shù)，對(duì)重復(fù)下單不付款的操作進(jìn)行次數(shù)限制等。針對(duì)“庫(kù)存超賣”這種情況，在10分鐘時(shí)間內(nèi)下單的數(shù)量仍然有可能超過(guò)庫(kù)存數(shù)量，遇到這種情況只能區(qū)別對(duì)待：對(duì)普通的商品下單數(shù)量超過(guò)庫(kù)存數(shù)量的情況，可以通過(guò)補(bǔ)貨來(lái)解決；但是有些賣家完全不允許庫(kù)存為負(fù)數(shù)的情況，那只能在買(mǎi)家付款時(shí)提示庫(kù)存不足。

由于參加秒殺的商品成功下單后卻不付款的情況比較少，再加上賣家對(duì)秒殺商品的庫(kù)存有嚴(yán)格限制，所以秒殺商品采用“下單減庫(kù)存”更加合理。一般我們有多種解決方案：一種是在應(yīng)用程序中通過(guò)事務(wù)來(lái)判斷，即保證減后庫(kù)存不能為負(fù)數(shù)，否則就回滾；另一種辦法是直接設(shè)置數(shù)據(jù)庫(kù)的字段數(shù)據(jù)為 無(wú)符號(hào)整數(shù)， 這樣減后庫(kù)存字段值小于零時(shí)會(huì)直接執(zhí)行SQL語(yǔ)句來(lái)報(bào)錯(cuò)。 

二、秒殺中的高可用

高可用涉及架構(gòu)階段、編碼階段、測(cè)試階段、運(yùn)行階段。

1.架構(gòu)階段：架構(gòu)階段主要考慮系統(tǒng)的可擴(kuò)展性和容錯(cuò)性，要避免系統(tǒng)出現(xiàn)單點(diǎn)問(wèn)題，例如多機(jī)房部署，即使某個(gè)機(jī)房出現(xiàn)整體故障，仍然不會(huì)影響整體網(wǎng)站的運(yùn)轉(zhuǎn)。

2.編碼階段：編碼最重要的是保證代碼的健壯性，例如涉及遠(yuǎn)程調(diào)用問(wèn)題時(shí)，要設(shè)置合理的超時(shí)退出機(jī)制，防止被其他系統(tǒng)拖垮。

3.測(cè)試階段：測(cè)試主要是保證測(cè)試用例的覆蓋度，保證最壞情況發(fā)生時(shí)，我們也有相應(yīng)的處理流 程。

4.運(yùn)行階段：系統(tǒng)大部分時(shí)間都會(huì)處于運(yùn)行態(tài)，運(yùn)行態(tài)最重要的是對(duì)系統(tǒng)的監(jiān)控要準(zhǔn)確及時(shí)，發(fā)現(xiàn)問(wèn)題能夠準(zhǔn)確報(bào)警并且報(bào)警數(shù)據(jù)要準(zhǔn)確詳細(xì)，以便于排查問(wèn)題。

 為什么系統(tǒng)的高可用建設(shè)要放到整個(gè)生命周期中全面考慮?因?yàn)槲覀冊(cè)诿總€(gè)環(huán)節(jié)中都可能犯錯(cuò)， 而有些環(huán)節(jié)犯的錯(cuò)是無(wú)法彌補(bǔ)的。例如在架構(gòu)階段，沒(méi)有消除單點(diǎn)問(wèn)題，那么系統(tǒng) 上線后，遇到突發(fā)流量把單點(diǎn)給掛了，加機(jī)器都加不進(jìn)去。

那么針對(duì)秒殺系統(tǒng)，我們重點(diǎn)介紹在遇到大流量時(shí)，應(yīng)該從哪些方面來(lái)保障系統(tǒng)的穩(wěn)定運(yùn)行，所 以更多的是看如何針對(duì)運(yùn)行階段進(jìn)行處理，這就引出了接下來(lái)的內(nèi)容：降級(jí)、限流。

降級(jí)：就是當(dāng)系統(tǒng)的容量達(dá)到一定程度時(shí)，限制或者關(guān)閉系統(tǒng)的某些非核心功能，從而把有限的資源保留給更核心的業(yè)務(wù)。降級(jí)方案可以這樣設(shè)計(jì)：當(dāng)秒殺流量達(dá)到5w/s時(shí)，把成交記錄的獲取從展示20條降級(jí)到只展示5條。 

執(zhí)行降級(jí)無(wú)疑是在系統(tǒng)性能和用戶體驗(yàn)之間選擇了前者，降級(jí)后肯定會(huì)影響一部分用戶的體驗(yàn)，。 所以降級(jí)的核心目標(biāo)是犧牲次要的功能和用戶體驗(yàn)來(lái)保證核心業(yè)務(wù)流程的穩(wěn)定，是一個(gè)不得已而 為之的舉措。

限流： 如果說(shuō)降級(jí)是犧牲了一部分次要的功能和用戶的體驗(yàn)效果，那么限流就是更極端的一種保護(hù)措施 了。限流就是當(dāng)系統(tǒng)容量達(dá)到瓶頸時(shí)，我們需要通過(guò)限制一部分流量來(lái)保護(hù)系統(tǒng)，并做到既可以人工執(zhí)行開(kāi)關(guān)，也支持自動(dòng)化保護(hù)的措施。

首先，來(lái)分別說(shuō)下客戶端限流和服務(wù)端限流的優(yōu)缺點(diǎn)。 客戶端限流，好處可以限制請(qǐng)求的發(fā)出，通過(guò)減少發(fā)出無(wú)用請(qǐng)求從而減少對(duì)系統(tǒng)的消耗，缺點(diǎn) 就是當(dāng)客戶端比較分散時(shí)，沒(méi)法設(shè)置合理的限流閾值。如果閾值設(shè)的太小，會(huì)導(dǎo)致服務(wù)端沒(méi)有 達(dá)到瓶頸時(shí)客戶端已經(jīng)被限制；而如果設(shè)的太大，則起不到限制的作用。 服務(wù)端限流，好處是可以根據(jù)服務(wù)端的性能設(shè)置合理的閾值，而缺點(diǎn)就是被限制的請(qǐng)求都是無(wú)效的請(qǐng)求，處理這些無(wú)效的請(qǐng)求本身也會(huì)消耗服務(wù)器資源。