自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

秒殺系統(tǒng)瞬時(shí)百萬并發(fā)流量的六種應(yīng)對之道

開發(fā) 架構(gòu)
主要是對秒殺系統(tǒng)高并發(fā)大流量的挑戰(zhàn)給出了應(yīng)對之道,從總體上說,我們應(yīng)對秒殺系統(tǒng)挑戰(zhàn)時(shí),心中要有一桿秤,在設(shè)計(jì)秒殺系統(tǒng)時(shí),一定要做到分離、削峰限流、快速響應(yīng)、準(zhǔn)確一致、穩(wěn)定可靠、全鏈路壓測。

架構(gòu)

  • 本章難度:★★★☆☆
  • 本章重點(diǎn):全面闡述建設(shè)秒殺系統(tǒng)挑戰(zhàn)的應(yīng)對之道,知己知彼,方案了然于胸,自然有應(yīng)對之道。經(jīng)過長期秒殺大促的沉淀與總結(jié),針對秒殺系統(tǒng)存在高并發(fā)大流量的挑戰(zhàn),冰河沉淀出六種應(yīng)對之道:分離、限流、快速響應(yīng)、準(zhǔn)確一致、穩(wěn)定可靠、全鏈路壓測。

大家好,我是冰河~~

雖然建設(shè)秒殺系統(tǒng)的過程中存在著諸多的挑戰(zhàn),但是這些挑戰(zhàn)都是有應(yīng)對之道的,對于整個(gè)過程中遇到的難點(diǎn)和痛點(diǎn),都是會沉淀出對應(yīng)的解決方案。

一、前言

在前面的文章中,詳細(xì)闡述了建設(shè)秒殺系統(tǒng)的目標(biāo)與存在的挑戰(zhàn),并且簡單羅列了如何應(yīng)對這些挑戰(zhàn)的方式。本章,就詳細(xì)闡述對秒殺系統(tǒng)存在挑戰(zhàn)的應(yīng)對之道,最終構(gòu)建出兼具高并發(fā)、高性能和高可用的秒殺系統(tǒng)。心中不僅了解建設(shè)秒殺系統(tǒng)存在的挑戰(zhàn),更清楚的知道這些挑戰(zhàn)的應(yīng)對之道,正所謂:知己知彼,百戰(zhàn)不殆,方案了然于胸,自然有應(yīng)對之法。

二、本章訴求

一般一套成熟并且穩(wěn)定、經(jīng)得起實(shí)際大促場景考驗(yàn)的秒殺系統(tǒng),都是經(jīng)過不斷迭代、優(yōu)化和演化而來的。對于設(shè)計(jì)和研發(fā)秒殺系統(tǒng)的技術(shù)人員來說,心中一定要清晰的知曉建設(shè)秒殺系統(tǒng)存在的挑戰(zhàn),以及針對這些挑戰(zhàn)的應(yīng)對之法。

三、應(yīng)對之道

對于秒殺系統(tǒng),站在技術(shù)人員的角度,相信大家多多少少對秒殺系統(tǒng)有所了解了。既然建設(shè)秒殺系統(tǒng)存在著種種的困難和挑戰(zhàn),那我們就需要從整體上分析這些挑戰(zhàn)的應(yīng)對之法,而不是在真正開發(fā)秒殺系統(tǒng)時(shí),再去臨時(shí)想方案,查漏補(bǔ)缺,切忌頭痛醫(yī)頭、腳痛醫(yī)腳。

從總體上說,我們應(yīng)對秒殺系統(tǒng)挑戰(zhàn)時(shí),心中要有一桿秤,在設(shè)計(jì)秒殺系統(tǒng)時(shí),一定要做到分離、削峰限流、快速響應(yīng)、準(zhǔn)確一致、穩(wěn)定可靠、全鏈路壓測。

圖片

接下來,就針對每種應(yīng)對之道進(jìn)行詳細(xì)的闡述。

四、分離之道

分離之道中,重點(diǎn)在于一個(gè)“分”字,主要包括:前后端資源分離、接口分離,數(shù)據(jù)分離、業(yè)務(wù)分離、系統(tǒng)分離、流量分離。

