Mysql 事務及數據的一致性處理

在工做中，咱們常常會遇到這樣的問題，須要更新庫存，當咱們查詢到可用的庫存準備修改時，這時，其餘的用戶可能已經對這個庫存數據進行修改了，致使，咱們查詢到的數據會有問題，下面咱們就來看解決方法。

在MySQL的InnoDB中，預設的Tansaction isolation level 爲REPEATABLE READ（可重讀）

若是SELECT 後面若要UPDATE 同一個表單，最好使用SELECT ... UPDATE。

舉個例子:

　　假設商品表單products 內有一個存放商品數量的quantity ，在訂單成立以前必須先肯定quantity 商品數量是否足夠(quantity>0) ，而後才把數量更新爲1。代碼以下:

SELECT quantity FROM products WHERE id=3; UPDATE products SET quantity = 1 WHERE id=3;

爲何不安全呢?

少許的情況下或許不會有問題，可是大量的數據存取「鐵定」會出問題。若是咱們須要在quantity>0 的狀況下才能扣庫存，假設程序在第一行SELECT 讀到的quantity 是2 ，看起來數字沒有錯，可是當MySQL 正準備要UPDATE 的時候，可能已經有人把庫存扣成0 了，可是程序卻渾然不知，將錯就錯的UPDATE 下去了。所以必須透過的事務機制來確保讀取及提交的數據都是正確的。

因而咱們在MySQL 就能夠這樣測試，代碼以下:

SET AUTOCOMMIT=0; BEGIN WORK; SELECT quantity FROM products WHERE id=3 FOR UPDATE;

此時products 數據中id=3 的數據被鎖住(注3)，其它事務必須等待這次事務 提交後才能執行

SELECT * FROM products WHERE id=3 FOR UPDATE

如此能夠確保quantity 在別的事務讀到的數字是正確的。

UPDATE products SET quantity = '1' WHERE id=3 ; COMMIT WORK;

提交(Commit)寫入數據庫，products 解鎖。
注1: BEGIN/COMMIT 爲事務的起始及結束點，可以使用二個以上的MySQL Command 視窗來交互觀察鎖定的情況。
注2: 在事務進行當中，只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一筆數據時會等待其它事務結束後才執行，通常SELECT ... 則不受此影響。
注3: 因爲InnoDB 預設爲Row-level Lock，數據列的鎖定可參考這篇。
注4: InnoDB 表單儘可能不要使用LOCK TABLES 指令，若情非得已要使用，請先看官方對於InnoDB 使用LOCK TABLES 的說明，以避免形成系統常常發生死鎖。

更高級用法

若是咱們須要先查詢，後更新數據的話，最好能夠這樣使用語句：

UPDATE products SET quantity = '1' WHERE id=3 AND quantity > 0;

這樣，能夠不用添加事物就可處理。

mysql處理高併發，防止庫存超賣

看到了一篇很是好的文章，特轉此學習。

今天王總又給咱們上了一課，其實mysql處理高併發，防止庫存超賣的問題，在去年的時候，王總已經提過；可是很惋惜，即便當時你們都聽懂了，可是在現實開發中，仍是沒這方面的意識。今天就個人一些理解，整理一下這個問題，並但願之後這樣的課程能多點。

先來就庫存超賣的問題做描述：通常電子商務網站都會遇到如團購、秒殺、特價之類的活動，而這樣的活動有一個共同的特色就是訪問量激增、上千甚至上萬人搶購一個商品。然而，做爲活動商品，庫存確定是頗有限的，如何控制庫存不讓出現超買，以防止形成沒必要要的損失是衆多電子商務網站程序員頭疼的問題，這同時也是最基本的問題。

從技術方面剖析，不少人確定會想到事務，可是事務是控制庫存超賣的必要條件，但不是充分必要條件。

舉例：

總庫存：4個商品

請求人：a、1個商品 b、2個商品 c、3個商品

程序以下：

beginTranse(開啓事務)

try{

    $result = $dbca->query('select amount from s_store where postID = 12345');

    if(result->amount > 0){

        //quantity爲請求減掉的庫存數量

        $dbca->query('update s_store set amount = amount - quantity where postID = 12345');

    }

}catch($e Exception){

    rollBack(回滾)

}

commit(提交事務)

以上代碼就是咱們平時控制庫存寫的代碼了，大多數人都會這麼寫，看似問題不大，其實隱藏着巨大的漏洞。數據庫的訪問其實就是對磁盤文件的訪問，數據庫中的表其實就是保存在磁盤上的一個個文件，甚至一個文件包含了多張表。例如因爲高併發，當前有三個用戶a、b、c三個用戶進入到了這個事務中，這個時候會產生一個共享鎖，因此在select的時候，這三個用戶查到的庫存數量都是4個，同時還要注意，mysql innodb查到的結果是有版本控制的，再其餘用戶更新沒有commit以前(也就是沒有產生新版本以前)，當前用戶查到的結果依然是就版本；

