當沒有并發時，上面的流程看起來是再正常不過了，假設同時兩個人下單，而庫存只有1個了，在sql1階段兩個人查詢到的庫存都是>0的，于是最終都執行了sql2，庫存最后變為-1，超售了，這不是我們想要的結果吧。

解決這個問題比較流行的思路我總結了下：

1. 用額外的單進程處理一個隊列，下單請求放到隊列里，一個個處理，就不會有并發的問題了，但是要額外的開啟后臺進程以及延遲問題，這里暫不予考慮。這里我可使用消息隊列，我們常用到Memcacheq、Radis。 比如：有100張票可供用戶搶，那么就可以把這100張票放到緩存中，讀寫時不要加鎖。 當并發量大的時候，可能有500人左右搶票成功，這樣對于500后面的請求可以直接轉到活動結束的靜態頁面。進去的500個人中有400個人是不可能獲得商品的。所以可以根據進入隊列的先后順序只能前100個人購買成功。后面400個人就直接轉到活動結束頁面。當然進去500個人只是舉個例子，至于多少可以自己調整。而活動結束頁面一定要用靜態頁面，不要用數據庫。這樣就減輕了數據庫的壓力。

2. mysql樂觀鎖，意思是比如總庫存是2,搶購事件提交時，立馬將庫存+1，那么此時庫存是3，然后訂單生成后，在更新庫存前再查詢一次庫存(因為訂單生成理所當然庫存-1，但是先不急，再查一次庫存返回結果是3)，看看跟預期的庫存數量(這里預期的庫存是3)是否保持一致，不一致就回滾，提示用戶庫存不足。這里說道悲觀鎖，可能有朋友會問，那一定有樂觀鎖了吧??這里我就淺談下我所了解的悲觀與樂觀鎖了

悲觀鎖與樂觀鎖是兩種常見的資源并發鎖設計思路，也是并發編程中一個非?；A的概念。本文將對這兩種常見的鎖機制在數據庫數據上的實現進行比較系統的介紹。

悲觀鎖（Pessimistic Lock）

悲觀鎖的特點是先獲取鎖，再進行業務操作，即“悲觀”的認為獲取鎖是非常有可能失敗的，因此要先確保獲取鎖成功再進行業務操作。通常所說的“一鎖二查三更新”即指的是使用悲觀鎖。通常來講在數據庫上的悲觀鎖需要數據庫本身提供支持，即通過常用的select … for update操作來實現悲觀鎖。當數據庫執行select for update時會獲取被select中的數據行的行鎖，因此其他并發執行的select for update如果試圖選中同一行則會發生排斥（需要等待行鎖被釋放），因此達到鎖的效果。select for update獲取的行鎖會在當前事務結束時自動釋放，因此必須在事務中使用。

這里需要注意的一點是不同的數據庫對select for update的實現和支持都是有所區別的，例如oracle支持select for update no wait，表示如果拿不到鎖立刻報錯，而不是等待，mysql就沒有no wait這個選項。另外mysql還有個問題是select for update語句執行中所有掃描過的行都會被鎖上，這一點很容易造成問題。因此如果在mysql中用悲觀鎖務必要確定走了索引，而不是全表掃描。

樂觀鎖（Optimistic Lock）

樂觀鎖的特點先進行業務操作，不到萬不得已不去拿鎖。即“樂觀”的認為拿鎖多半是會成功的，因此在進行完業務操作需要實際更新數據的最后一步再去拿一下鎖就好。

樂觀鎖在數據庫上的實現完全是邏輯的，不需要數據庫提供特殊的支持。一般的做法是在需要鎖的數據上增加一個版本號，或者時間戳，然后按照如下方式實現：

1. SELECT data AS old_data, version AS old_version FROM …;2. 根據獲取的數據進行業務操作，得到new_data和new_version3. UPDATE SET data = new_data, version = new_version WHERE version = old_versionif (updated row > 0) { // 樂觀鎖獲取成功，操作完成} else { // 樂觀鎖獲取失敗，回滾并重試}

樂觀鎖是否在事務中其實都是無所謂的，其底層機制是這樣：在數據庫內部update同一行的時候是不允許并發的，即數據庫每次執行一條update語句時會獲取被update行的寫鎖，直到這一行被成功更新后才釋放。因此在業務操作進行前獲取需要鎖的數據的當前版本號，然后實際更新數據時再次對比版本號確認與之前獲取的相同，并更新版本號，即可確認這之間沒有發生并發的修改。如果更新失敗即可認為老版本的數據已經被并發修改掉而不存在了，此時認為獲取鎖失敗，需要回滾整個業務操作并可根據需要重試整個過程。

在此嘮叨總結下這兩個鎖：

1. 樂觀鎖在不發生取鎖失敗的情況下開銷比悲觀鎖小，但是一旦發生失敗回滾開銷則比較大，因此適合用在取鎖失敗概率比較小的場景，可以提升系統并發性能。

2. 樂觀鎖還適用于一些比較特殊的場景，例如在業務操作過程中無法和數據庫保持連接等悲觀鎖無法適用的地方。

3. 根據update結果來判斷，我們可以在sql2的時候加一個判斷條件update table set 庫存=xxx where 庫存>0，如果返回false，則說明庫存不足，并回滾事務。

4. 借助文件排他鎖，在處理下單請求的時候，用flock鎖定一個文件，如果鎖定失敗說明有其他訂單正在處理，此時要么等待要么直接提示用戶"服務器繁忙"。大致代碼如下：

阻塞(等待)模式

$fp = fopen("lock.txt", "w+");if(flock($fp,LOCK_EX)) { // 鎖定當前指針，，，    //..處理訂單    flock($fp,LOCK_UN);}fclose($fp);

非阻塞模式

$fp = fopen("lock.txt", "w+");if(flock($fp,LOCK_EX | LOCK_NB)) {    //..處理訂單    flock($fp,LOCK_UN);} else {  echo "系統繁忙，請稍后再試";}fclose($fp);

5. 如果是分布式集群服務器，就需要一個或多個隊列服務器 小米和淘寶的搶購還是有稍許不同的，小米重在搶的那瞬間，搶到了名額，就是你的，你就可以下單結算。而淘寶則重在付款的時候的過濾，做了多層過濾，比如要賣10件商品，他會讓大于10的用戶搶到，在付款的時候再進行并發過濾，一層層的減少一瞬間的并發量。

6. 使用redis鎖 product_lock_key 為票鎖key 當product_key存在于redis中時，所有用戶都可以進入下單流程。 當進入支付流程時，首先往redis存放sadd(product_lock_key, “1″),如果返回成功，進入支付流程。如果不成，則說明已經有人進入支付流程，則線程等待N秒，遞歸執行sadd操作。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。