圖片

4.1 資源分離

資源分離,主要指的是前后端的資源分離。目前,除了一些非常老舊的系統(tǒng)之外,一般在開發(fā)互聯(lián)網(wǎng)項(xiàng)目過程中,都會采用前后端分離的架構(gòu)模式,這也是比較普遍的做法。在秒殺系統(tǒng)中,將前端資源分離出來,部署時(shí)可以直接推送到CDN服務(wù)器,CDN服務(wù)器全國各地都有,用戶在訪問系統(tǒng)時(shí),可以從就近的CDN服務(wù)器上拉取對應(yīng)的資源,能夠極大的增強(qiáng)系統(tǒng)的性能。

4.2 接口分離

接口分離包含兩個(gè)方面:一個(gè)是秒殺接口與其他接口分離,一個(gè)是高頻訪問接口與低頻訪問接口分離。

對于秒殺系統(tǒng)的接口來說,在設(shè)計(jì)上一定要與其他的接口進(jìn)行分離,不要讓秒殺系統(tǒng)的接口與其他業(yè)務(wù)的接口互相關(guān)聯(lián)引用,避免秒殺系統(tǒng)的瞬時(shí)高并發(fā)流量對其他接口造成影響。

就秒殺系統(tǒng)而言,并不是每個(gè)接口的訪問頻次都一樣,一本情況下,商品詳情頁、結(jié)算頁和秒殺下單接口的訪問頻次要遠(yuǎn)遠(yuǎn)大于支付接口的訪問頻次。在設(shè)計(jì)上一定要將這些接口進(jìn)行區(qū)分隔離,對高頻訪問的接口進(jìn)行單獨(dú)的性能優(yōu)化。

4.3 數(shù)據(jù)分離

數(shù)據(jù)分離也會包含兩個(gè)方面:一個(gè)是秒殺數(shù)據(jù)與其他數(shù)據(jù)分離,一個(gè)是動(dòng)態(tài)數(shù)據(jù)與靜態(tài)數(shù)據(jù)分離。

一般情況下,秒殺數(shù)據(jù)瞬時(shí)的增長率會遠(yuǎn)遠(yuǎn)大于其他數(shù)據(jù),在數(shù)據(jù)上進(jìn)行分離,可以對秒殺數(shù)據(jù)的存儲設(shè)施進(jìn)行單獨(dú)的針對性優(yōu)化,不能讓秒殺數(shù)據(jù)對其他數(shù)據(jù)產(chǎn)生影響,在數(shù)據(jù)層面對秒殺系統(tǒng)進(jìn)行專有部署。

就秒殺系統(tǒng)而言,本身也會存在著動(dòng)態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)。動(dòng)態(tài)數(shù)據(jù)在秒殺期間會容易發(fā)生變更,比如秒殺系統(tǒng)的品類、商品的庫存和上下架的狀態(tài)等,都是的動(dòng)態(tài)數(shù)據(jù),這些動(dòng)態(tài)數(shù)據(jù)對時(shí)間比較敏感。而像秒殺結(jié)果等與用戶本身相關(guān)的一些數(shù)據(jù),可以稱為靜態(tài)數(shù)據(jù),因?yàn)檫@些數(shù)據(jù)在整個(gè)秒殺活動(dòng)期間,基本不會發(fā)生變化。

在設(shè)計(jì)上,需要對這些動(dòng)態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)進(jìn)行分離,因?yàn)閿?shù)據(jù)的更新頻率不同,在優(yōu)化手段和架構(gòu)設(shè)計(jì)上也會存在著差異。對動(dòng)態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)進(jìn)行分離后,也可以將服務(wù)端產(chǎn)生的靜態(tài)數(shù)據(jù)推送到CDN。

4.4 業(yè)務(wù)分離

