數據庫併發事務控制 一:綜述

併發控制是DBMS的關鍵技術

對數據庫的操作都是在事務中進行的。
事務是指一組相互依賴的操作行爲。事務中的操作是不可分割的工作單元,由一組在業務邏輯上相互依賴的SQL語句組成,有ACID特徵。
    Atomic(原子性):事務中包含的操作被看做一個邏輯單元,這個邏輯單元中的操作要麼全部成功,要麼全部失敗。
    Consistency(一致性):只有合法的數據可以被寫入數據庫,否則事務應該將其回滾到最初狀態。
    Isolation(隔離性):事務允許多個用戶對同一個數據進行併發訪問,而不破壞數據的正確性和完整性。同時,並行事務的修改必須與其他並行事務的修改相互獨立。
    Durability(持久性):事務結束後,事務處理的結果必須能夠得到固化。

數據庫中有多個事務同時存在,就是事務併發,此時就不能保證事務隔離性,SQL-92定義了事務隔離級別,描述了給定事務的行爲對其它併發執行事務的暴露程度,或者說是一個事務必須與其它事務進行隔離的程度。隔離級別由低到高爲:
Read Uncommitted,Read Committed,Repeatable Read, Serializable
隔離級別越高,越能保證數據的完整性和一致性,但對併發性能的影響也越大。

併發事務操作相同的數據時會出現衝突,不能完全保證數據的完整性和一致性,此時可能會出現以下問題:
    Lost update(第一類丟失更新):撤銷一個事務時,把其他事務已提交的更新數據覆蓋。
    Dirty Reads(髒讀):一個事務讀到另一事務未提交的更新數據。
    Phantom Reads(虛讀):一個事務讀到另一事務已提交的新插入的數據。
    Non-repeatable Reads(不可重複讀):一個事務讀到另一事務已提交的更新數據。
    Second lost updates problem(第二類丟失更新):這是不可重複讀中的特例,一個事務覆蓋另一事務已提交的更新數據。

事務隔離級別和可能出現的問題


保證併發事務準確性的關鍵是讓衝突的相關事務調度可串行化。理論上,某一事務執行時禁止其他事務執行的調度策略一定是可串行化的調度,這是最簡單的調度策略,但實際上是不可行的,因爲它使用戶不能充分共享數據庫資源。目前DBMS普遍採用封鎖方法來保證事務正確性;即保證並行操作調度的可串行性。除此之外還有其他一些方法,如時標方法、樂觀方法等。

悲觀併發控制: 鎖定系統阻止用戶以影響其它用戶的方式修改數據。如果用戶執行的操作導致應用了某個鎖,則直到這個鎖的所有者釋放該鎖,其它用戶才能執行與該鎖衝突的操作。該方法主要用在數據爭奪激烈的環境中,以及出現併發衝突時用鎖保護數據的成本比回滾事務的成本低的環境中,因此稱該方法爲悲觀併發控制。

樂觀併發控制: 在樂觀併發控制中,用戶讀數據時不鎖定數據。在執行更新時,系統進行檢查,查看另一個用戶讀過數據後是否更改了數據。如果另一個用戶更新了數據,將產生一個錯誤。一般情況下,接收錯誤信息的用戶將回滾事務並重新開始。該方法主要用在數據爭奪少的環境內,以及偶爾回滾事務的成本超過讀數據時鎖定數據的成本的環境內,因此稱該方法爲樂觀併發控制。

時標併發控制: 時標和封鎖技術之間的基本區別是封鎖是使一組事務的併發執行(即交叉執行)同步,使用它等價於這些事務的某一串行操作;時標法也是使用一組事務的交叉執行同步,但是使它等價於這些事務的一個特定的串行執行,即由時標的時序所確定的一個執行。如果發生衝突,是通過撤銷並重新啓動一個事務解決的。事務重新啓動,則賦予新的時標。

單純加鎖協議解決併發控制問題會有讀寫衝突和寫寫衝突,對併發事務性能影響較大。因此實踐中postgresql,mysql innodb,oracle,sql server(可設置,默認關閉),informix等數據庫還使用了多版本併發控制(MVCC),MVCC可以避免讀寫衝突,這樣使用鎖搞定寫寫衝突的相關事務串行化操作就可以了。

後續節繼續具體數據庫的鎖機制和實現MVCC的情況。




-----------------

轉載請著明出處:
blog.csdn.net/beiigang



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章