摘要：樂觀鎖樂觀鎖實際上是一種邏輯思想，并不是數(shù)據(jù)庫的特性。悲觀鎖利用了存儲引擎的支持行鎖的特性。建議在用戶并發(fā)量不大的應用場景下，采用樂觀鎖的方式。在對數(shù)據(jù)一致性要求很高的情況下，可以犧牲一下性能，采用悲觀鎖。

MySQL5.5 版本之后默認采用innoDb 數(shù)據(jù)引擎.本文采用默認的存儲引擎。

樂觀鎖實際上是一種邏輯思想，并不是mysql 數(shù)據(jù)庫的特性。這個要區(qū)分清楚。
實現(xiàn)數(shù)據(jù)版本有兩種方式，第一種是使用版本號，第二種是使用時間戳。

使用方式：：

/** 偽代碼  number 庫存  goods_id 商品ID  version 版本號默認為0 **/

$sql="select number from goods where goods_id={$goods_id} and version= {$version} ";

// 時間戳方式查詢庫存
$sql="select number from goods where goods_id={$goods_id} and time < time() ";

$rs=mysqli_query($conn,$sql);

$row = $rs->fetch_assoc();

if($row["number"]>0){//高并發(fā)下會導致超賣

    if($row["number"]<$number){

        return insertLog("庫存不夠",3,$username);
    }

//庫存減少
 $sql="update goods set number=number-{$number},version += 1 where goods_id={$goods_id}  and number>0";

// 時間戳方式減少庫存
$sql="update goods set number=number-{$number},time = time() where goods_id={$goods_id}  and number>0";

$store_rs=mysqli_query($conn,$sql);

if($store_rs){

//生成訂單,返回操作成功
                    
echo json_encode(array("code"=>0,"msg"=>"庫存減少成功","data"=>$username));

}else{
   echo json_encode(array("code"=>1,"msg"=>"庫存減少失敗","data"=>$username));
}
}else{
    echo json_encode(array("code"=>3,"msg"=>"庫存減少失敗","data"=>$username));
}
      
            

注意：使用樂觀鎖需要注意啊，將庫存字段number字段設為unsigned，當庫存為0時，因為字段不能為負數(shù)，將會返回false

悲觀鎖指的是對數(shù)據(jù)被外界（包括本系統(tǒng)當前的其他事務，以及來自外部系統(tǒng)的事務處理）修改持保守態(tài)度，因此，在整個數(shù)據(jù)處理過程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機制（也只有數(shù)據(jù)庫層提供的鎖機制才能真正保證數(shù)據(jù)訪問的排他性，否則，即使在本系統(tǒng)中實現(xiàn)了加鎖機制，也無法保證外部系統(tǒng)不會修改數(shù)據(jù)）。
悲觀鎖利用了MySQL innoDB 存儲引擎的支持行鎖的特性。一行一行操作數(shù)據(jù).

使用方式：

// 使用悲觀鎖鎖住當前行
$sql="select number from goods where goods_id={$goods_id} for update ";

// 減少庫存操作
$sql="update goods set number=number-{$number} where goods_id={$goods_id}  and number>0";
   

注意：innoDB 行鎖是基于索引來執(zhí)行的，where 條件后必須有索引，不然走的就是全表掃描。

優(yōu)點與不足：

悲觀并發(fā)控制實際上是“先取鎖再訪問”的保守策略，為數(shù)據(jù)處理的安全提供了保證。但是在效率方面，處理加鎖的機制會讓數(shù)據(jù)庫產(chǎn)生額外的開銷，還有增加產(chǎn)生死鎖的機會；另外，在只讀型事務處理中由于不會產(chǎn)生沖突，也沒必要使用鎖，這樣做只能增加系統(tǒng)負載；還有會降低了并行性，一個事務如果鎖定了某行數(shù)據(jù)，其他事務就必須等待該事務處理完才可以處理那行數(shù)
樂觀并發(fā)控制相信事務之間的數(shù)據(jù)競爭(datarace)的概率是比較小的，因此盡可能直接做下去，直到提交的時候才去鎖定，所以不會產(chǎn)生任何鎖和死鎖。但如果直接簡單這么做，還是有可能會遇到不可預期的結(jié)果，例如兩個事務都讀取了數(shù)據(jù)庫的某一行，經(jīng)過修改以后寫回數(shù)據(jù)庫，這時就遇到了問題。

建議： 在用戶并發(fā)量不大的應用場景下，采用樂觀鎖的方式。在對數(shù)據(jù)一致性要求很高的情況下，可以犧牲一下性能，采用悲觀鎖。這個兩種方式的前提是采用MySQL的解決方案。