秒殺業(yè)務(wù)不同于普通的商城業(yè)務(wù),秒殺業(yè)務(wù)的特點(diǎn)就是流量大、持續(xù)的時(shí)間短,在設(shè)計(jì)秒殺系統(tǒng)時(shí),需要充分考慮到不同業(yè)務(wù)之間的影響,做到秒殺業(yè)務(wù)與其他業(yè)務(wù)之間的分離。

4.5 系統(tǒng)分離

秒殺系統(tǒng)與其他系統(tǒng)不同,秒殺系統(tǒng)需要承接瞬時(shí)高并發(fā)流量,而其他大部分系統(tǒng)的流量則比較平緩。一旦將秒殺系統(tǒng)和其他業(yè)務(wù)系統(tǒng)部署到一起的話,勢必會對其他業(yè)務(wù)系統(tǒng)造成比較大的影響,所以,需要將秒殺系統(tǒng)與其他業(yè)務(wù)系統(tǒng)進(jìn)行分離處理。

在系統(tǒng)分離層面,一般在大廠的秒殺系統(tǒng)中會將秒殺詳情頁系統(tǒng)、秒殺結(jié)算頁系統(tǒng)、購物車系統(tǒng)和訂單系統(tǒng)進(jìn)行分離,并且會申請單獨(dú)的域名和負(fù)載均衡器等,并且會對相應(yīng)的微服務(wù)集群進(jìn)行分組隔離。

4.6 流量分離

看到這里,相信大家對秒殺系統(tǒng)的印象更加深刻了。沒錯(cuò),秒殺系統(tǒng)的瞬時(shí)流量是巨大的,如果秒殺系統(tǒng)的流量與其他業(yè)務(wù)系統(tǒng)的流量不加以分離處理,其他系統(tǒng)勢必會由于巨大的瞬時(shí)流量而導(dǎo)致各種連鎖問題,所以,在設(shè)計(jì)上,務(wù)必將秒殺系統(tǒng)與其他業(yè)務(wù)系統(tǒng)的流量進(jìn)行分離。

五、限流之道

限流主要是對流量進(jìn)行限制,對于秒殺這種業(yè)務(wù)場景來說,流量是瞬時(shí)且巨大的,期間流量會在幾秒鐘之內(nèi)爬升到峰值,然后馬上又掉下來,形成巨大的毛刺峰值,對系統(tǒng)費(fèi)資源的消耗也是瞬時(shí)且巨大的,需要對這些流量進(jìn)行限制和管控。通常的應(yīng)對方法主要有:提前預(yù)約秒殺、打散客戶端流量、消息隊(duì)列、網(wǎng)關(guān)限流、API限流、應(yīng)用層限流、安全校驗(yàn)、活動(dòng)校驗(yàn),秒殺商品校驗(yàn)、秒殺資格校驗(yàn)、風(fēng)控校驗(yàn),大廠策略。

圖片

5.1 提前預(yù)約秒殺

為秒殺系統(tǒng)設(shè)計(jì)一個(gè)預(yù)約功能,或者單獨(dú)設(shè)計(jì)一個(gè)預(yù)約系統(tǒng),用戶要想?yún)⑴c秒殺搶購,則需要提前預(yù)約商品的搶購,這樣可以在參與搶購的用戶基數(shù)上進(jìn)行控制,能夠提前鎖定參與秒殺搶購的用戶,而不是整個(gè)平臺中所有的用戶都能參與搶購。這樣可以通過將搶購的用戶訪問控制在預(yù)約人數(shù)之內(nèi),在一定程度上能夠大大減少秒殺的峰值流量,對秒殺系統(tǒng)起到一定的防護(hù)作用。

5.2 打散客戶端流量

一般秒殺系統(tǒng)的客戶端也會包含:PC、H5、App和小程序,作為秒殺流量的入口,可以在這些入口端設(shè)置答題、驗(yàn)證碼和滑塊等方式將流量打散,因?yàn)槊總€(gè)人輸入問答題答案、驗(yàn)證碼和滑塊的手速不同,就會將瞬時(shí)的大并發(fā)流量分散到一小段時(shí)間內(nèi)。在秒殺的場景中,不要小看這些處理方式,即使將流量分?jǐn)偟揭幻牖蛘邘装俸撩氲臅r(shí)間內(nèi),也會將流量峰值降低一個(gè)甚至幾個(gè)量級。

例如,在沒有將客戶端瀏覽打散的情況下,流量峰值為100萬QPS,使用答題、驗(yàn)證碼和滑塊的方式將流量打散后,流量峰值可能就會下降到80萬QPS、60萬QPS甚至更低,對秒殺系統(tǒng)能過起到有效的防護(hù)作用。

另外,使用問答題、驗(yàn)證碼和滑塊的方式也能夠快速攔截部分刷單流量、防止機(jī)器作弊,起到一定的防刷作用。

注意:目前像阿里這樣的頭部電商平臺,已經(jīng)不會在客戶端使用問答題、驗(yàn)證碼和滑塊等方式將流量打散,更傾向于采用非公平的策略,使用有損逐級限流和分層過濾的方式來達(dá)到系統(tǒng)限流的目的。

5.3 消息隊(duì)列

使用消息隊(duì)列來削峰填谷,通過消息隊(duì)列可以將同步的請求改造成異步請求,將超過下游系統(tǒng)處理范圍的流量暫時(shí)存入消息隊(duì)列中,下游的系統(tǒng)可以根據(jù)自身處理數(shù)據(jù)的性能來消費(fèi)隊(duì)列中的數(shù)據(jù)。

使用消息隊(duì)列對搶購下單異步化之后,前端不能及時(shí)知曉秒殺的結(jié)果數(shù)據(jù),需要前端定期查詢秒殺的結(jié)果數(shù)據(jù)反饋給用戶。在使用消息隊(duì)列設(shè)計(jì)異步搶購流程時(shí),有個(gè)小技巧:就是前面的請求將商品的庫存消耗完之后,在商品庫存的緩存中設(shè)置一個(gè)特殊占位符,讓后續(xù)的請求能夠快速失敗,而不再進(jìn)行后續(xù)的業(yè)務(wù)邏輯處理。

可以使用RocketMQ、Kafka和RabbitMQ等消息中間件來實(shí)現(xiàn)請求的異步化和削峰填空,具體使用哪種消息中間件可以根據(jù)自身業(yè)務(wù)進(jìn)行實(shí)際評估。

5.4 網(wǎng)關(guān)限流

網(wǎng)關(guān)一般是一個(gè)系統(tǒng)的入口,可以在網(wǎng)關(guān)層對流量進(jìn)行限流,對超出當(dāng)前系統(tǒng)流量閾值的請求根據(jù)一定的策略進(jìn)行處理,例如拒絕超出當(dāng)前系統(tǒng)流量閾值的請求,快速返回失敗,也可以將超出閾值的流量緩存起來進(jìn)行排隊(duì),按照一定的順序消費(fèi)這些請求,會對下游的業(yè)務(wù)系統(tǒng)起到一定的防護(hù)作用。

5.5 API限流

API限流也就是對接口進(jìn)行限流,可以使用Google提供的RateLimiter開源包,實(shí)現(xiàn)對應(yīng)的限流策略,在系統(tǒng)中具體的API代碼里進(jìn)行限流。這種方式可以做到針對特定的API接口進(jìn)行限流。

5.6 應(yīng)用層限流

應(yīng)用層的限流可以通過對線程池的限流來實(shí)現(xiàn),實(shí)現(xiàn)線程池的限流時(shí),主要是設(shè)置并發(fā)數(shù)限流,可以通過自定義線程池,配置最大的連接數(shù),以請求隊(duì)列的長度和拒絕策略等參數(shù)進(jìn)行限流,如果隊(duì)列已滿,并且已經(jīng)達(dá)到最大的線程數(shù),多余的請求就會根據(jù)具體的拒絕策略進(jìn)行處理,以達(dá)到限流的目的和效果。

5.7 安全校驗(yàn)

安全校驗(yàn)就是要識別出請求的流量哪些是安全流量,哪些是不安全的流量,這里說的不安全的流量指的是友商、黃牛黨或者不懷好意的用戶發(fā)起的刷單流量、CC攻擊等,這種流量對系統(tǒng)是有害的,能夠消耗大量的系統(tǒng)資源,為系統(tǒng)造成比較大的壓力,并且這種方式擠占了正常搶購的通道,對正常參與秒殺活動(dòng)的用戶是不公平的。

5.8 活動(dòng)校驗(yàn)

活動(dòng)校驗(yàn)就是接收到請求時(shí),對活動(dòng)數(shù)據(jù)進(jìn)行校驗(yàn),核對活動(dòng)是否已經(jīng)結(jié)束、是否下架等等,如果活動(dòng)已經(jīng)結(jié)束或者已經(jīng)下架,則在緩存中設(shè)置特殊的占位符,對后續(xù)的請求進(jìn)行快速失敗處理,不再進(jìn)行后續(xù)的邏輯處理。

做活動(dòng)校驗(yàn)的原因是用戶在客戶端看到活動(dòng)有效,當(dāng)流量達(dá)到服務(wù)端時(shí),活動(dòng)可能已經(jīng)結(jié)束或者失效了,所以需要做活動(dòng)的校驗(yàn)處理。

5.9 秒殺品校驗(yàn)

秒殺品校驗(yàn)就是在接收到請求時(shí),對當(dāng)前的商品信息進(jìn)行校驗(yàn),核對當(dāng)前商品是否有效,庫存是否充足等。如果商品不再有效、或者庫存已經(jīng)消耗完畢,則在緩存中設(shè)置特殊的占位符,對后續(xù)的請求進(jìn)行快速失敗處理,不再進(jìn)行后續(xù)的邏輯處理。

做秒殺品校驗(yàn)的原因是用戶在客戶端看到活動(dòng)有效,當(dāng)流量達(dá)到服務(wù)端時(shí),秒殺品可能已經(jīng)結(jié)束或者失效了,所以需要做秒殺品的校驗(yàn)處理。

5.10 秒殺資格校驗(yàn)

秒殺資格校驗(yàn)主要是對參與秒殺的用戶的資格進(jìn)行校驗(yàn),比如設(shè)計(jì)了預(yù)約環(huán)節(jié)時(shí),只有提前預(yù)約過秒殺搶購的用戶才能參與秒殺。再比如,針對當(dāng)前活動(dòng)設(shè)置了只能秒殺一次的用戶,如果當(dāng)前用戶存在本次活動(dòng)的秒殺記錄,就不再允許二次秒殺等等。還有就是如果對秒殺品設(shè)置了只針對某些地區(qū)開放秒殺活動(dòng),則需要判斷用戶的所在地是否在開放的地區(qū),如果不在開放秒殺的地區(qū),則不允許搶購等等。

另外,在秒殺的資格校驗(yàn)上,可能存在同一個(gè)用戶不斷偽造請求的現(xiàn)象,需要加強(qiáng)用戶唯一身份的校驗(yàn)等邏輯。

5.11 風(fēng)控校驗(yàn)

一個(gè)成熟穩(wěn)定的秒殺系統(tǒng)的背后會接入風(fēng)控系統(tǒng),對整個(gè)秒殺活動(dòng)進(jìn)行風(fēng)控處理,風(fēng)控系統(tǒng)的建設(shè)不是一朝一夕就能完成的,建立風(fēng)控的過程也是比較困難的,這需要建立在大量數(shù)據(jù)的基礎(chǔ)之上,不斷的完善用戶的畫像,需要通過復(fù)雜的業(yè)務(wù)場景的考驗(yàn),不斷的修正風(fēng)控模型。

5.12 大廠策略

像阿里這種頭部互聯(lián)網(wǎng)公司,其秒殺系統(tǒng)處了會使用上述限流之道進(jìn)行系統(tǒng)限流外,其處于兼顧用戶體驗(yàn)和系統(tǒng)資源的考慮,一般不會采用問答題、驗(yàn)證碼或者滑塊的方式來打散客戶端流量,更傾向于采用非公平的策略,使用有損逐級限流和分層過濾的方式來達(dá)到系統(tǒng)限流的目的。

