今天就給大家聊一個有意思的話題：每秒上千訂單場景下色洞，如何對分布式鎖的并發(fā)能力進行優(yōu)化巫财？
背景引入
首先妄田，我們一起來看看這個問題的背景？
前段時間有個朋友在外面面試绳矩，然后有一天找我聊說：有一個國內(nèi)不錯的電商公司罩润，面試官給他出了一個場景題：
假如下單時，用分布式鎖來防止庫存超賣埋酬，但是是每秒上千訂單的高并發(fā)場景哨啃，如何對分布式鎖進行高并發(fā)優(yōu)化來應(yīng)對這個場景烧栋？
他說他當時沒答上來，因為沒做過沒什么思路拳球。其實我當時聽到這個面試題心里也覺得有點意思审姓，因為如果是我來面試候選人的話，應(yīng)該會給的范圍更大一些祝峻。
比如魔吐，讓面試的同學(xué)聊一聊電商高并發(fā)秒殺場景下的庫存超賣解決方案，各種方案的優(yōu)缺點以及實踐莱找，進而聊到分布式鎖這個話題酬姆。
因為庫存超賣問題是有很多種技術(shù)解決方案的，比如悲觀鎖奥溺，分布式鎖辞色，樂觀鎖，隊列串行化浮定，Redis原子操作相满，等等吧。
但是既然那個面試官兄弟限定死了用分布式鎖來解決庫存超賣桦卒，我估計就是想問一個點：在高并發(fā)場景下如何優(yōu)化分布式鎖的并發(fā)性能立美。
我覺得，面試官提問的角度還是可以接受的方灾，因為在實際落地生產(chǎn)的時候建蹄，分布式鎖這個東西保證了數(shù)據(jù)的準確性，但是他天然并發(fā)能力有點弱裕偿。
剛好我之前在自己項目的其他場景下洞慎，確實是做過高并發(fā)場景下的分布式鎖優(yōu)化方案，因此正好是借著這個朋友的面試題击费，把分布式鎖的高并發(fā)優(yōu)化思路拢蛋，給大家來聊一聊。
庫存超賣現(xiàn)象是怎么產(chǎn)生的蔫巩？
先來看看如果不用分布式鎖，所謂的電商庫存超賣是啥意思快压？大家看看下面的圖：
這個圖圆仔，其實很清晰了，假設(shè)訂單系統(tǒng)部署兩臺機器上蔫劣，不同的用戶都要同時買10臺iphone坪郭，分別發(fā)了一個請求給訂單系統(tǒng)。
接著每個訂單系統(tǒng)實例都去數(shù)據(jù)庫里查了一下脉幢，當前iphone庫存是12臺歪沃。
倆大兄弟一看嗦锐，樂了，12臺庫存大于了要買的10臺數(shù)量盎κ铩奕污！
于是乎，每個訂單系統(tǒng)實例都發(fā)送SQL到數(shù)據(jù)庫里下單液走，然后扣減了10個庫存碳默，其中一個將庫存從12臺扣減為2臺，另外一個將庫存從2臺扣減為-8臺缘眶。
現(xiàn)在完了嘱根，庫存出現(xiàn)了負數(shù)！淚奔啊巷懈，沒有20臺iphone發(fā)給兩個用戶案檬恪！這可如何是好顶燕。
用分布式鎖如何解決庫存超賣問題柔逼？
我們用分布式鎖如何解決庫存超賣問題呢？其實很簡單割岛，回憶一下上次我們說的那個分布式鎖的實現(xiàn)原理：
同一個鎖key愉适，同一時間只能有一個客戶端拿到鎖，其他客戶端會陷入無限的等待來嘗試獲取那個鎖癣漆，只有獲取到鎖的客戶端才能執(zhí)行下面的業(yè)務(wù)邏輯维咸。
代碼大概就是上面那個樣子，現(xiàn)在我們來分析一下惠爽，為啥這樣做可以避免庫存超賣癌蓖？
大家可以順著上面的那個步驟序號看一遍，馬上就明白了婚肆。
從上圖可以看到租副，只有一個訂單系統(tǒng)實例可以成功加分布式鎖，然后只有他一個實例可以查庫存较性、判斷庫存是否充足用僧、下單扣減庫存，接著釋放鎖赞咙。
釋放鎖之后责循，另外一個訂單系統(tǒng)實例才能加鎖，接著查庫存攀操，一下發(fā)現(xiàn)庫存只有2臺了院仿，庫存不足，無法購買，下單失敗歹垫。不會將庫存扣減為-8的剥汤。
有沒有其他方案可以解決庫存超賣問題？
當然有芭挪摇吭敢！比如悲觀鎖，分布式鎖若贮，樂觀鎖省有，隊列串行化，異步隊列分散谴麦，Redis原子操作蠢沿，等等，很多方案匾效，我們對庫存超賣有自己的一整套優(yōu)化機制舷蟀。
但是前面說過了，這篇文章就聊一個分布式鎖的并發(fā)優(yōu)化面哼，不是聊庫存超賣的解決方案野宜，所以庫存超賣只是一個業(yè)務(wù)場景而已。
以后有機會筆者會寫一篇文章魔策，講講電商庫存超賣問題的解決方案匈子，這篇文章先focus在一個分布式鎖并發(fā)優(yōu)化上，希望大家明白這個用意和背景闯袒，避免有的兄弟沒看清楚又吐槽虎敦。
而且建議大家即使對文章里的內(nèi)容有異議，公眾號后臺給我留言跟我討論一下政敢，技術(shù)其徙，就是要多交流，打開思路喷户，碰撞思維唾那。
分布式鎖的方案在高并發(fā)場景下
好，現(xiàn)在我們來看看褪尝，分布式鎖的方案在高并發(fā)場景下有什么問題闹获？
問題很大啊恼五！兄弟昌罩，不知道你看出來了沒有。分布式鎖一旦加了之后灾馒，對同一個商品的下單請求，會導(dǎo)致所有客戶端都必須對同一個商品的庫存鎖key進行加鎖遣总。
比如睬罗，對iphone這個商品的下單轨功，都必對“iphone_stock”這個鎖key來加鎖。這樣會導(dǎo)致對同一個商品的下單請求容达，就必須串行化古涧，一個接一個的處理。
大家再回去對照上面的圖反復(fù)看一下花盐，應(yīng)該能想明白這個問題羡滑。
假設(shè)加鎖之后，釋放鎖之前算芯，查庫存 -> 創(chuàng)建訂單 -> 扣減庫存柒昏，這個過程性能很高吧，算他全過程20毫秒熙揍，這應(yīng)該不錯了职祷。
那么1秒是1000毫秒，只能容納50個對這個商品的請求依次串行完成處理届囚。
比如一秒鐘來50個請求，都是對iphone下單的，那么每個請求處理20毫秒羽德，一個一個來徙垫，最后1000毫秒正好處理完50個請求。
大家看一眼下面的圖蛔添，加深一下感覺痰催。
所以看到這里，大家起碼也明白了作郭，簡單的使用分布式鎖來處理庫存超賣問題陨囊，存在什么缺陷。
缺陷就是同一個商品多用戶同時下單的時候夹攒，會基于分布式鎖串行化處理蜘醋，導(dǎo)致沒法同時處理同一個商品的大量下單的請求。
這種方案咏尝，要是應(yīng)對那種低并發(fā)压语、無秒殺場景的普通小電商系統(tǒng)，可能還可以接受编检。
因為如果并發(fā)量很低胎食，每秒就不到10個請求，沒有瞬時高并發(fā)秒殺單個商品的場景的話允懂，其實也很少會對同一個商品在一秒內(nèi)瞬間下1000個訂單厕怜，因為小電商系統(tǒng)沒那場景。
如何對分布式鎖進行高并發(fā)優(yōu)化？
好了粥航，終于引入正題了琅捏，那么現(xiàn)在怎么辦呢？
面試官說递雀，我現(xiàn)在就卡死柄延，庫存超賣就是用分布式鎖來解決，而且一秒對一個iphone下上千訂單缀程，怎么優(yōu)化搜吧？
現(xiàn)在按照剛才的計算，你一秒鐘只能處理針對iphone的50個訂單杨凑。
其實說出來也很簡單滤奈，相信很多人看過java里的ConcurrentHashMap的源碼和底層原理，應(yīng)該知道里面的核心思路蠢甲，就是分段加鎖僵刮！
把數(shù)據(jù)分成很多個段，每個段是一個單獨的鎖鹦牛，所以多個線程過來并發(fā)修改數(shù)據(jù)的時候搞糕，可以并發(fā)的修改不同段的數(shù)據(jù)。不至于說曼追，同一時間只能有一個線程獨占修改ConcurrentHashMap中的數(shù)據(jù)窍仰。
另外，Java 8中新增了一個LongAdder類礼殊，也是針對Java 7以前的AtomicLong進行的優(yōu)化驹吮，解決的是CAS類操作在高并發(fā)場景下，使用樂觀鎖思路晶伦，會導(dǎo)致大量線程長時間重復(fù)循環(huán)碟狞。
LongAdder中也是采用了類似的分段CAS操作，失敗則自動遷移到下一個分段進行CAS的思路婚陪。
其實分布式鎖的優(yōu)化思路也是類似的族沃，之前我們是在另外一個業(yè)務(wù)場景下落地了這個方案到生產(chǎn)中，不是在庫存超賣問題里用的泌参。
但是庫存超賣這個業(yè)務(wù)場景不錯脆淹，很容易理解，所以我們就用這個場景來說一下沽一。大家看看下面的圖：
其實這就是分段加鎖盖溺。你想，假如你現(xiàn)在iphone有1000個庫存铣缠，那么你完全可以給拆成20個庫存段烘嘱，要是你愿意昆禽，可以在數(shù)據(jù)庫的表里建20個庫存字段，比如stock_01拙友，stock_02为狸，類似這樣的歼郭，也可以在redis之類的地方放20個庫存key遗契。
總之，就是把你的1000件庫存給他拆開病曾，每個庫存段是50件庫存牍蜂，比如stock_01對應(yīng)50件庫存，stock_02對應(yīng)50件庫存泰涂。
接著鲫竞，每秒1000個請求過來了，好逼蒙！此時其實可以是自己寫一個簡單的隨機算法从绘，每個請求都是隨機在20個分段庫存里，選擇一個進行加鎖是牢。
bingo僵井！這樣就好了，同時可以有最多20個下單請求一起執(zhí)行驳棱，每個下單請求鎖了一個庫存分段批什，然后在業(yè)務(wù)邏輯里面，就對數(shù)據(jù)庫或者是Redis中的那個分段庫存進行操作即可社搅，包括查庫存 -> 判斷庫存是否充足 -> 扣減庫存驻债。
這相當于什么呢？相當于一個20毫秒形葬，可以并發(fā)處理掉20個下單請求合呐，那么1秒，也就可以依次處理掉20 * 50 ?= 1000個對iphone的下單請求了笙以。
一旦對某個數(shù)據(jù)做了分段處理之后淌实，有一個坑大家一定要注意：就是如果某個下單請求，咔嚓加鎖源织，然后發(fā)現(xiàn)這個分段庫存里的庫存不足了翩伪，此時咋辦？
這時你得自動釋放鎖谈息，然后立馬換下一個分段庫存缘屹，再次嘗試加鎖后嘗試處理。這個過程一定要實現(xiàn)侠仇。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?轉(zhuǎn)載 石杉的架構(gòu)筆記
