涉及搶購、秒殺、抽獎、搶票等活動時，為了避免超賣，那麼庫存數量是有限的，但是如果同時下單人數超過了庫存數量，就會導致商品超賣問題。那我們要怎麼解決這個問題呢，我的想法如下(偽代碼)： sql1:查詢商品庫存if(庫存數量> 0) { //產生訂單...
sql2:同時庫存-1}
當沒有並發時，上面的流程看起來是再正常不過了，假設同時兩個人下單，而庫存只有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)是否保持一致，不一致就回滾，提示用戶庫存不足。這裡說道悲觀鎖，可能有朋友會問，那一定有樂觀鎖了吧??這裡我就淺談下我所了解的悲觀與樂觀鎖了
悲觀鎖與樂觀鎖是兩種常見的資源並發鎖設計思路，也是並發程式設計中一個非常基礎的概念。本文將對這兩種常見的鎖定機制在資料庫資料上的實作進行比較系統的介紹。
悲觀鎖（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操作。
