前提聲明

本篇內(nèi)容完全是筆者自己對(duì)技術(shù)分析和總結(jié)沉淀，由于筆者技術(shù)和能力有限讯沈，如果有不對(duì)的地方郁岩，還望大家多多見(jiàn)諒和包涵，并且多多指正留言缺狠，謝謝问慎。

秒殺系統(tǒng)-情報(bào)背景

相信大家都接觸過(guò)新浪微博、淘寶挤茄、京東等等這些訪問(wèn)量較為巨大的平臺(tái)以及網(wǎng)站如叼，針對(duì)于“高流量”、“高并發(fā)”來(lái)講穷劈，更是我們【技術(shù)開發(fā)者】都要面臨的的一個(gè)很難的“包袱”難題笼恰。哎踊沸，看來(lái)如果要在這行混下去，即使你可能沒(méi)有接觸高并發(fā)場(chǎng)景社证，也要自己創(chuàng)造“高并發(fā)”進(jìn)行迎難而上逼龟，因?yàn)橹挥羞@樣子我們才可以更進(jìn)一步啊猴仑！

秒殺系統(tǒng)-情報(bào)介紹

對(duì)于今天我們要介紹的內(nèi)容就屬于高并發(fā)的一個(gè)最極端的場(chǎng)景之一：“秒殺”审轮，這個(gè)名詞一般會(huì)在“大促”的時(shí)候出現(xiàn)，當(dāng)然也會(huì)在某些平臺(tái)活動(dòng)上出現(xiàn)辽俗，那么肯定會(huì)有小伙伴會(huì)說(shuō)疾渣，秒殺系統(tǒng)要注意哪些問(wèn)題啊崖飘！為啥會(huì)比較難呢榴捡，難在哪里啊朱浴！

秒殺系統(tǒng)- 特點(diǎn)分析

• 瞬時(shí)劇增：在某一個(gè)時(shí)刻開始進(jìn)入流量（很少會(huì)有熱身以及緩慢增長(zhǎng)機(jī)制）吊圾，秒殺時(shí)大量用戶會(huì)在同一時(shí)間，搶購(gòu)?fù)簧唐泛泊溃W(wǎng)站瞬時(shí)流量激增项乒。

• 僧多粥少：商品的庫(kù)存是有限的，秒殺請(qǐng)求下的訂單數(shù)量會(huì)遠(yuǎn)遠(yuǎn)大于庫(kù)存數(shù)量梁沧，只有少部分用戶能夠秒殺成功檀何。

• 資源鎖定：秒殺業(yè)務(wù)流程比較簡(jiǎn)單，一般就是下訂單減庫(kù)存廷支。庫(kù)存就是用戶爭(zhēng)奪的“資源”频鉴，實(shí)際被消費(fèi)的“資源”不能超過(guò)計(jì)劃要售出的“資源”，也就是不能被“超賣”恋拍。

秒殺系統(tǒng)- 難度分析

它的難度就在于要完成一個(gè)“60-100分”的秒殺系統(tǒng)垛孔，那么它必須要要至少兼顧以下這三個(gè)方面，才算合格施敢，這三個(gè)“惡魔”分別叫“服務(wù)可用性”周荐、“數(shù)據(jù)一致性”和“快速響應(yīng)性”，有點(diǎn)“苛刻”僵娃！

在我們現(xiàn)在的場(chǎng)景下概作，很難再去考慮一個(gè)非分布式系統(tǒng)的架構(gòu)了。（分布式架構(gòu)）相信大家都知道CAP理論吧悯许！沒(méi)事不知道也沒(méi)關(guān)系仆嗦，可見(jiàn)內(nèi)容：

CAP理論又稱CAP定理，它說(shuō)的是在一個(gè)分布式系統(tǒng)中先壕，服務(wù)（數(shù)據(jù)）層面的一致性（Consistency）瘩扼、服務(wù)自身的可用性（Availability）谆甜、網(wǎng)絡(luò)不同節(jié)點(diǎn)分區(qū)容錯(cuò)性（Partition tolerance）。