六、快速響應(yīng)之道

秒殺的場景雖然是高并發(fā)、大流量的業(yè)務(wù)場景,但是在秒殺場景中,需要快速響應(yīng)用戶的請求,不能讓用戶出現(xiàn)長時(shí)間等待的情況,這就需要在秒殺系統(tǒng)的設(shè)計(jì)上采用一定的策略。對于快速響應(yīng)來說,可以從多用緩存、本地緩存、分布式緩存、數(shù)據(jù)盡量少、計(jì)算盡量少和流程盡量簡單幾個(gè)方面進(jìn)行設(shè)計(jì)。

圖片

6.1 多用緩存

像秒殺這種在高并發(fā)大流量場景下要求極致體驗(yàn)的系統(tǒng),緩存是必不可少的,無論是對前端資源還是對后端數(shù)據(jù)來說,使用緩存都能夠極大的提升系統(tǒng)的性能。同時(shí),使用緩存也能夠?qū)ο到y(tǒng)進(jìn)行一定的防護(hù)。

如果系統(tǒng)中沒有使用緩存,或者發(fā)生了緩存穿透或者雪崩,瞬時(shí)的大量請求直接打到數(shù)據(jù)庫,那數(shù)據(jù)庫連接會被瞬間耗盡而導(dǎo)致不可用,進(jìn)而導(dǎo)致嚴(yán)重的連鎖反應(yīng),整個(gè)系統(tǒng)都會被拖垮,所以,使用緩存是非常重要的。

6.2 本地緩存

在秒殺系統(tǒng)中,為了進(jìn)一步提升系統(tǒng)的性能,會將一部分非常熱點(diǎn)的數(shù)據(jù)緩存在本地的JVM內(nèi)存中,接收到請求后,會先從本地緩存中獲取數(shù)據(jù),如果本地緩存不存在要獲取的數(shù)據(jù),就會到分布式緩存中進(jìn)行查詢。

6.3 分布式緩存

除了本地緩存外,分布式緩存也是秒殺系統(tǒng)必不可少的,本地緩存的數(shù)據(jù)有限,只能緩存一部分極度熱點(diǎn)的數(shù)據(jù),并且這些極度熱點(diǎn)的數(shù)據(jù)開始在本地緩存中也不一定存在,這就需要分布式緩存的存在,如果本地緩存中沒有數(shù)據(jù),就到分布式緩存查詢,盡最大努力提升系統(tǒng)的性能。

6.4 數(shù)據(jù)盡量少

對于提升系統(tǒng)的響應(yīng)性能來說,光有緩存還不夠,還要在處理的數(shù)據(jù)上要盡量少,不要查詢或者返回?zé)o關(guān)緊要的數(shù)據(jù)。因?yàn)榫彺嬷皇翘嵘薎O的執(zhí)行效率,但是除了要提升IO的執(zhí)行效率,還要提升數(shù)據(jù)在網(wǎng)絡(luò)中的傳輸效率、以及內(nèi)存和磁盤的讀寫效率。這些都要求我們處理的數(shù)據(jù)要盡量少。

6.5 計(jì)算盡量少

除了數(shù)據(jù)盡量少以外,對于數(shù)據(jù)的計(jì)算操作也要盡量少,盡量不涉及復(fù)雜的計(jì)算操作,復(fù)雜的計(jì)算操作會消耗大量的CPU資源,會極大的影響系統(tǒng)的響應(yīng)性能。

6.6 流程盡量簡單

秒殺系統(tǒng)在流程設(shè)計(jì)中要盡量簡單,不要涉及到復(fù)雜的業(yè)務(wù)流程,流程越簡單,處理的業(yè)務(wù)邏輯越少,性能就越高效。

七、準(zhǔn)確一致之道

緩存是秒殺系統(tǒng)必不可少的,但是使用緩存之后,就會出現(xiàn)數(shù)據(jù)一致性的問題,這些數(shù)據(jù)一致性的問題,就是需要考慮和處理的,主要包含:緩存與數(shù)據(jù)庫一致、本地緩存與分布式緩存一致、商品庫存與訂單數(shù)據(jù)一致、前端與后端數(shù)據(jù)一致。