而後是update，假如這三個用戶同時到達update這裏，這個時候update更新語句會把併發串行化，也就是給同時到達這裏的是三個用戶排個序，一個一個執行，並生成排他鎖，在當前這個update語句commit以前，其餘用戶等待執行，commit後，生成新的版本；這樣執行完後，庫存確定爲負數了。可是根據以上描述，咱們修改一下代碼就不會出現超買現象了，代碼以下：

beginTranse(開啓事務)

try{

    //quantity爲請求減掉的庫存數量
    $dbca->query('update s_store set amount = amount - quantity where postID = 12345');

    $result = $dbca->query('select amount from s_store where postID = 12345');

    if(result->amount < 0){

       throw new Exception('庫存不足');

    }

}catch($e Exception){

    rollBack(回滾)

}

commit(提交事務)

另外，更簡潔的方法：

beginTranse(開啓事務)

try{

    //quantity爲請求減掉的庫存數量
    $dbca->query('update s_store set amount = amount - quantity where amount>=quantity and postID = 12345');

}catch($e Exception){

    rollBack(回滾)

}

commit(提交事務)

=====================================================================================

一、在秒殺的狀況下，確定不能如此高頻率的去讀寫數據庫，會嚴重形成性能問題的
必須使用緩存，將須要秒殺的商品放入緩存中，並使用鎖來處理其併發狀況。當接到用戶秒殺提交訂單的狀況下，先將商品數量遞減（加鎖/解鎖）後再進行其餘方面的處理，處理失敗在將數據遞增1（加鎖/解鎖），不然表示交易成功。
當商品數量遞減到0時，表示商品秒殺完畢，拒絕其餘用戶的請求。

二、這個確定不能直接操做數據庫的，會掛的。直接讀庫寫庫對數據庫壓力太大，要用緩存。
把你要賣出的商品好比10個商品放到緩存中；而後在memcache裏設置一個計數器來記錄請求數，這個請求書你能夠以你要秒殺賣出的商品數爲基數，好比你想賣出10個商品，只容許100個請求進來。那當計數器達到100的時候，後面進來的就顯示秒殺結束，這樣能夠減輕你的服務器的壓力。而後根據這100個請求，先付款的先得後付款的提示商品以秒殺完。

三、首先，多用戶併發修改同一條記錄時，確定是後提交的用戶將覆蓋掉前者提交的結果了。

這個直接可使用加鎖機制去解決，樂觀鎖或者悲觀鎖。
樂觀鎖:，就是在數據庫設計一個版本號的字段，每次修改都使其+1，這樣在提交時比對提交前的版本號就知道是否是併發提交了，可是有個缺點就是隻能是應用中控制，若是有跨應用修改同一條數據樂觀鎖就沒辦法了，這個時候能夠考慮悲觀鎖。

悲觀鎖:，就是直接在數據庫層面將數據鎖死，相似於oralce中使用select xxxxx from xxxx where xx=xx for update，這樣其餘線程將沒法提交數據。

除了加鎖的方式也可使用接收鎖定的方式，思路是在數據庫中設計一個狀態標識位，用戶在對數據進行修改前，將狀態標識位標識爲正在編輯的狀態，這樣其餘用戶要編輯此條記錄時系統將發現有其餘用戶正在編輯，則拒絕其編輯的請求，相似於你在操做系統中某文件正在執行，而後你要修改該文件時，系統會提醒你該文件不可編輯或刪除。

四、不建議在數據庫層面加鎖，建議經過服務端的內存鎖（鎖主鍵）。當某個用戶要修改某個id的數據時，把要修改的id存入memcache，若其餘用戶觸發修改此id的數據時，讀到memcache有這個id的值時，就阻止那個用戶修改。

五、實際應用中，並非讓mysql去直面大併發讀寫，會藉助「外力」，好比緩存、利用主從庫實現讀寫分離、分表、使用隊列寫入等方法來下降併發讀寫。

悲觀鎖和樂觀鎖

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

　　悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認爲別人會修改，因此每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關係型數據庫裏邊就用到了不少這種鎖機制，好比行鎖，表鎖等，讀鎖，寫鎖等，都是在作操做以前先上鎖。

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

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

實戰

對這個表的 amount 進行修改，開兩個命令行窗口

第一個窗口A;

SET AUTOCOMMIT=0; BEGIN WORK; SELECT * FROM order_tbl WHERE order_id='124' FOR UPDATE;

第二個窗口B：

# 更新訂單ID 124 的庫存數量
UPDATE `order_tbl` SET amount = 1 WHERE order_id = 124;

咱們能夠看到窗口A加了事物，鎖住了這條數據，窗口B執行時會出現這樣的問題：

第一個窗口完整的提交事物：

SET AUTOCOMMIT=0; BEGIN WORK; SELECT * FROM order_tbl WHERE order_id='124' FOR UPDATE;
UPDATE `order_tbl` SET amount = 10 WHERE order_id = 124;
COMMIT WORK;

---

mysql處理高併發，防止庫存超賣