今天就給大家聊一個(gè)有意思的話題：每秒上千訂單場景下蜜宪，如何對分布式鎖的并發(fā)能力進(jìn)行優(yōu)化虫埂？
背景引入
首先，我們一起來看看這個(gè)問題的背景圃验？
前段時(shí)間有個(gè)朋友在外面面試掉伏，然后有一天找我聊說：有一個(gè)國內(nèi)不錯(cuò)的電商公司，面試官給他出了一個(gè)場景題：
假如下單時(shí)澳窑，用分布式鎖來防止庫存超賣斧散，但是是每秒上千訂單的高并發(fā)場景，如何對分布式鎖進(jìn)行高并發(fā)優(yōu)化來應(yīng)對這個(gè)場景摊聋？
他說他當(dāng)時(shí)沒答上來颅湘，因?yàn)闆]做過沒什么思路。其實(shí)我當(dāng)時(shí)聽到這個(gè)面試題心里也覺得有點(diǎn)意思栗精，因?yàn)槿绻俏襾砻嬖嚭蜻x人的話闯参，應(yīng)該會(huì)給的范圍更大一些。
比如悲立，讓面試的同學(xué)聊一聊電商高并發(fā)秒殺場景下的庫存超賣解決方案鹿寨，各種方案的優(yōu)缺點(diǎn)以及實(shí)踐，進(jìn)而聊到分布式鎖這個(gè)話題薪夕。
因?yàn)閹齑娉u問題是有很多種技術(shù)解決方案的脚草，比如悲觀鎖，分布式鎖原献，樂觀鎖馏慨，隊(duì)列串行化，Redis原子操作姑隅，等等吧写隶。
但是既然那個(gè)面試官兄弟限定死了用分布式鎖來解決庫存超賣，我估計(jì)就是想問一個(gè)點(diǎn)：在高并發(fā)場景下如何優(yōu)化分布式鎖的并發(fā)性能讲仰。
我覺得慕趴，面試官提問的角度還是可以接受的，因?yàn)樵趯?shí)際落地生產(chǎn)的時(shí)候鄙陡，分布式鎖這個(gè)東西保證了數(shù)據(jù)的準(zhǔn)確性冕房，但是他天然并發(fā)能力有點(diǎn)弱。
剛好我之前在自己項(xiàng)目的其他場景下趁矾，確實(shí)是做過高并發(fā)場景下的分布式鎖優(yōu)化方案耙册，因此正好是借著這個(gè)朋友的面試題，把分布式鎖的高并發(fā)優(yōu)化思路毫捣，給大家來聊一聊详拙。
庫存超賣現(xiàn)象是怎么產(chǎn)生的帝际？
JAVA高階交流群：851531810
先來看看如果不用分布式鎖，所謂的電商庫存超賣是啥意思溪厘？大家看看下面的圖：
這個(gè)圖胡本，其實(shí)很清晰了牌柄，假設(shè)訂單系統(tǒng)部署兩臺(tái)機(jī)器上畸悬，不同的用戶都要同時(shí)買10臺(tái)iphone，分別發(fā)了一個(gè)請求給訂單系統(tǒng)珊佣。
接著每個(gè)訂單系統(tǒng)實(shí)例都去數(shù)據(jù)庫里查了一下蹋宦，當(dāng)前iphone庫存是12臺(tái)。
倆大兄弟一看咒锻，樂了冷冗，12臺(tái)庫存大于了要買的10臺(tái)數(shù)量啊惑艇！
于是乎蒿辙，每個(gè)訂單系統(tǒng)實(shí)例都發(fā)送SQL到數(shù)據(jù)庫里下單，然后扣減了10個(gè)庫存滨巴，其中一個(gè)將庫存從12臺(tái)扣減為2臺(tái)思灌，另外一個(gè)將庫存從2臺(tái)扣減為-8臺(tái)。
現(xiàn)在完了恭取，庫存出現(xiàn)了負(fù)數(shù)泰偿！淚奔啊，沒有20臺(tái)iphone發(fā)給兩個(gè)用戶膀诳濉耗跛！這可如何是好。
用分布式鎖如何解決庫存超賣問題攒发？
我們用分布式鎖如何解決庫存超賣問題呢调塌？其實(shí)很簡單，回憶一下上次我們說的那個(gè)分布式鎖的實(shí)現(xiàn)原理：
同一個(gè)鎖key惠猿，同一時(shí)間只能有一個(gè)客戶端拿到鎖烟阐，其他客戶端會(huì)陷入無限的等待來嘗試獲取那個(gè)鎖，只有獲取到鎖的客戶端才能執(zhí)行下面的業(yè)務(wù)邏輯紊扬。
代碼大概就是上面那個(gè)樣子蜒茄，現(xiàn)在我們來分析一下，為啥這樣做可以避免庫存超賣餐屎？
大家可以順著上面的那個(gè)步驟序號(hào)看一遍檀葛，馬上就明白了。
從上圖可以看到腹缩，只有一個(gè)訂單系統(tǒng)實(shí)例可以成功加分布式鎖屿聋，然后只有他一個(gè)實(shí)例可以查庫存空扎、判斷庫存是否充足、下單扣減庫存润讥，接著釋放鎖转锈。
釋放鎖之后，另外一個(gè)訂單系統(tǒng)實(shí)例才能加鎖楚殿，接著查庫存撮慨，一下發(fā)現(xiàn)庫存只有2臺(tái)了，庫存不足脆粥，無法購買砌溺，下單失敗。不會(huì)將庫存扣減為-8的变隔。
分布式鎖的方案在高并發(fā)場景下
好规伐，現(xiàn)在我們來看看，分布式鎖的方案在高并發(fā)場景下有什么問題匣缘？
問題很大安痢！兄弟肌厨，不知道你看出來了沒有培慌。分布式鎖一旦加了之后，對同一個(gè)商品的下單請求夏哭，會(huì)導(dǎo)致所有客戶端都必須對同一個(gè)商品的庫存鎖key進(jìn)行加鎖检柬。
比如，對iphone這個(gè)商品的下單竖配，都必對“iphone_stock”這個(gè)鎖key來加鎖何址。這樣會(huì)導(dǎo)致對同一個(gè)商品的下單請求，就必須串行化进胯，一個(gè)接一個(gè)的處理用爪。
大家再回去對照上面的圖反復(fù)看一下，應(yīng)該能想明白這個(gè)問題胁镐。
假設(shè)加鎖之后偎血，釋放鎖之前，查庫存 -> 創(chuàng)建訂單 -> 扣減庫存盯漂，這個(gè)過程性能很高吧颇玷，算他全過程20毫秒，這應(yīng)該不錯(cuò)了就缆。
那么1秒是1000毫秒帖渠，只能容納50個(gè)對這個(gè)商品的請求依次串行完成處理。
比如一秒鐘來50個(gè)請求竭宰，都是對iphone下單的空郊，那么每個(gè)請求處理20毫秒份招，一個(gè)一個(gè)來，最后1000毫秒正好處理完50個(gè)請求狞甚。
大家看一眼下面的圖锁摔，加深一下感覺。
所以看到這里哼审，大家起碼也明白了谐腰，簡單的使用分布式鎖來處理庫存超賣問題，存在什么缺陷棺蛛。
缺陷就是同一個(gè)商品多用戶同時(shí)下單的時(shí)候怔蚌，會(huì)基于分布式鎖串行化處理巩步，導(dǎo)致沒法同時(shí)處理同一個(gè)商品的大量下單的請求旁赊。
這種方案，要是應(yīng)對那種低并發(fā)椅野、無秒殺場景的普通小電商系統(tǒng)终畅，可能還可以接受。
因?yàn)槿绻l(fā)量很低竟闪，每秒就不到10個(gè)請求离福，沒有瞬時(shí)高并發(fā)秒殺單個(gè)商品的場景的話，其實(shí)也很少會(huì)對同一個(gè)商品在一秒內(nèi)瞬間下1000個(gè)訂單炼蛤，因?yàn)樾‰娚滔到y(tǒng)沒那場景妖爷。
如何對分布式鎖進(jìn)行高并發(fā)優(yōu)化？
好了理朋，終于引入正題了絮识，那么現(xiàn)在怎么辦呢？
面試官說嗽上，我現(xiàn)在就卡死次舌，庫存超賣就是用分布式鎖來解決，而且一秒對一個(gè)iphone下上千訂單兽愤，怎么優(yōu)化彼念？
現(xiàn)在按照剛才的計(jì)算，你一秒鐘只能處理針對iphone的50個(gè)訂單浅萧。
其實(shí)說出來也很簡單逐沙，相信很多人看過java里的ConcurrentHashMap的源碼和底層原理，應(yīng)該知道里面的核心思路洼畅，就是分段加鎖吩案！
JAVA高階交流群：851531810
把數(shù)據(jù)分成很多個(gè)段，每個(gè)段是一個(gè)單獨(dú)的鎖土思，所以多個(gè)線程過來并發(fā)修改數(shù)據(jù)的時(shí)候务热，可以并發(fā)的修改不同段的數(shù)據(jù)忆嗜。不至于說，同一時(shí)間只能有一個(gè)線程獨(dú)占修改ConcurrentHashMap中的數(shù)據(jù)崎岂。
另外捆毫，Java 8中新增了一個(gè)LongAdder類，也是針對Java 7以前的AtomicLong進(jìn)行的優(yōu)化冲甘，解決的是CAS類操作在高并發(fā)場景下绩卤，使用樂觀鎖思路，會(huì)導(dǎo)致大量線程長時(shí)間重復(fù)循環(huán)江醇。
LongAdder中也是采用了類似的分段CAS操作濒憋，失敗則自動(dòng)遷移到下一個(gè)分段進(jìn)行CAS的思路。
其實(shí)分布式鎖的優(yōu)化思路也是類似的陶夜，之前我們是在另外一個(gè)業(yè)務(wù)場景下落地了這個(gè)方案到生產(chǎn)中凛驮，不是在庫存超賣問題里用的。
但是庫存超賣這個(gè)業(yè)務(wù)場景不錯(cuò)条辟，很容易理解黔夭，所以我們就用這個(gè)場景來說一下。大家看看下面的圖：
其實(shí)這就是分段加鎖羽嫡。你想本姥，假如你現(xiàn)在iphone有1000個(gè)庫存，那么你完全可以給拆成20個(gè)庫存段杭棵，要是你愿意婚惫，可以在數(shù)據(jù)庫的表里建20個(gè)庫存字段，比如stock_01魂爪，stock_02先舷，類似這樣的，也可以在redis之類的地方放20個(gè)庫存key甫窟。
總之密浑，就是把你的1000件庫存給他拆開，每個(gè)庫存段是50件庫存粗井，比如stock_01對應(yīng)50件庫存尔破，stock_02對應(yīng)50件庫存。
接著浇衬，每秒1000個(gè)請求過來了懒构，好！此時(shí)其實(shí)可以是自己寫一個(gè)簡單的隨機(jī)算法耘擂，每個(gè)請求都是隨機(jī)在20個(gè)分段庫存里胆剧，選擇一個(gè)進(jìn)行加鎖。
bingo！這樣就好了秩霍，同時(shí)可以有最多20個(gè)下單請求一起執(zhí)行篙悯，每個(gè)下單請求鎖了一個(gè)庫存分段，然后在業(yè)務(wù)邏輯里面铃绒，就對數(shù)據(jù)庫或者是Redis中的那個(gè)分段庫存進(jìn)行操作即可鸽照，包括查庫存 -> 判斷庫存是否充足 -> 扣減庫存。
這相當(dāng)于什么呢颠悬？相當(dāng)于一個(gè)20毫秒矮燎，可以并發(fā)處理掉20個(gè)下單請求，那么1秒赔癌，也就可以依次處理掉20 * 50 ?= 1000個(gè)對iphone的下單請求了诞外。
JAVA高階交流群：851531810
一旦對某個(gè)數(shù)據(jù)做了分段處理之后，有一個(gè)坑大家一定要注意：就是如果某個(gè)下單請求灾票，咔嚓加鎖峡谊，然后發(fā)現(xiàn)這個(gè)分段庫存里的庫存不足了，此時(shí)咋辦铝条？
這時(shí)你得自動(dòng)釋放鎖靖苇，然后立馬換下一個(gè)分段庫存席噩，再次嘗試加鎖后嘗試處理班缰。這個(gè)過程一定要實(shí)現(xiàn)。
分布式鎖并發(fā)優(yōu)化方案有沒有什么不足悼枢？
不足肯定是有的埠忘，最大的不足，大家發(fā)現(xiàn)沒有馒索，很不方便坝ǘ省！實(shí)現(xiàn)太復(fù)雜了绰上。
首先旨怠，你得對一個(gè)數(shù)據(jù)分段存儲(chǔ)，一個(gè)庫存字段本來好好的蜈块，現(xiàn)在要分為20個(gè)分段庫存字段鉴腻；
其次，你在每次處理庫存的時(shí)候百揭，還得自己寫隨機(jī)算法爽哎，隨機(jī)挑選一個(gè)分段來處理；
最后器一，如果某個(gè)分段中的數(shù)據(jù)不足了课锌，你還得自動(dòng)切換到下一個(gè)分段數(shù)據(jù)去處理。
這個(gè)過程都是要手動(dòng)寫代碼實(shí)現(xiàn)的祈秕，還是有點(diǎn)工作量渺贤，挺麻煩的雏胃。
不過我們確實(shí)在一些業(yè)務(wù)場景里，因?yàn)橛玫搅朔植际芥i志鞍，然后又必須要進(jìn)行鎖并發(fā)的優(yōu)化丑掺，又進(jìn)一步用到了分段加鎖的技術(shù)方案，效果當(dāng)然是很好的了述雾，一下子并發(fā)性能可以增長幾十倍街州。
JAVA高階交流群：851531810
