涉及搶購、秒殺、**、搶票等活動時，為了避免超賣，那麼庫存數量是有限的，但是如果同時下單人數超過了庫存數量，就會導致商品超賣問題。那麼我們怎麼來解決這個問題呢，
解決這個問題比較流行的思路我總結了下：
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 asold_version from …;
2.根據獲取的資料進行業務操作，得到new_data和new_version
3. update set data = new_data, version = new_version where version =old_version
if (updated row > 0) else
樂觀鎖是否在事務中其實都是無所謂的，其底層機制是這樣：在資料庫內部update同一行的時候是不允許併發的，即資料庫每次執行一條update語句時會獲取被update行的寫鎖，直到這一行被成功更新後才釋放。因此在業務操作進行前獲取需要鎖的資料的當前版本號，然後實際更新資料時再次對比版本號確認與之前獲取的相同，並更新版本號，即可確認這之間沒有發生併發的修改。如果更新失敗即可認為老版本的資料已經被併發修改掉而不存在了，此時認為獲取鎖失敗，需要回滾整個業務操作並可根據需要重試整個過程。
在此嘮叨總結下這兩個鎖：
1. 樂觀鎖在不發生取鎖失敗的情況下開銷比悲觀鎖小，但是一旦發生失敗回滾開銷則比較大，因此適合用在取鎖失敗概率比較小的場景，可以提公升系統併發效能。
2. 樂觀鎖還適用於一些比較特殊的場景，例如在業務操作過程中無法和資料庫保持連線等悲觀鎖無法適用的地方。
3. 根據update結果來判斷，我們可以在sql2的時候加乙個判斷條件update table set 庫存=*** where 庫存》0，如果返回false，則說明庫存不足，並回滾事務。
4. 借助檔案排他鎖，在處理下單請求的時候，用flock鎖定乙個檔案，如果鎖定失敗說明有其他訂單正在處理，此時要麼等待要麼直接提示使用者"伺服器繁忙"。大致**如下：
阻塞(等待)模式
$fp = fopen("lock.txt", "w+");
if(flock($fp,lock_ex))
fclose($fp);
非阻塞模式
$fp = fopen("lock.txt", "w+");
if(flock($fp,lock_ex |lock_nb))
else
fclose($fp);
5. 如果是分布式集群伺服器，就需要乙個或多個佇列伺服器 小公尺和**的搶購還是有稍許不同的，小公尺重在搶的那瞬間，搶到了名額，就是你的，你就可以下單結算。而**則重在付款的時候的過濾，做了多層過濾，比如要賣10件商品，他會讓大於10的使用者搶到，在付款的時候再進行併發過濾，一層層的減少一瞬間的併發量。
6. 使用redis鎖 product_lock_key 為票鎖key 當product_key存在於redis中時，所有使用者都可以進入下單流程。 當進入支付流程時，首先往redis存放sadd(product_lock_key, 「1″),如果返回成功，進入支付流程。如果不成，則說明已經有人進入支付流程，則執行緒等待n秒，遞迴執行sadd操作。
鎖 排它鎖 悲觀鎖
查詢中a使用 for update 當其他使用者查詢被鎖的記錄的時候，會跳過這條記錄。如 a select from test zhi where khh 001676786773 for update 預設行級鎖 b select from test zhi for update skip loc...
mysql樂觀鎖 悲觀鎖 共享鎖與排它鎖
樂觀鎖 樂觀併發控制 和悲觀鎖 悲觀併發控制 是指資料庫在對待併發上控制的兩種思想，共享鎖和排它鎖是具體的鎖的實現，且都屬於悲觀鎖。樂觀鎖沒有加鎖 獲取資料的時候不用獲取鎖，直到需要更新資料的時候才去檢查獲取的記錄是否已被其他事務更新，如果更新了則返回錯誤拋異常。注意的是，樂觀鎖中沒有鎖機制，通常的...
C 樂觀鎖 悲觀鎖 共享鎖 排它鎖 互斥鎖
悲觀鎖 pessimistic lock 顧名思義，就是很悲觀，每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。通過 jdbc 實...