A和C相信大家從字面上都可以理解了集绰，這里要聲明一下比較陌生的P：它代表如果要保證不同的節(jié)點(diǎn)即使在網(wǎng)絡(luò)出現(xiàn)問(wèn)題的時(shí)候仍能夠訪問(wèn)到數(shù)據(jù)规辱，那么最直接的辦法就是冗余賦值節(jié)點(diǎn)，否則一切都是空談栽燕，所以作為一個(gè)分布式系統(tǒng)而言罕袋，無(wú)法忽略P，我們可以理解它就是A和C的基礎(chǔ)碍岔。

CAP體系總結(jié)

• 只保證AC就是一個(gè)單體應(yīng)用浴讯，根本不是分布式。意義當(dāng)然有蔼啦，在分布式出現(xiàn)之前都是這么搭系統(tǒng)榆纽。倘若這個(gè)系統(tǒng)的節(jié)點(diǎn)之一掛了，不會(huì)發(fā)生腦裂而是整個(gè)系統(tǒng)直接宕掉捏肢。

• 進(jìn)一步說(shuō)如果網(wǎng)絡(luò)中存在的節(jié)點(diǎn)越多奈籽，分區(qū)容忍性越高，但要復(fù)制更新的數(shù)據(jù)就越多鸵赫，一致性就越難保證衣屏。

• 為了保證一致性测蹲，更新所有節(jié)點(diǎn)數(shù)據(jù)所需要的時(shí)間就越長(zhǎng)膊爪，可用性就會(huì)降低碱工。

以上三者成為了“矛盾論”争占，而CAP原則指的是，這三個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)霎迫，不可能三者兼顧。

回到我們的主體：秒殺三要素，它們?nèi)齻€(gè)可不完全等同于CAP三要素卖局，甚至比它們的要求更高，甚至是基于前三者的一個(gè)更高層次的水平要求双霍。

服務(wù)的可用性（Availability）

服務(wù)可用性砚偶，是在于高并發(fā)流量的沖擊下，仍然可以保持服務(wù)的可用性并且還要保證一直可以輸出對(duì)外界的服務(wù)能力洒闸，不會(huì)造成宕機(jī)以及資源損壞染坯，即使在內(nèi)存和網(wǎng)絡(luò)甚至硬件資源有限的情況下，也不會(huì)被擊垮“死亡”丘逸。

比如就像你養(yǎng)魚单鹿，你玩命的給魚放飼料，而超過(guò)了魚能夠承受的量深纲，它受不了了活活被噎死或者撐死了仲锄，這魚就像你的系統(tǒng)一樣劲妙，一定要保證魚的健康啊儒喊！

數(shù)據(jù)的一致性（Consistency）

都知道镣奋，我們開發(fā)的程序以及現(xiàn)在多數(shù)的服務(wù)器，比如數(shù)據(jù)庫(kù)怀愧，他們?cè)谔幚頂?shù)據(jù)的時(shí)候侨颈，很有可能會(huì)存在多個(gè)線程同時(shí)在修改同一行數(shù)據(jù)或者同一塊內(nèi)存，在Java角度而言本身也會(huì)存在不一致的問(wèn)題芯义，而在程序和中間件的角度而言哈垢，也是一樣，會(huì)出現(xiàn)同一時(shí)刻在數(shù)據(jù)修改順序的亂序化扛拨，以及數(shù)據(jù)的紊亂温赔，造成數(shù)據(jù)的重復(fù)操作，造成與我們預(yù)期的設(shè)想不同鬼癣。

• 除非你可以實(shí)現(xiàn)串行化陶贼，一條一條處理，不讓它們同一時(shí)刻就行修改或者操作數(shù)據(jù)待秃，這個(gè)是最本質(zhì)且最安全的辦法拜秧，但是也是最影響性能的辦法。（悲觀鎖章郁、同步隊(duì)列）枉氮。