圖片

7.1 緩存與數(shù)據(jù)庫一致

使用緩存能夠極大的提升系統(tǒng)的性能,但是使用了緩存之后,需要在確保緩存中的數(shù)據(jù)和數(shù)據(jù)庫中的數(shù)據(jù)是一致的。這種一致性需要根據(jù)場景決定是強(qiáng)一致性還是弱一致性,亦或是最終一致性。

7.2 本地緩存與分布式緩存一致

本地緩存和分布式緩存都能夠提升數(shù)據(jù)的性能,對于極度熱點(diǎn)數(shù)據(jù)來說,最好是存儲在本地緩存中來提升系統(tǒng)的性能,但是這就需要考慮本地緩存與分布式緩存數(shù)據(jù)的一致性問題。

7.3 商品庫存與訂單一致

這里說的商品庫存與訂單一致,指的是商品已經(jīng)消耗的庫存數(shù)量與訂單中的商品數(shù)量一致,不能出現(xiàn)超賣問題,這就需要在秒殺系統(tǒng)的設(shè)計(jì)中,充分考慮到商品庫存的扣減問題。

7.4 前端與后端數(shù)據(jù)一致

前端與后端的數(shù)據(jù)一致,指的是在秒殺過程中盡量做到前端的數(shù)據(jù)與后端的數(shù)據(jù)保持一致,這里說的一致,就不是強(qiáng)一致了,而是最終一致。因?yàn)閰⑴c秒殺的用戶很多,可能會出現(xiàn)某個(gè)用戶在客戶端看到的商品庫存剩余100件,發(fā)起秒殺搶購的請求后,請求發(fā)送到服務(wù)端,服務(wù)端檢測到商品庫存已經(jīng)耗光,就會返回庫存不足或者秒殺已結(jié)束的提示,這種場景就可以歸類為最終一致。

八、穩(wěn)定可靠之道

一個(gè)系統(tǒng)的穩(wěn)定性是重中之重要考慮的問題,一個(gè)秒殺系統(tǒng)必須要具備高度的穩(wěn)定性,要想滿足系統(tǒng)的穩(wěn)定性,可以從隔離策略和監(jiān)控的角度來保證系統(tǒng)的穩(wěn)定性。隔離可以從業(yè)務(wù)隔離、系統(tǒng)隔離和數(shù)據(jù)隔離的角度進(jìn)行考慮,監(jiān)控就可以從監(jiān)控?cái)?shù)據(jù)庫與基礎(chǔ)指標(biāo)、JVM指標(biāo)和中間件等指標(biāo)的角度進(jìn)行考慮。

圖片

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

秒殺系統(tǒng)在業(yè)務(wù)上與其他系統(tǒng)進(jìn)行隔離,對于參與秒殺的商品來說,一般會在秒殺活動(dòng)開始前,提前進(jìn)行提報(bào),并且指定詳細(xì)的營銷策劃和方案。對于參與用戶來說,提前預(yù)約,可以提前識別流量和系統(tǒng)的并發(fā)數(shù),根據(jù)具體情況評估是否需要擴(kuò)容、是否需要降級或者調(diào)整限流策略。

8.2 系統(tǒng)隔離

對于被流量沖擊比較大的核心系統(tǒng)進(jìn)行物理隔離,鏈路末端的系統(tǒng),經(jīng)過前面的削峰限流之后,流量就比較可控了,可以不做物理隔離,在邏輯上進(jìn)行隔離即可。在大廠中,一般會將秒殺的商詳頁系統(tǒng)、秒殺結(jié)算頁系統(tǒng)、購物車系統(tǒng)和訂單系統(tǒng)單獨(dú)隔離出來。

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

對于秒殺系統(tǒng)的數(shù)據(jù)服務(wù),例如Redis集群、MySQL集群等要單獨(dú)隔離部署,做到秒殺數(shù)據(jù)與其他業(yè)務(wù)數(shù)據(jù)的隔離。

