背景：

本人上次做申領campaign的PHP後臺時，因為專案上線後某些時段同時申領的人過多，導致一些專櫃的存貨為負數（<0），還好併發量不是特別大，只存在於小部分專櫃而且一般都是-1的狀況，沒有造成特別特別嚴重的後果，但還是要反思了自己的過錯。

　　這次又有新的申領campaign，我翻看了上次的程式碼邏輯：

正文：

【先select後update】

1. beginTranse(開啟事務)
2. try{
3.     $result = $dbca->query('select amount from s_store where postID = 12345');
4.     if
   (result->amount > 0){
5.         $dbca->query('update s_store set amount = amount - 1 where postID = 12345');
6.     }
7. }catch($e Exception){
8.     rollBack(回滾)
9. }
10. commit(提交事務)

　　以上程式碼就是我第一次的寫法，看似問題不大，其實隱藏著巨大的漏洞。資料庫的訪問其實就是對磁碟檔案的訪問，資料庫中的表其實就是儲存在磁碟上的一個個檔案，甚至一個檔案包含了多張表。例如由於高併發，當前有三個使用者a、b、c三個使用者進入到了這個事務中，這個時候會產生一個共享鎖

　　然後是update，假如這三個使用者同時到達update這裡，這個時候update更新語句會把併發序列化，也就是給同時到達這裡的是三個使用者排個序，一個一個執行，並生成排他鎖，在當前這個update語句commit之前，其他使用者等待執行，commit後，生成新的版本；這樣執行完後，庫存肯定為負數了。但是根據以上描述，我們修改一下程式碼就不會出現超買現象了，程式碼如下：

【先update後select】