• 此外還有一種辦法就是，時(shí)時(shí)刻刻在原子層級(jí)暖庄，也就是最接近底層的計(jì)算機(jī)修改數(shù)據(jù)的時(shí)候聊替，或者在所有節(jié)點(diǎn)之間建立一個(gè)應(yīng)用層級(jí)的中間匯總干路點(diǎn)（redis或者database的主干點(diǎn)），上面加入寫屏障和讀屏障培廓，在修改之前惹悄，在進(jìn)行一次校驗(yàn)判斷，如果數(shù)據(jù)與預(yù)期不同肩钠，就不進(jìn)行修改泣港。這就是著名的樂(lè)觀鎖！

服務(wù)快速響應(yīng)性（Quick Response）

一般來(lái)講這個(gè)屬于用戶體驗(yàn)价匠，一個(gè)較為合格的秒殺系統(tǒng)当纱，是不應(yīng)該讓用戶漫長(zhǎng)的等待而是最好盡可能快速反饋結(jié)果。

• 要做成快速響應(yīng)踩窖，就不需要是異步返回坡氯，直接快速響應(yīng)。

• 此外還需要盡快幫助用戶計(jì)算數(shù)據(jù)，直接返回箫柳。

總結(jié)一下

1. （異步返回+同步處理）總結(jié)一下就是異步中套用者同步進(jìn)行計(jì)算颓遏，既可以保證快速響應(yīng)，又可以保證數(shù)據(jù)的一致性滞时。

2. （異步返回+樂(lè)觀鎖處理）總結(jié)一下就是異步中套用者樂(lè)觀鎖進(jìn)行計(jì)算叁幢，既可以保證快速響應(yīng)，又可以保證數(shù)據(jù)的一致性坪稽。

情報(bào)分析結(jié)束后曼玩，我們要重頭戲！進(jìn)行技術(shù)分析了窒百。

秒殺系統(tǒng)-架構(gòu)設(shè)計(jì)

我們將秒殺架構(gòu)進(jìn)行一下劃分黍判，大體分為三個(gè)層級(jí)進(jìn)行分析：由外到內(nèi)進(jìn)行分析，分別是：應(yīng)用層篙梢、服務(wù)層顷帖、數(shù)據(jù)訪問(wèn)層。

image

秒殺架構(gòu)設(shè)計(jì)點(diǎn)

應(yīng)用層架構(gòu)設(shè)計(jì)

image

動(dòng)靜分離+CDN技術(shù)

動(dòng)靜分離分析

• 場(chǎng)景分析：在秒殺活動(dòng)開啟之前渤滞，用戶一般都會(huì)嘗試不斷的刷新瀏覽器頁(yè)面（俗稱F5）以保證不會(huì)錯(cuò)過(guò)秒殺活動(dòng)的商品贬墩。

• 按照常用的網(wǎng)站應(yīng)用架構(gòu)：

  • 我們假設(shè)，如果這些無(wú)用的請(qǐng)求妄呕，頻繁的沖擊我們的后臺(tái)服務(wù)器陶舞，比如說(shuō)經(jīng)過(guò)：Web服務(wù)器(LVS、Nginx等)->應(yīng)用服務(wù)器（tomcat或者Jetty等）绪励、連接數(shù)據(jù)庫(kù)（MySQL）肿孵，者無(wú)疑會(huì)對(duì)后端服務(wù)以及服務(wù)器造成非常大的壓力。

• 解決方案：重新設(shè)計(jì)秒殺商品頁(yè)面疏魏，不使用網(wǎng)站原來(lái)的商品詳細(xì)頁(yè)面停做，頁(yè)面內(nèi)容靜態(tài)化，減少/隔絕無(wú)用的請(qǐng)求經(jīng)過(guò)后端服務(wù)大莫。

image

CDN技術(shù)分析

突然增加的網(wǎng)絡(luò)及服務(wù)器帶寬