除此之外,還要將流量正確的路由到秒殺專有的環(huán)境中。

8.4 監(jiān)控?cái)?shù)據(jù)庫與基礎(chǔ)指標(biāo)

除了通過隔離策略增強(qiáng)系統(tǒng)的穩(wěn)定性之外,還要時(shí)刻關(guān)注系統(tǒng)的風(fēng)險(xiǎn)指標(biāo),對數(shù)據(jù)庫、CPU使用率、內(nèi)存使用率、負(fù)載、網(wǎng)卡、磁盤、IO、網(wǎng)絡(luò)波動(dòng)等進(jìn)行監(jiān)控。

8.5 監(jiān)控JVM指標(biāo)

監(jiān)控JVM的指標(biāo)可以包含:Young GC和Full GC的次數(shù)和耗時(shí),線程池的線程數(shù)和等待隊(duì)列,運(yùn)行中的線程,死鎖的線程,以及JVM的堆棧使用情況等等。

8.6 監(jiān)控中間件指標(biāo)

監(jiān)控中間件的指標(biāo),一般情況下可以緩存的容量、QPS和RT進(jìn)行監(jiān)控,對于數(shù)據(jù)庫的QPS、容量和連接池進(jìn)行監(jiān)控,對消息中間件的QPS、RT以及消息的堆積情況進(jìn)行監(jiān)控,對整個(gè)交易鏈路的分支系統(tǒng)進(jìn)行監(jiān)控等等。

九、全鏈路壓測之道

對于秒殺這種系統(tǒng)高并發(fā)、大流量的系統(tǒng)來說,單一的測試功能和對交易鏈路上某一部分功能都不能測試出整個(gè)秒殺系統(tǒng)的性能瓶頸點(diǎn),要知道木桶能不能裝滿水是取決于最短的木板,對于系統(tǒng)來說也是,整體性能也是取決于整個(gè)交易鏈路上性能最低的一環(huán)。所以,需要對秒殺系統(tǒng)進(jìn)行全鏈路壓測。根據(jù)實(shí)際壓測出來的數(shù)據(jù)進(jìn)行針對性的優(yōu)化和調(diào)整。

十、總結(jié)

本章,主要是對秒殺系統(tǒng)高并發(fā)大流量的挑戰(zhàn)給出了應(yīng)對之道,從總體上說,我們應(yīng)對秒殺系統(tǒng)挑戰(zhàn)時(shí),心中要有一桿秤,在設(shè)計(jì)秒殺系統(tǒng)時(shí),一定要做到分離、削峰限流、快速響應(yīng)、準(zhǔn)確一致、穩(wěn)定可靠、全鏈路壓測。

責(zé)任編輯:武曉燕 來源: 冰河技術(shù)
相關(guān)推薦

2024-07-03 11:01:55

2018-09-04 10:24:35

網(wǎng)絡(luò)流量提取工具

2018-04-09 04:38:43

2017-04-07 09:00:24

技術(shù)管理物聯(lián)網(wǎng)開發(fā)

2019-12-03 10:46:07

PHP高并發(fā)架構(gòu)

2023-07-13 23:35:06

系統(tǒng)Linux

2023-11-14 18:07:44

Python字典項(xiàng)目

2025-02-27 00:00:30

SpringJava方式

2011-06-07 09:36:18

2016-01-15 17:36:29

云計(jì)算云應(yīng)用

2012-10-15 13:26:31

云計(jì)算架構(gòu)

2016-11-10 18:57:19

雙十一高并發(fā)

2012-11-27 13:36:01

2009-02-11 09:46:00

ASON網(wǎng)絡(luò)演進(jìn)

2018-09-15 04:59:01

2025-03-31 01:22:00

2017-06-26 10:35:58

前端JavaScript繼承方式

2024-01-05 13:25:00

架構(gòu)架構(gòu)模式開發(fā)

2010-10-08 11:13:22

MySQL修改密碼

2022-10-25 12:09:13

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號