1. beginTranse(開啟事務)
2. try{
3.     $dbca->query('update s_store set
   amount = amount - 1 where postID = 12345');
4.     $result = $dbca->query('select amount from s_store where postID = 12345');
5.     if(result->amount < 0){
6.        throw new Exception('庫存不足');
7.     }
8. }catch($e Exception){
9.     rollBack(回滾)
10. }
11. commit(提交事務)

　　另外，更簡潔的方法：

【update & select合併】

1. beginTranse(開啟事務)
2. try{
3.     $dbca->query('update s_store set amount = amount - 1 where amount>=1 and postID = 12345');
4. }catch($e Exception){
5.     rollBack(回滾)
6. }
7. commit(提交事務)

========================================補充=============================================

1、這個肯定不能直接操作資料庫的，會掛的。直接讀庫寫庫對資料庫壓力太大，要用快取。

　　把你要賣出的商品比如10個商品放到快取中；然後在memcache裡設定一個計數器來記錄請求數，這個請求書你可以以你要秒殺賣出的商品數為基數，比如你想賣出10個商品，只允許100個請求進來。那當計數器達到100的時候，後面進來的就顯示秒殺結束，這樣可以減輕你的伺服器的壓力。然後根據這100個請求，先付款的先得後付款的提示商品以秒殺完。

2、首先，多使用者併發修改同一條記錄時，肯定是後提交的使用者將覆蓋掉前者提交的結果了。這個直接可以使用加鎖機制去解決，樂觀鎖或者悲觀鎖。

　　悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

　　樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料，可以使用版本號等機制。樂觀鎖適用於多讀的應用型別，這樣可以提高吞吐量，像資料庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。

　　兩種鎖各有優缺點，不能單純的定義哪個好於哪個。樂觀鎖比較適合資料修改比較少，讀取比較頻繁的場景，即使出現了少量的衝突，這樣也省去了大量的鎖的開銷，故而提高了系統的吞吐量。但是如果經常發生衝突（寫資料比較多的情況下），上層應用不不斷的retry，這樣反而降低了效能，對於這種情況使用悲觀鎖就更合適。

 3、不建議在資料庫層面加鎖，建議通過服務端的記憶體鎖（鎖主鍵）。

　　當某個使用者要修改某個id的資料時，把要修改的id存入memcache，若其他使用者觸發修改此id的資料時，讀到memcache有這個id的值時，就阻止那個使用者修改。

=======================================補充==============================================

參考資料:

【mysql處理高併發，防止庫存超賣】http://blog.csdn.net/caomiao2006/article/details/38568825

鎖機制  ---  MYSQL中的鎖和PHP中的鎖

1、MYSQL中的表：

語法 ：LOCK TABLE 表名1 READ|WRITE, 表名2 READ|WRITE ..................

       UNLOCK TABLES

Read讀鎖|共享鎖 ： 所有的客戶端只能讀這個表不能寫這個表

Write寫鎖|排它鎖： 所有當前鎖定客戶端可以操作這個表，其他客戶端只能阻塞

注意：在鎖表的過程中只能操作被鎖定的表，如果要操作其他表，必須把所有要操作的表都鎖定起來！！

2、PHP中的檔案鎖

檔案可以隨意名字，只要是個檔案就行。上面LOCK_EX 排他型。“此檔案相當與鑰匙，搶到鑰匙的才能進門。”

總結：專案中應該只使用PHP中的檔案鎖，儘量避免鎖表，因為如果表被鎖定了，那麼整個網站中所有和這個表相關的功能都被拖慢了。

應用場景：

1. 高併發下單時，減庫存量時要加鎖

2. 高併發搶單、搶票時要使用

如何模擬高併發訪問一個指令碼：可以使用APACHE中的ab.exe軟體：

Ab.exe：apache中用來做壓力測試。直接將ab.exe拖拽到dos黑窗中。

其它方案措施

  如今在電商行業裡,秒殺搶購活動已經是商家常用促銷手段。但是庫存數量有限，而同時下單人數超過了庫存量，就會導致商品超賣甚至庫存變負數的問題。
又比如：搶購火車票、論壇搶樓、抽獎乃至爆紅微博評論等也會引發阻塞式高併發問題。如果不做任何措施可能在高瞬間造成伺服器癱瘓，如何解決這個問題呢？
這裡提出個人認為比較可行的幾個思路方法：

  可以基於例如MemcacheQ等這樣的訊息佇列，具體的實現方案這麼表述吧
  比如有100張票可供使用者搶，那麼就可以把這100張票放到快取中，讀寫時不要加鎖。 當併發量大的時候，可能有500人左右搶票成功，這樣對於500後面的請求可以直接轉到活動結束的靜態頁面。進去的500個人中有400個人是不可能獲得商品的。所以可以根據進入佇列的先後順序只能前100個人購買成功。後面400個人就直接轉到活動結束頁面。當然進去500個人只是舉個例子，至於多少可以自己調整。而活動結束頁面一定要用靜態頁面，不要用資料庫。這樣就減輕了資料庫的壓力。

方案二：當有多臺伺服器時，可以採用分流的形式實現

  假設有m張票, 有n臺產品伺服器接收請求,有x個請求路由伺服器隨機轉發
  直接給每臺產品伺服器分配 m/n張票
  每臺產品伺服器記憶體做計數器,比如允許m/n*(1+0.1)個人進來。
  當記憶體計數器已滿：
  後面進的人, 直接跳到到轉到活動結束的靜態頁面，
  通知路由伺服器,不在路由到這臺伺服器(這個值得商討)。
  所有產品伺服器進來的m/n*(1+0.1)個人再全部轉發到一臺付款伺服器上,進入付款環節,看誰手快了,這時候人少,加鎖什麼的就簡單的。

方案三、如果是單伺服器，可以使用Memcache鎖來實現

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

方案四、藉助檔案排他鎖
  在處理下單請求的時候，用flock鎖定一個檔案，如果鎖定失敗說明有其他訂單正在處理，此時要麼等待要麼直接提示使用者"伺服器繁忙"
本文要說的是第4種方案，大致程式碼如下：

阻塞(等待)模式：

<?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);
?>