網(wǎng)站的靜態(tài)頁(yè)面數(shù)據(jù)大小100K蛉腌，那么需要的網(wǎng)絡(luò)和服務(wù)器帶寬是2G（100K×10000），這些網(wǎng)絡(luò)帶寬是因?yàn)槊霘⒒顒?dòng)新增的葵硕，超過(guò)網(wǎng)站平時(shí)使用的帶寬眉抬。

即使將動(dòng)態(tài)業(yè)務(wù)轉(zhuǎn)換為靜態(tài)化頁(yè)面贯吓，但是秒殺活動(dòng)會(huì)非常劇烈的增加的網(wǎng)絡(luò)帶寬的消耗懈凹，同時(shí)并不會(huì)減輕前端網(wǎng)站服務(wù)器的壓力，所以如果可以的話悄谐，需要再進(jìn)一步將秒殺商品頁(yè)面緩存在CDN介评，而不在是單純的我們的前端Nginx服務(wù)器層面，所以需要和CDN服務(wù)商臨時(shí)租借新增的出口帶寬。

image

防止緩存干擾頁(yè)面刷新為秒殺頁(yè)面

通過(guò)javascript文件進(jìn)行傳遞隨機(jī)號(hào)+狀態(tài)位们陆！

在秒殺商品靜態(tài)頁(yè)面中加入一個(gè)JavaScript文件引用寒瓦，該JavaScript文件中包含秒殺開始標(biāo)志為否；

image

• 當(dāng)秒殺開始的時(shí)候生成一個(gè)新的JavaScript文件（文件名保持不變坪仇，只是內(nèi)容不一樣）杂腰，更新秒殺開始標(biāo)志為是，加入下單頁(yè)面的URL及隨機(jī)數(shù)參數(shù)（這個(gè)隨機(jī)數(shù)只會(huì)產(chǎn)生一個(gè)椅文，即所有人看到的URL都是同一個(gè)喂很，服務(wù)器端可以用redis這種分布式緩存服務(wù)器來(lái)保存隨機(jī)數(shù)），并被用戶瀏覽器加載皆刺，控制秒殺商品頁(yè)面的展示少辣。

• 這個(gè)JavaScript文件的加載可以加上隨機(jī)版本號(hào)（例如xx.js?v=32353823），這樣就不會(huì)被瀏覽器羡蛾、CDN和反向代理服務(wù)器緩存漓帅。

• 這個(gè)JavaScript文件非常小，即使每次瀏覽器刷新都訪問(wèn)JavaScript文件服務(wù)器也不會(huì)對(duì)服務(wù)器集群和網(wǎng)絡(luò)帶寬造成太大壓力痴怨。

總結(jié)一下：前端秒殺頁(yè)面使用專門的頁(yè)面忙干，這些頁(yè)面包括靜態(tài)的 HTML 和動(dòng)態(tài)的 JS，他們都需要在 CDN 上緩存浪藻。

根據(jù)UID限制頻率熱度

為了控制公平性原則豪直，由于黃牛或者一些黑客達(dá)人珠移，會(huì)采用”高科技“弓乙，比如說(shuō)，采用爬蟲腳本操作钧惧，瘋狂的去刷新頁(yè)面暇韧。為了防止一些人的破壞以及公平分散，所以采用同一個(gè)標(biāo)準(zhǔn)去控制UID（用戶ID）去訪問(wèn)頻率信息浓瞪，當(dāng)超過(guò)每個(gè)人所需要達(dá)到的頻率閾值懈玻，就要進(jìn)行限制互動(dòng)窗口內(nèi)能夠訪問(wèn)刷新的數(shù)據(jù)量！

例如：可以用Redis給每個(gè)用戶做訪問(wèn)統(tǒng)計(jì)乾颁，根據(jù)用戶的ID和商品的標(biāo)識(shí)雙方面進(jìn)行對(duì)用戶對(duì)某一個(gè)商品的訪問(wèn)頻率控制涂乌，超過(guò)訪問(wèn)頻率后，就會(huì)將他的請(qǐng)求暫時(shí)性熔斷英岭。

