完整秒殺架構(gòu)的設(shè)計(jì)

作者：浩宇天尚

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

相信大家都接觸過(guò)新浪微博、淘寶、京東等等這些訪問(wèn)量較為巨大的平臺(tái)以及網(wǎng)站，針對(duì)于“高流量”、“高并發(fā)”來(lái)講，更是我們【技術(shù)開(kāi)發(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í)刻開(kāi)始進(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)魚(yú)，你玩命的給魚(yú)放飼料，而超過(guò)了魚(yú)能夠承受的量，它受不了了活活被噎死或者撐死了，這魚(yú)就像你的系統(tǒng)一樣，一定要保證魚(yú)的健康?。?

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

都知道，我們開(kāi)發(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)層。

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

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

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

# 動(dòng)靜分離分析

• 場(chǎng)景分析：在秒殺活動(dòng)開(kāi)啟之前，用戶一般都會(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ù)。

  
  

# 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í)租借新增的出口帶寬。

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

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

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

• 當(dāng)秒殺開(kāi)始的時(shí)候生成一個(gè)新的JavaScript文件（文件名保持不變，只是內(nèi)容不一樣），更新秒殺開(kā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ō)，采用爬蟲(chóng)腳本操作，瘋狂的去刷新頁(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í)性熔斷。

反向代理 負(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)行處理。

# 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ì)

緩存技術(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ù)的效率和性能！

# 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ù)和壓力，如下圖所示：

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

限流

漏桶算法

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

• 設(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í)，不宜選擇該方法。

令牌桶算法

令牌桶算法的原理是系統(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ī)則。

為解決固定窗口計(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ù)。

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

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

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

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

可以從“悲觀鎖”的方向

• 悲觀鎖，也就是在修改數(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è)觀鎖”的思路了。

• 樂(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ì)算開(kāi)銷。但是在沖突較小的時(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ī)制（分布式）