一、分析問題

剛剛秒殺優(yōu)惠券購買測(cè)試的時(shí)候是我們自己在頁面上點(diǎn)擊進(jìn)行測(cè)試的，這跟真實(shí)的秒殺場(chǎng)景還是有很大差異的，因?yàn)檎鎸?shí)的秒殺場(chǎng)景下肯定有無數(shù)的用戶一起來搶購，一起來點(diǎn)購這個(gè)按鈕，因此一瞬間的并發(fā)量可能會(huì)達(dá)到每秒數(shù)百甚至上千、上萬的并發(fā)，那我們這個(gè)結(jié)構(gòu)還能不能工作呢？

要想模擬這種高并發(fā)的場(chǎng)景，肯定要用到JeMter

數(shù)據(jù)庫總量是100

將訂單也清0

接下來我們有100個(gè)券，我們希望的是只賣出100個(gè)，理論上來講只生成100個(gè)訂單。

啟動(dòng)JeMeter，結(jié)果肯定有些成功有些失敗

查看報(bào)告 49.25% 的異常率，跟我們預(yù)期有出入，我們的預(yù)期應(yīng)該是一般失敗

回到數(shù)據(jù)庫中查看，可以看見訂單生成數(shù)量是 102

并且?guī)齑孀優(yōu)榱?-2

由此可見票出現(xiàn)了超賣，我們只能賣一百件，現(xiàn)在卻賣出了 102件，如果這件賣出的商品很貴重，這樣可能會(huì)給商家?guī)砭薮蟮膿p失。

那么我們?yōu)槭裁磿?huì)出現(xiàn)這個(gè)問題呢？

有關(guān)超賣問題分析：在我們?cè)写a中是這么寫的

if (voucher.getStock() < 1) {
    // 庫存不足
    return Result.fail("庫存不足！");
}
//5，扣減庫存
boolean success = seckillVoucherService.update()
    .setSql("stock= stock -1")
    .eq("voucher_id", voucherId).update();
if (!success) {
    //扣減庫存
    return Result.fail("庫存不足！");
}

正常情況下一個(gè)如下圖，一個(gè)執(zhí)行完再執(zhí)行另一個(gè)

但是高并發(fā)的場(chǎng)景下，你就沒辦法控制線程的順序了，假設(shè)線程1過來查詢庫存，判斷出來庫存大于1，正準(zhǔn)備去扣減庫存，但是還沒有來得及去扣減，此時(shí)線程2過來，線程2也去查詢庫存，發(fā)現(xiàn)這個(gè)數(shù)量一定也大于1，那么這兩個(gè)線程都會(huì)去扣減庫存，最終多個(gè)線程相當(dāng)于一起去扣減庫存，此時(shí)就會(huì)出現(xiàn)庫存的超賣問題。

二、解決辦法

超賣問題是典型的多線程安全問題，針對(duì)這一問題的常見解決方案就是加鎖：而對(duì)于加鎖，我們通常有兩種解決方案：見下圖：

悲觀鎖和樂觀鎖并不是真正的鎖，它只是鎖設(shè)計(jì)的理念

悲觀鎖：

如果我們多個(gè)線程是串行執(zhí)行的，就不會(huì)出現(xiàn)安全問題了。所以這就是悲觀鎖的實(shí)現(xiàn)思想，既然多線程并發(fā)有安全問題，那你就不要并發(fā)執(zhí)行了。正因?yàn)槿绱耍^鎖的性能就不是很好，因?yàn)槟悴还苡卸嗌倬€程，都只能一個(gè)一個(gè)的去執(zhí)行，因此高并發(fā)的場(chǎng)景下悲觀鎖并不是很適合。

JDK中提供的syn，和lock、數(shù)據(jù)庫中的互斥的鎖，都是悲觀鎖的代表，同時(shí)，悲觀鎖中又可以再細(xì)分為公平鎖，非公平鎖，可重入鎖，等等。

樂觀鎖：

因?yàn)闃酚^鎖折后轉(zhuǎn)給你方案它不用加鎖，而是在執(zhí)行時(shí)才做一個(gè)判斷，因此它的性能要比悲觀鎖好很多。

但是它的關(guān)鍵點(diǎn)在于：我怎么知道在我更新的時(shí)候別人有沒有來做修改？因此這個(gè)判斷成為了關(guān)鍵，這也是我們接下來要研究的。

悲觀鎖比較簡單，相信大家都會(huì)，這里就不演示了，這里就演示樂觀鎖