image

反向代理+負(fù)載均衡

• 秒殺系統(tǒng)必然是一個(gè)集群系統(tǒng)湾盒，在硬件不提升的情況下利用nginx做負(fù)載均衡也是不錯(cuò)的選擇。

負(fù)載均衡(Load Balance)是集群技術(shù)(Cluster)的一種應(yīng)用诅妹，可以將工作任務(wù)分?jǐn)偟蕉鄠€(gè)處理單元罚勾，從而提高并發(fā)處理能力毅人，有利于提升中大型網(wǎng)站的性能。
需要使用服務(wù)集群和水平擴(kuò)展尖殃，讓“高峰”請(qǐng)求分流到不同的服務(wù)器進(jìn)行處理丈莺。

image

http重定向協(xié)議實(shí)現(xiàn)負(fù)載均衡

根據(jù)用戶的http請(qǐng)求的DNAT計(jì)算出一個(gè)真實(shí)的web服務(wù)器地址，并將該web服務(wù)器地址寫入http重定向響應(yīng)中返回給瀏覽器送丰，由瀏覽器重新進(jìn)行訪問(wèn)缔俄。該方式比較簡(jiǎn)單，但性能較差器躏。

一般來(lái)講經(jīng)常用的SpringCloud-Gateway或者Neflix的Zuul等就屬于該類型牵现。

協(xié)議層：DNS域名解析負(fù)載均衡

DNS服務(wù)器上配置多個(gè)域名對(duì)應(yīng)IP的記錄。該方式直接將負(fù)載均衡的工作交給了DNS邀桑，為網(wǎng)站管理維護(hù)省掉了很多麻煩瞎疼，訪問(wèn)速度快，有效改善性能壁畸。

一般來(lái)講經(jīng)常用的DNS服務(wù)器或者國(guó)內(nèi)的DNS服務(wù)器等就屬于該類型贼急。

協(xié)議層：反向代理負(fù)載均衡

反向代理服務(wù)器在提供負(fù)載均衡功能的同時(shí)，管理著一組web服務(wù)器捏萍，根據(jù)負(fù)載均衡算法將請(qǐng)求的瀏覽器訪問(wèn)轉(zhuǎn)發(fā)到不同的web服務(wù)器處理太抓，處理結(jié)果經(jīng)過(guò)反向服務(wù)器返回給瀏覽器。

該方式部署簡(jiǎn)單令杈，web服務(wù)器地址不能直接暴露在外走敌，不需要使用外部IP地址，而反向代理服務(wù)作為溝通橋梁就需要配置雙網(wǎng)卡逗噩、外部?jī)?nèi)部?jī)商譏P地址掉丽。

一般來(lái)講經(jīng)常用的Nginx或者HaProxy等就屬于該類型。

網(wǎng)絡(luò)層IP負(fù)載均衡

網(wǎng)絡(luò)層通過(guò)修改目標(biāo)地址進(jìn)行負(fù)載均衡异雁，該方式在響應(yīng)請(qǐng)求時(shí)速度較反向服務(wù)器負(fù)載均衡要快捶障，但是，當(dāng)請(qǐng)求數(shù)據(jù)較大(大型視頻或文件)時(shí)纲刀，速度反應(yīng)就會(huì)變慢项炼。

一般來(lái)講經(jīng)常用的Nginx或者HaProxy等就屬于該類型。

數(shù)據(jù)鏈路層負(fù)載均衡

數(shù)據(jù)鏈路層修改Mac地址進(jìn)行負(fù)載均衡示绊，負(fù)載均衡服務(wù)器的IP和它所管理的web 服務(wù)群的虛擬IP一致锭部。它不需要負(fù)載均衡服務(wù)器進(jìn)行地址的轉(zhuǎn)換，但是對(duì)負(fù)載均衡服務(wù)器的網(wǎng)卡帶寬要求較高面褐。

