(方案)高併發下如何避免髒數據
1. 什麼是髒數據
髒數據是指從目標中取出的數據已經過期、錯誤或沒意義,當出現髒數據時,一般會涉及髒讀和髒寫兩種操作。
- 髒讀:讀取出來的髒數據稱為髒讀;
- 髒寫:寫入進去的髒數據稱為髒寫。
2.應用層面如何避免髒數據
- 髒讀:獲取經常變化的數據,高併發期間緩存數據與數據庫數據不一致問題:-- >解決方案: 利用數據庫鎖、Redis分佈式鎖和Zookeeper分佈式鎖來解決,參考http://my.oschina.net/pengchanghua/blog/3275206
- 髒寫:就是兩個事務沒提交的狀況下,都修改同一條數據,結果一個事務回滾了,把另外一個事務修改的值也撤銷了,所謂髒寫就是兩個事務沒提交狀態下修改同一個值。 --->解決方案:利用Redis緩存的IncrBy、incr函數,由於其具有原子性,在寫入過程中不會產生髒數據。 (注意:redis後台服務是串行的單線程執行,不存在併發,即多線程調用Incr/incrby方法,在redis服務器上仍然是串行的單線程執行,不存在併發,所以這倆命令都是原子自增、線程安全的。)
3.數據庫層面如何避免髒數據
如果多個事務要是對數據庫中的同一條數據同時進行更新或者查詢,此時會產生哪些問題呢?這裏實際上會涉及到髒寫、髒讀、不可重複讀、幻讀四種問題。
3.1 髒寫
當兩個事務同時嘗試去更新某一條數據記錄時,就肯定會存在一個先一個後。而當事務A更新時,事務A還沒提交,事務B就也過來進行更新,覆蓋了事務A提交的更新數據,這就是髒寫。
3.2 髒讀
如果一個事務A向數據庫寫了數據,但事務還沒提交或終止,另一個事務B就看到了事務A寫進數據庫的數據,這就是髒讀。
3.3 不可重複讀
如果你期望的是可重複讀,但是數據庫表現的是不可重複讀,讓你事務 A 執行期間多次查到的值都不一樣,都的問題是別的提交過的事務修改過的,那麼此時你就可以認為,數據庫有問題,這個問題就是「不可重複讀」
3.4 幻讀
簡單來説,你一個事務 A,先發送一條 SQL 語句,裏面有一個條件,要查詢一批數據出來,如SELECT * FROM table WHERE id > 10
。然後呢,它一開始查詢出來了 10 條數據。接着這個時候,別的事務 B往表裏插了幾條數據,而且事務 B 還提交了,此時多了幾行數據。
要解決上述問題,通過數據庫的隔離級別進行解決,如MYSQL。
Read Uncommitted(讀取未提交內容)
在該隔離級別,所有事務都可以看到其他未提交事務的執行結果。本隔離級別很少用於實際應用,因為它的性能也不比其他級別好多少。讀取未提交的數據,也被稱之為髒讀(Dirty Read)。
Read Committed(讀取已提交內容)
這是大多數數據庫系統的默認隔離級別(但不是MySQL默認的,ORACLE和 SQL Server 默認為該級別)。它滿足了隔離的簡單定義:一個事務只能看見已經提交事務所做的改變。這種隔離級別 也支持所謂的不可重複讀(Nonrepeatable Read),因為同一事務的其他實例在該實例處理其間可能會有新的commit,所以同一select可能返回不同結果。
Repeatable Read(可重讀)
這是MySQL的默認事務隔離級別,它確保同一事務的多個實例在併發讀取數據時,會看到同樣的數據行。不過理論上,這會導致另一個棘手的問題:幻讀 (Phantom Read)。簡單的説,幻讀指當用户讀取某一範圍的數據行時,另一個事務又在該範圍內插入了新行,當用户再讀取該範圍的數據行時,會發現有新的“幻影” 行。InnoDB和Falcon存儲引擎通過多版本併發控制(MVCC,Multiversion Concurrency Control)機制解決了該問題。
存在的問題: 條件列未命中索引會鎖表, 現死鎖的機率 比在讀取已提交RC多得多,而在RC隔離級別下,只鎖行。
所以針對互聯網高併發應用,如果用MYSQL也會將其默認隔離級別改成讀已提交RC .
http://my.oschina.net/pengchanghua/blog/4701283
Serializable(可串行化)
這是最高的隔離級別,它通過強制事務排序,使之不可能相互衝突,從而解決幻讀問題。簡言之,它是在每個讀的數據行上加上共享鎖。在這個級別,可能導致大量的超時現象和鎖競爭。
在MySQL中,實現了這四種隔離級別,分別有可能產生問題如下所示: