Reference:??http://blog.ruaby.com/?p=256

并發(fā)事務處理帶來的問題?

相對于串行處理來說，并發(fā)事務處理能大大增加數(shù)據(jù)庫資源的利用率，提高數(shù)據(jù)庫系統(tǒng)的事務吞吐量，從而可以支持更多的用戶。但并發(fā)事務處理也會帶來一些問題，主要包括以下幾種情況:

更新丟失(ost Update)：當兩個或多個事務選擇同一行，然后基于最初選定的值更新該行時，由于每個事務都不知道其他事務的存在，就會發(fā)生丟失更新問題－－最后的更新覆蓋了由其他事務所做的更新。例如，兩個編輯人員制作了同一文檔的電子副本。每個編輯人員獨立地更改其副本，然后保存更改后的副本，這樣就覆蓋了原始文檔。最后保存其更改副本的編輯人員覆蓋另一個編輯人員所做的更改。如果在一個編輯人員完成并提交事務之前，另一個編輯人員不能訪問同一文件，則可避免此問題。

臟讀(Dirty Reads)：一個事務正在對一條記錄做修改，在這個事務完成并提交前，這條記錄的數(shù)據(jù)就處于不一致狀態(tài)；這時，另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些“臟”數(shù)據(jù)，并據(jù)此做進一步的處理，就會產(chǎn)生未提交的數(shù)據(jù)依賴關系。這種現(xiàn)象被形象地叫做”臟讀”。

不可重復讀(Non-Repeatabe Reads)：一個事務在讀取某些數(shù)據(jù)后的某個時間，再次讀取以前讀過的數(shù)據(jù)，卻發(fā)現(xiàn)其讀出的數(shù)據(jù)已經(jīng)發(fā)生了改變、或某些記錄已經(jīng)被刪除了！這種現(xiàn)象就叫做“不可重復讀”。

幻讀(Phantom Reads)：一個事務按相同的查詢條件重新讀取以前檢索過的數(shù)據(jù)，卻發(fā)現(xiàn)其他事務插入了滿足其查詢條件的新數(shù)據(jù)，這種現(xiàn)象就稱為“幻讀”。

事務隔離級別

在上面講到的并發(fā)事務處理帶來的問題中，“更新丟失”通常是應該完全避免的。但防止更新丟失，并不能單靠數(shù)據(jù)庫事務控制器來解決，需要應用程序?qū)σ碌臄?shù)據(jù)加必要的鎖來解決，因此，防止更新丟失應該是應用的責任。

“臟讀”、“不可重復讀”和“幻讀”，其實都是數(shù)據(jù)庫讀一致性問題，必須由數(shù)據(jù)庫提供一定的事務隔離機制來解決。數(shù)據(jù)庫實現(xiàn)事務隔離的方式，基本上可分為以下兩種:

一種是在讀取數(shù)據(jù)前，對其加鎖，阻止其他事務對數(shù)據(jù)進行修改。

另一種是不用加任何鎖，通過一定機制生成一個數(shù)據(jù)請求時間點的一致性數(shù)據(jù)快照(Snapshot)，并用這個快照來提供一定級別(語句級或事務級)的一致性讀取。從用戶的角度來看，好象是數(shù)據(jù)庫可以提供同一數(shù)據(jù)的多個版本，因此，這種技術叫做數(shù)據(jù)多版本并發(fā)控制(MutiVersion Concurrency Contro，簡稱MVCC或MCC)，也經(jīng)常稱為多版本數(shù)據(jù)庫。

數(shù)據(jù)庫的事務隔離越嚴格，并發(fā)副作用越小，但付出的代價也就越大，因為事務隔離實質(zhì)上就是使事務在一定程度上 “串行化”進行，這顯然與“并發(fā)”是矛盾的。同時，不同的應用對讀一致性和事務隔離程度的要求也是不同的，比如許多應用對“不可重復讀”和“幻讀”并不敏感，可能更關心數(shù)據(jù)并發(fā)訪問的能力。

InnoDB的行鎖模式及加鎖方法

InnoDB實現(xiàn)了以下兩種類型的行鎖。

共享鎖(S)：允許一個事務去讀一行，阻止其他事務獲得相同數(shù)據(jù)集的排他鎖。

排他鎖(X)：允許獲得排他鎖的事務更新數(shù)據(jù)，阻止其他事務取得相同數(shù)據(jù)集的共享讀鎖和排他寫鎖。

對于UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及數(shù)據(jù)集加排他鎖(X)；對于普通SELECT語句，InnoDB不會加任何鎖；事務可以通過以下語句顯示給記錄集加共享鎖或排他鎖。

共享鎖(S)：SELECT * FROM table_name WHERE … LOCK IN SHARE MODE。

排他鎖(X)：SELECT * FROM table_name WHERE … FOR UPDATE。

用SELECT … IN SHARE MODE獲得共享鎖，主要用在需要數(shù)據(jù)依存關系時來確認某行記錄是否存在，并確保沒有人對這個記錄進行UPDATE或者DELETE操作。但是如果當前事務也需要對該記錄進行更新操作，則很有可能造成死鎖，對于鎖定行記錄后需要進行更新操作的應用，應該使用SELECT… FOR UPDATE方式獲得排他鎖。

秒殺系統(tǒng)的實現(xiàn)

按照正常的購買流程：查詢商品庫存，庫存大于0時，生成訂單，去庫存。如果出現(xiàn)并發(fā)，導致在查詢商品庫存的時候，庫存會一直出現(xiàn)大于0的情況，出現(xiàn)超賣現(xiàn)象。

基于mysql的事務和鎖實現(xiàn)方式：

1：開啟事務

2：查詢庫存，并顯示的設置寫鎖(排他鎖)：SELECT * FROM table_name WHERE … FOR UPDATE

3：生成訂單

4：去庫存，隱示的設置寫鎖(排他鎖)：UPDATE goods SET counts = counts – 1 WHERE id = 1

5：commit，釋放鎖

注意：

如果不開啟事務，第二步即使加鎖，第一個會話讀庫存結(jié)束后，變會釋放鎖，第二個會話仍有機會在去庫存前讀庫存，出現(xiàn)超賣。

如果開啟事務，第二步不加鎖，第一個會話讀庫存結(jié)束后，第二個會話容易出現(xiàn)【臟讀】，出現(xiàn)超賣。

即加事務，又加讀鎖：開啟事務，第一個會話讀庫存時加讀鎖，并發(fā)時，第二個會話也允許獲得讀庫存的讀鎖，但是在第一個會話執(zhí)行寫操作時，寫鎖便會等待第二個會話的讀鎖，第二個會話執(zhí)行寫操作時，寫鎖便會等待第一個會話的讀鎖，出現(xiàn)死鎖

即加事務，又加寫鎖：第一個會話讀庫存時加寫鎖，寫鎖會阻止其它事務的讀鎖和寫鎖。直到commit才會釋放，允許第二個會話查詢庫存，不會出現(xiàn)超賣現(xiàn)象。

總結(jié)

以上是生活随笔為你收集整理的秒杀 mysql 事务_秒杀怎么样才可以防止超卖？基于mysql的事务和锁实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。