一、分析問題

剛剛秒殺優(yōu)惠券購買測試的時候是我們自己在頁面上點擊進行測試的，這跟真實的秒殺場景還是有很大差異的，因為真實的秒殺場景下肯定有無數的用戶一起來搶購，一起來點購這個按鈕，因此一瞬間的并發(fā)量可能會達到每秒數百甚至上千、上萬的并發(fā)，那我們這個結構還能不能工作呢？

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

數據庫總量是100

將訂單也清0

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

啟動JeMeter，結果肯定有些成功有些失敗

查看報告 49.25% 的異常率，跟我們預期有出入，我們的預期應該是一般失敗

回到數據庫中查看，可以看見訂單生成數量是 102

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

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

那么我們?yōu)槭裁磿霈F這個問題呢？

有關超賣問題分析：在我們原有代碼中是這么寫的

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("庫存不足！");
}

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

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

二、解決辦法

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

悲觀鎖和樂觀鎖并不是真正的鎖，它只是鎖設計的理念

悲觀鎖：

如果我們多個線程是串行執(zhí)行的，就不會出現安全問題了。所以這就是悲觀鎖的實現思想，既然多線程并發(fā)有安全問題，那你就不要并發(fā)執(zhí)行了。正因為如此，悲觀鎖的性能就不是很好，因為你不管有多少線程，都只能一個一個的去執(zhí)行，因此高并發(fā)的場景下悲觀鎖并不是很適合。

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

樂觀鎖：

因為樂觀鎖折后轉給你方案它不用加鎖，而是在執(zhí)行時才做一個判斷，因此它的性能要比悲觀鎖好很多。

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

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

三、樂觀鎖

判斷是否有人進行修改，常見的方式有兩種

實現方式一：版本號法

這種方案是應用最廣泛的，也是最普遍的。

樂觀鎖：會有一個版本號，每次操作數據會對版本號+1，再提交回數據時，會去校驗是否比之前的版本大1 ，如果大1 ，則進行操作成功，這套機制的核心邏輯在于，如果在操作過程中，版本號只比原來大1 ，那么就意味著操作過程中沒有人對他進行過修改，他的操作就是安全的，如果不大1，則數據被修改過。

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

以前是直接扣減就完了，但是現在不行，版本號每次修改的時候都要加1，因此它在修改庫存的時候不僅僅要修改庫存，還需要修改版本號，因此在修改時，樂觀鎖的方案是：修改前先判斷一下，之前查詢到的數據是否被修改過，這里就是判斷版本是否被修改過， where version = 1，因為之前查詢出來的version是1，如果執(zhí)行這個條件時version依然等于1，說明跟我們之前查詢到的一樣，說明在我執(zhí)行修改之前，是沒有人修改過這個數據的，既然沒有人修改過，我就可以放心大膽的去減了。

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

實現方式二：CAS

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

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

核心思路和上面差不多

下面是補充，老師沒講的。

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

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

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

return var5;

總結

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論