一般來(lái)講經(jīng)常用的LVS等就屬于該類型拌禾。

F5 和 A10 負(fù)載均衡器

F5的全稱是F5-BIG-IP-GTM，硬件負(fù)載均衡設(shè)備盆耽，其并發(fā)能力達(dá)到蹋砚。該方式能夠?qū)崿F(xiàn)多鏈路的負(fù)載均衡和冗余扼菠，可以接入多條ISP鏈路摄杂，在鏈路之間實(shí)現(xiàn)負(fù)載均衡和高可用坝咐。

服務(wù)層架構(gòu)設(shè)計(jì)

image

緩存技術(shù)分析

硬盤持久化的IO操作將耗費(fèi)大量資源。所以決定采用基于內(nèi)存操作的redis析恢，redis的密集型io墨坚。

分批放行+排隊(duì)處理

• 即使我們擴(kuò)展再多的應(yīng)用，使用再多的應(yīng)用服務(wù)器映挂，部署再多的負(fù)載均衡器泽篮，都會(huì)遇到支撐不住海量請(qǐng)求的時(shí)候。
• 所以柑船，在這一層我們要考慮的是如何做好限流帽撑，當(dāng)超過(guò)系統(tǒng)承受范圍的時(shí)候，需要果斷阻止請(qǐng)求的涌入鞍时。

排隊(duì)處理

排隊(duì)處理機(jī)制亏拉，正如，我們?nèi)粘ＹI東西排隊(duì)一樣的道理逆巍，這樣子就不會(huì)處理不過(guò)來(lái)及塘，并且也可以保證數(shù)據(jù)執(zhí)行的正確性！

它直接將請(qǐng)求放入隊(duì)列中的锐极，采用FIFO（First Input First Output笙僚，先進(jìn)先出），這樣的話灵再，我們就不會(huì)導(dǎo)致某些請(qǐng)求永遠(yuǎn)獲取不到鎖肋层。看到這里翎迁，有一些將多線程處理方式變成單線程處理機(jī)制槽驶，會(huì)大大影響數(shù)據(jù)的效率和性能！

image

Java的三個(gè)常用的并發(fā)隊(duì)列

• ArrayBlockingQueue是初始容量固定的阻塞隊(duì)列鸳兽，可以用來(lái)作為數(shù)據(jù)庫(kù)成功競(jìng)拍的隊(duì)列掂铐，比如有10個(gè)商品，那么我們就設(shè)定一個(gè)10大小的數(shù)組隊(duì)列揍异。

• ConcurrentLinkedQueue使用的是CAS原語(yǔ)無(wú)鎖隊(duì)列實(shí)現(xiàn)全陨，是一個(gè)異步隊(duì)列，入隊(duì)的速度很快衷掷，出隊(duì)進(jìn)行了加鎖辱姨，性能稍慢。

• LinkedBlockingQueue也是阻塞的隊(duì)列戚嗅，入隊(duì)和出隊(duì)都用了加鎖雨涛，當(dāng)隊(duì)空的時(shí)候線程會(huì)暫時(shí)阻塞枢舶。

在請(qǐng)求預(yù)處理階段，由于系統(tǒng)入隊(duì)需求要遠(yuǎn)大于出隊(duì)需求替久，一般不會(huì)出現(xiàn)隊(duì)空的情況凉泄，所以我們可以選擇ConcurrentLinkedQueue來(lái)作為我們的請(qǐng)求隊(duì)列實(shí)現(xiàn)，甚至可以采用Disruptor異步處理框架機(jī)制蚯根。

分批放行

在同步排隊(duì)的基礎(chǔ)上后众，我們可以在加入一個(gè)分批放行執(zhí)行處理機(jī)制。

