涉及搶購、秒殺、抽獎、搶票等活動時，為了避免超賣,那麼庫存數量是有限的，但是如果同時下單人數超過了庫存數量，就會導致商品超賣問題。

sql1:秒殺
if(庫存數量 > 0)
{
  //生成訂單...

 //sql2
 //庫存-1
}

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

解決這個問題比較流行的思路我總結了下：
1.訊息佇列，下單請求放到佇列裡，一個個處理，就不會有併發的問題了，我們常用到Memcacheq、Radis作為中介軟體，

但是要額外的開啟後臺程序以及延遲問題， 比如：有100張票可供使用者搶，那麼就可以把這100張票放到快取中，讀寫時不要加鎖。 當併發量大的時候，可能有1000人左右搶票成功，這樣對於900後面的請求可以直接轉到活動結束的靜態頁面。進去的1000個人中有900個人是不可能獲得商品的。所以可以根據進入佇列的先後順序只能前100個人購買成功。後面900個人就直接轉到活動結束頁面。當然進去1000個人只是舉個例子，至於多少可以自己調整。而活動結束頁面一定要用靜態頁面，不要用資料庫。這樣就減輕了資料庫的壓力

樂觀鎖（Optimistic Lock）

---

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

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

1. SELECT data AS old_data, version AS old_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 {
    // 樂觀鎖獲取失敗，回滾並重試
}

3.根據update結果來判斷，我們可以在sql2的時候加一個判斷條件update table set 庫存=xxx where 庫存>0，如果返回false，則說明庫存不足，並回滾事務。
4.藉助檔案排他鎖，在處理下單請求的時候，用flock鎖定一個檔案，如果鎖定失敗說明有其他訂單正在處理，此時要麼等待要麼直接提示使用者"伺服器繁忙"

大致程式碼如下：
阻塞(等待)模式

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

非阻塞模式
 

<?php
$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操作。