三、樂觀鎖

判斷是否有人進(jìn)行修改，常見的方式有兩種

實(shí)現(xiàn)方式一：版本號(hào)法

這種方案是應(yīng)用最廣泛的，也是最普遍的。

樂觀鎖：會(huì)有一個(gè)版本號(hào)，每次操作數(shù)據(jù)會(huì)對(duì)版本號(hào)+1，再提交回?cái)?shù)據(jù)時(shí)，會(huì)去校驗(yàn)是否比之前的版本大1 ，如果大1 ，則進(jìn)行操作成功，這套機(jī)制的核心邏輯在于，如果在操作過程中，版本號(hào)只比原來大1 ，那么就意味著操作過程中沒有人對(duì)他進(jìn)行過修改，他的操作就是安全的，如果不大1，則數(shù)據(jù)被修改過。

有了版本號(hào)后，線程1在做查詢的時(shí)候，就不僅僅是查庫存了，它還要將版本號(hào)也查出來，此時(shí)線程1查到的庫存和版本號(hào)是 1，緊接著，它本來要進(jìn)行扣減了，但是此時(shí)另外一個(gè)線程插入進(jìn)來了，此時(shí)就出現(xiàn)并發(fā)的問題了，此時(shí)線程二也去查詢，同樣也是查詢stock和version，查到的也是1。緊接著又切到了線程1，線程1要去扣減庫存，判斷庫存是否大于0，此時(shí)就要去扣減。

以前是直接扣減就完了，但是現(xiàn)在不行，版本號(hào)每次修改的時(shí)候都要加1，因此它在修改庫存的時(shí)候不僅僅要修改庫存，還需要修改版本號(hào)，因此在修改時(shí)，樂觀鎖的方案是：修改前先判斷一下，之前查詢到的數(shù)據(jù)是否被修改過，這里就是判斷版本是否被修改過， where version = 1，因?yàn)橹安樵兂鰜淼膙ersion是1，如果執(zhí)行這個(gè)條件時(shí)version依然等于1，說明跟我們之前查詢到的一樣，說明在我執(zhí)行修改之前，是沒有人修改過這個(gè)數(shù)據(jù)的，既然沒有人修改過，我就可以放心大膽的去減了。

那么第一個(gè)線程在操作后，數(shù)據(jù)庫中的version變成了2，但是他自己滿足version=1 ，所以沒有問題，此時(shí)線程2執(zhí)行，線程2 最后也需要加上條件version =1 ，但是現(xiàn)在由于線程1已經(jīng)操作過了，所以線程2，操作時(shí)就不滿足version=1 的條件了，所以線程2無法執(zhí)行成功

實(shí)現(xiàn)方式二：CAS

在實(shí)現(xiàn)方式一的基礎(chǔ)上做了簡化，版本號(hào)法其實(shí)是用版本來表示版本是否變化，其次在更新的時(shí)候每次除了數(shù)據(jù)以外，版本也要跟著更新，既然每次更新都要更新版本，如果我查到的版本跟我更新時(shí)的版本一致，證明就沒有人更新。但是大家看一下我們當(dāng)前的業(yè)務(wù)，我們每一次業(yè)務(wù)，其實(shí)在查詢版本的時(shí)候庫存也都跟著查出來了，更新的時(shí)候庫存也要更新，可以發(fā)現(xiàn)庫存跟版本所做的事是一樣的，既然如此為什么不使用庫存代替版本？我在查詢的時(shí)候?qū)齑娌槌鰜?，然后我在更新的時(shí)候當(dāng)前的這個(gè)庫存跟之前查到的庫存是不是一樣的，如果一樣，不就同樣可以證明沒有人修改過嗎？

用數(shù)據(jù)本身有沒有變化來判斷線程是否安全，這種方案就稱之為cas(compare and set)，先比較然后修改。

核心思路和上面差不多

下面是補(bǔ)充，老師沒講的。

利用cas進(jìn)行無鎖化機(jī)制加鎖，var5 是操作前讀取的內(nèi)存值，while中的var1+var2 是預(yù)估值，如果預(yù)估值 == 內(nèi)存值，則代表中間沒有被人修改過，此時(shí)就將新值去替換 內(nèi)存值

其中do while 是為了在操作失敗時(shí)，再次進(jìn)行自旋操作，即把之前的邏輯再操作一次。

int var5;
do {
    var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

return var5;

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論