顧名思義的就是颅拦，為了提高性能蒂誉，我們可以考慮達(dá)到預(yù)定閾值以后，在進(jìn)行相關(guān)的執(zhí)行后端服務(wù)距帅，這樣子可以提高一定的性能以及減少后端請(qǐng)求的次數(shù)和壓力右锨，如下圖所示：

image

還會(huì)利用緩存和隊(duì)列技術(shù)減輕應(yīng)用處理的壓力，通過(guò)異步請(qǐng)求的方式做到最終一致性碌秸。

限流

漏桶算法

漏桶算法思路很簡(jiǎn)單绍移，水（請(qǐng)求）先進(jìn)入到漏桶里，漏桶以一定的速度出水哮肚，當(dāng)水流入速度過(guò)大會(huì)直接溢出登夫，可以看出漏桶算法能強(qiáng)行限制數(shù)據(jù)的傳輸速率。

image

• 設(shè)定漏桶流出速度及漏桶的總?cè)萘吭侍耍谡?qǐng)求到達(dá)時(shí)判斷當(dāng)前漏桶容量是否已滿恼策，不滿則可將請(qǐng)求存入桶中，否則拋棄請(qǐng)求潮剪。
• 采用一個(gè)線程以設(shè)定的速率取出請(qǐng)求進(jìn)行處理涣楷。

算法弊端

• 由于其只能以特定速率處理請(qǐng)求，則如何確定該速率就是核心問(wèn)題抗碰，如果速率設(shè)置太小則會(huì)浪費(fèi)性能資源狮斗，設(shè)置太大則會(huì)造成資源不足。

速度執(zhí)行敏感度不高弧蝇！無(wú)論輸入速率如何波動(dòng)碳褒，均不會(huì)體現(xiàn)在服務(wù)端，即使資源有空余看疗，對(duì)于突發(fā)請(qǐng)求也無(wú)法及時(shí)處理沙峻，故對(duì)有突發(fā)請(qǐng)求處理需求時(shí)，不宜選擇該方法两芳。

image

令牌桶算法

令牌桶算法的原理是系統(tǒng)會(huì)以一個(gè)恒定的速度往桶里放入令牌摔寨，而如果請(qǐng)求需要被處理，則需要先從桶里獲取一個(gè)令牌怖辆，當(dāng)桶里沒(méi)有令牌可取時(shí)是复，則拒絕服務(wù)删顶。

實(shí)現(xiàn)原理

設(shè)定令牌桶中添加令牌的速率，并且設(shè)置桶中最大可存儲(chǔ)的令牌淑廊，當(dāng)請(qǐng)求到達(dá)時(shí)逗余，向桶中請(qǐng)求令牌（根據(jù)應(yīng)用需求，可能為1個(gè)或多個(gè)）蒋纬，若令牌數(shù)量滿足要求猎荠，則刪除對(duì)應(yīng)數(shù)量的令牌并通過(guò)當(dāng)前請(qǐng)求坚弱，若桶中令牌數(shù)不足則觸發(fā)限流規(guī)則蜀备。

image

為解決固定窗口計(jì)數(shù)帶來(lái)的周期切換處流量突發(fā)問(wèn)題，可以使用滑動(dòng)窗口計(jì)數(shù)荒叶∧敫螅滑動(dòng)窗口計(jì)算本質(zhì)上也是固定窗口計(jì)數(shù)，區(qū)別在于將計(jì)數(shù)周期進(jìn)行細(xì)化些楣。

滑動(dòng)窗口

滑動(dòng)窗口計(jì)數(shù)法與固定窗口計(jì)數(shù)法相比較脂凶，除了計(jì)數(shù)周期T及周期內(nèi)最大訪問(wèn)（調(diào)用）數(shù)N兩個(gè)參數(shù)，增加一個(gè)參數(shù)M愁茁，用于設(shè)置周期T內(nèi)的滑動(dòng)窗口數(shù)蚕钦。

image

數(shù)據(jù)訪問(wèn)層

由于要承受高并發(fā)，mysql在高并發(fā)情況下的性能下降尤其嚴(yán)重鹅很。

image

數(shù)據(jù)更新點(diǎn)（庫(kù)存扣除）

悲觀鎖更新數(shù)據(jù)

可以從“悲觀鎖”的方向

image

• 悲觀鎖嘶居，也就是在修改數(shù)據(jù)的時(shí)候，采用鎖定狀態(tài)促煮，排斥外部請(qǐng)求的修改邮屁。遇到加鎖的狀態(tài)，就必須等待菠齿。

• 雖然它解決了線程安全的問(wèn)題佑吝，但是“高并發(fā)”場(chǎng)景下，會(huì)很多這樣的修改請(qǐng)求绳匀，每個(gè)請(qǐng)求都需要等待“鎖”芋忿，某些線程可能永遠(yuǎn)都沒(méi)有機(jī)會(huì)搶到這個(gè)“鎖”，這種請(qǐng)求就會(huì)死在那里疾棵。

• 同時(shí)戈钢，這種請(qǐng)求會(huì)很多，瞬間增大系統(tǒng)的平均響應(yīng)時(shí)間陋桂，結(jié)果是可用連接數(shù)被耗盡逆趣，系統(tǒng)陷入異常。

行鎖嗜历、頁(yè)鎖宣渗、表鎖抖所、同步鎖、分布式鎖痕囱、分布式隊(duì)列田轧、意向所等。

樂(lè)觀鎖更新數(shù)據(jù)

討論一下“樂(lè)觀鎖”的思路了鞍恢。

image

• 樂(lè)觀鎖傻粘，是相對(duì)于“悲觀鎖”采用更為寬松的加鎖機(jī)制，大都是采用帶版本號(hào)（Version）更新/通過(guò)狀態(tài)化進(jìn)行更新操作機(jī)制帮掉。

• 實(shí)現(xiàn)就是弦悉，這個(gè)數(shù)據(jù)所有請(qǐng)求都有資格去修改，但會(huì)獲得一個(gè)該數(shù)據(jù)的版本號(hào)蟆炊，只有版本號(hào)符合的才能更新成功稽莉，其他的返回?fù)屬?gòu)失敗。

• 這樣的話涩搓，我們就不需要考慮隊(duì)列的問(wèn)題污秆，不過(guò)，它會(huì)增大CPU的計(jì)算開銷昧甘。但是在沖突較小的時(shí)候良拼，這是一個(gè)比較好的解決方案。

緩存樂(lè)觀鎖充边、數(shù)據(jù)庫(kù)樂(lè)觀鎖庸推。（判斷更新行數(shù)是否>0），CAS機(jī)制

姊妹篇【「絕密檔案」“爆料”完整秒殺架構(gòu)的設(shè)計(jì)到技術(shù)關(guān)鍵點(diǎn)的“八卦資料”】

再此會(huì)進(jìn)行擴(kuò)展技術(shù)介紹痛黎，以下內(nèi)容：

• 熱點(diǎn)分離

  • 熱點(diǎn)識(shí)別技術(shù)
  • 熱點(diǎn)隔離技術(shù)
  • 熱點(diǎn)優(yōu)化技術(shù)

• 事務(wù)完整性

  • 接口冪等性

• 分布式事務(wù)系統(tǒng)

  • 事務(wù)處理去重法
  • 事務(wù)處理冪等性

• 數(shù)據(jù)高可用

  • 讀寫分離
  • 分庫(kù)分表
  • 數(shù)據(jù)庫(kù)集群
  • 優(yōu)化數(shù)據(jù)庫(kù)

• DB層面的單行記錄做并發(fā)排隊(duì)機(jī)制

• 服務(wù)降級(jí)分析

• 降低沖擊法（延時(shí)處理）

  • 延時(shí)隊(duì)列機(jī)制（單點(diǎn)法）
  • 延時(shí)隊(duì)列機(jī)制（分布式）