首頁 > 資料庫 > mysql教程 > 事務和並發控制:DBMS

事務和並發控制:DBMS

Linda Hamilton
發布: 2025-01-05 16:07:44
原創
650 人瀏覽過

Transactions and Concurrency Controls: DBMS

資料庫管理系統 (DBMS) 中的事務

定義:

資料庫管理系統 (DBMS) 中的事務是作為單一邏輯工作單元執行的一系列操作。事務可以涉及讀取、插入、更新或刪除資料庫中的資料。事務的關鍵特徵是它是原子的,這意味著事務中的所有操作都成功完成,或者根本沒有任何操作應用於資料庫。


事務的關鍵屬性:ACID 屬性

事務必須遵守ACID屬性以確保資料庫的一致性和可靠性。這些屬性是:

  1. 原子性

    • 原子性確保事務被視為單一、不可分割的工作單元。要么執行事務中的所有操作,要么不執行。如果交易的任何部分失敗,整個事務將回滾,確保資料庫保持一致的狀態。
    • 範例:如果一筆交易涉及從帳戶A 向帳戶B 轉賬,原子性可確保整個轉賬完成(從A 扣除資金並添加到B)或不執行任何操作(不轉賬)如果失敗) 。
  2. 一致性

    • 一致性確保交易將資料庫從一種有效狀態轉移到另一種有效狀態。任何事務都不應該違反資料庫的完整性約束(例如主鍵、外鍵等)。事務提交後,資料庫應該始終處於一致狀態。
    • 範例:在兩個銀行帳戶之間轉帳後,兩個帳戶中的餘額總和應保持不變。如果違反資料庫一致性規則,交易將會回滾。
  3. 隔離

    • 隔離性確保事務的操作在執行時對其他事務隱藏。即使多個事務同時發生,每個事務也應該不知道其他事務的操作。這可以防止髒讀、不可重複讀和幻讀。
    • 範例:如果兩個使用者同時從同一個銀行帳戶轉賬,隔離可確保一筆交易不會幹擾另一筆交易,從而防止重複提款等錯誤。
  4. 耐用性

    • 持久性保證一旦事務提交,其更改就是永久性的,即使在系統崩潰的情況下也是如此。成功提交後,事務所所做的更改將保存到資料庫中,並且不會遺失。
    • 範例:如果使用者成功下訂單,資料庫中的變更(例如庫存更新和下訂單)應該持續存在,即使提交後突然斷電也是如此。

交易類型

  1. 簡單交易

    • 這些涉及單一操作,例如讀取或寫入資料。例如,簡單的讀取查詢或更新查詢可以是事務的一部分。
  2. 複雜交易

    • 這些涉及多種操作,包括讀取、更新、插入和刪除。複雜的交易可以是旨在完成業務流程的一系列操作,例如將資金從一個帳戶轉移到另一個帳戶,其中涉及檢查帳戶餘額、從一個帳戶中扣除以及向另一個帳戶中添加。

交易生命週期

典型的交易遵循以下步驟:

  1. 開始交易

    • 這標誌著交易的開始。表示即將執行新的交易。
  2. 執行操作

    • 交易執行一系列資料庫操作,例如選擇、插入、更新或刪除記錄。這些操作作為事務的一部分按順序執行。
  3. 提交交易

    • 所有操作完成後,交易提交。這意味著事務所所做的所有更改都將永久保存到資料庫中。一旦提交,事務就無法回滾。
  4. 回滾事務

    • 如果在事務執行過程中出現錯誤或失敗(例如違反約束),事務將被回滾。這意味著事務所所做的所有更改都將被撤消,並且資料庫將返回其原始狀態。
  5. 結束交易

    • 提交或回滾後,事務結束。這意味著交易的生命週期已經完成。

交易狀態

交易在其生命週期內必須處於以下狀態之一:

  1. 活躍

    • 交易的初始狀態。事務在執行和執行操作時保持此狀態。
  2. 部分承諾

    • 此狀態發生在交易的最終語句執行之後。至此,交易已完成所有操作,但尚未提交到資料庫。
  3. 失敗

    • 當發現交易無法正常執行時,它會進入失敗狀態,通常是由於約束衝突或系統故障等問題。
  4. 已中止

    • 交易回滾且資料庫恢復到交易開始之前的狀態後,進入中止狀態。
  5. 承諾

    • 交易在所有操作成功完成後進入已提交狀態,且其變更已永久套用至資料庫。
  6. 終止

    • 如果交易已提交或中止,則該事務被視為已終止。一旦交易達到已提交或已中止狀態,就無法重新啟動。

DBMS 中的時間表

schedule 是按特定順序執行的多個交易的操作序列。調度決定了多個事務的讀寫操作的執行順序。主要目標是確定並發交易如何互動並確保資料庫保持一致狀態。

時間表可以是連續非連續


時間表的類型

  1. 連續劇時間表
    • 串列計畫是一種交易一個接著一個執行而沒有任何交錯的計畫。這意味著一個事務的操作在下一個事務開始之前完全完成。
    • 在串列調度中,沒有並發性,調度相當於順序執行交易。

序列時間表範例

  • 交易1:T1:讀取(A);寫(A);犯罪
  • 交易2:T2:讀(B);寫(B);犯罪
  • 交易是依序執行的,操作上沒有重疊。
  1. 非連續劇時間表
    • 非串列調度允許多個交易的操作交錯。在這種類型的調度中,事務是並發執行的,這意味著它們的操作混合在一起。
    • 非串行調度可能會導致不同的結果,具體取決於操作執行的順序,這需要仔細管理以維護 ACID 屬性。

非連續劇時間表範例

  • T1:閱讀(A);寫(A);
  • T2:讀取(B);寫(B);
  • T1:提交;
  • T2:提交;
  • 事務T1和T2的操作是交錯的。

可串列化

可串列性是確保並發執行多個交易的結果與串列執行事務(一個接一個)的結果相同的概念。如果一個調度在對資料庫的影響方面等同於串列調度,則該調度稱為可序列化

重要性

可串行化的目標是確保並發交易不會導致衝突或異常(例如髒讀、丟失更新等)並且資料庫保持一致的狀態。

可序列化有兩種主要類型:

  1. 可串列化衝突
    • 如果一個調度可以透過交換非衝突運算轉換為串列調度,那麼它就是衝突可串列化的。如果兩個操作來自不同的事務,存取相同的資料項,並且其中至少一個是寫入操作,則認為它們是衝突的。
    • 衝突操作
      • 當一個事務讀取另一個事務寫入的資料項時,會發生讀寫衝突
      • 當兩個交易都寫入同一個資料項時,就會發生寫-寫衝突

可串列化衝突範例:

  • 時間表:
    • T1:寫入(A);
    • T2:寫入(B);
    • T1:讀取(B);
    • T2:閱讀(A);
  • 此調度可以重新排列為串列調度,並且可以衝突串列化。
  1. 查看可序列化性
    • 如果調度在最終結果方面等同於串行調度,即發生相同的讀取和寫入,並且事務被正確序列化,則該調度是視圖可串行化的。然而,在視圖可序列化性中,操作不一定必須像衝突可序列化性中那樣交換。

衝突等價、衝突可序列化

  • 等效衝突

    • 如果兩個調度包含相同的操作,操作的順序相同,並且保留衝突操作的順序,則稱它們是衝突等效。這意味著兩個計劃中的事務交錯會產生相同的結果,確保它們是衝突等價的。
  • 可序列化衝突

    • 如果一個調度表的事務可以重新排列以形成一個串列調度表,從而保持衝突順序,那麼該調度表就是衝突可序列化的。簡單來說,如果交易可以在不違反資料一致性的情況下序列化,即保持衝突操作的順序,則調度是衝突可序列化的。

衝突可串行性和衝突等效計劃範例

讓我們考慮以下交易及其操作:

  • 交易T1:讀取(A);寫(A);犯罪
  • 交易T2:讀取(A);寫(A);犯罪

時間表1

T1: Read(A);
T2: Read(A);
T1: Write(A);
T2: Write(A);
T1: Commit;
T2: Commit;
登入後複製

時間表2

T2: Read(A);
T1: Read(A);
T2: Write(A);
T1: Write(A);
T1: Commit;
T2: Commit;
登入後複製

衝突可串列性檢查

  • 時間表 1時間表 2衝突等效,因為衝突操作(在 A 上讀/寫)的順序保持不變。兩個調度都可以轉換為串列調度:
    • T1:閱讀(A);寫(A);承諾;
    • T2:閱讀(A);寫(A);承諾;
  • 因此,兩個調度都是可序列化衝突

事務隔離性和原子性

除了事務的基本屬性(例如 ACID 屬性)之外,管理事務失敗是維護資料庫一致性和可靠性的一個重要面向。當交易並發執行時,資料庫必須確保交易期間的任何失敗都不會破壞資料庫狀態,並保持資料庫的原子性和一致性。本節討論故障處理如何影響 DBMS 中的事務隔離和原子性。


原子性和故障處理

原子性 是交易的屬性,可確保將其視為單一不可分割的工作單元。這意味著事務要么完全完成,要么根本不執行。如果事務的任何部分失敗,則必須回滾整個事務,以確保不會將部分變更套用至資料庫。

當交易失敗時,它對資料庫可能產生的任何影響都必須撤消,以便資料庫可以回到交易開始之前的狀態。在允許並發執行事務的系統中,如果事務 T1 失敗,則所有依賴 T1 的事務(即,讀取或寫入受 T1 影響的資料的任何事務 T2)也必須中止,以保留資料庫的原子性。如果一個事務依賴另一個失敗的事務,它不應該留下部分更改或不一致的資料。

為了防止事務執行期間出現不一致,管理規定事務操作順序的時間表至關重要,尤其是當事務失敗時。需要限制某些類型的計劃,以確保能夠正確管理故障。


可恢復的時間表

可恢復調度 是一種事務 T2 僅在其依賴的事務 T1 提交後才提交的調度。簡單來說,如果事務 T2 讀取事務 T1 寫入的數據,則 T1 必須在 T2 之前提交。這確保 T2 不會基於未提交的事務提交更改,從而防止回滾 T1 也需要回滾 T2 的情況。

違反此規則的計劃稱為不可恢復的計劃。例如,如果T2在讀取T1寫入的資料後提交,但T1失敗並回滾,則資料庫無法恢復到一致狀態,因為T2的提交依賴於T1未提交的變更。在這種情況下,T2 就無法撤銷,導致資料不一致。

不可回復的時間表範例
在不可恢復的時間表中,假設:

  • 事務 T6 將資料寫入項目 A。
  • 事務T7讀取T6寫入的A的值並立即提交。

如果 T6 在提交之前失敗,T7 依賴 T6 所做的未提交的更改。由於T7已經提交,我們無法回滾T7,從而導致無法從T6的故障中恢復的情況。這會導致不可恢復的時間表

為了使調度可恢復,T7 應該將其提交延遲到 T6 提交之後,確保 T7 不依賴 T6 中未提交的資料。


無級聯時間表

即使計劃是可恢復的,它仍然可能導致事務失敗恢復期間出現問題,特別是在發生級聯回滾時。 級聯回滾是指一個交易的失敗導致其他依賴事務回滾的連鎖反應。當事務讀取另一個未提交事務寫入的資料時,就會發生這種情況。

例如,考慮以下場景:

  • 事務 T8 將值寫入資料項 A,該值由事務 T9 讀取。
  • 事務 T9 將一個值寫入 A,然後由事務 T10 讀取該值。
  • 如果T8失敗,依賴T8的T9也需要回滾。 T10依賴T9,也必須回滾。這會產生級聯回滾效應,不必要地撤銷多個交易的工作。

級聯回滾是不可取的,因為它們會導致大量工作的撤銷,即使只有一個事務失敗。為了防止級聯回滾,我們可以使用級聯調度。無級聯調度是一種交易不讀取尚未提交的事務寫入的資料的調度。

形式上,級聯調度是這樣一種調度,對於任意兩個事務T1和T2,如果T2讀取T1寫入的資料項,則T1必須在T2讀取資料項之前提交。這確保沒有事務可以依賴未提交的數據,並且不會出現級聯回滾。

每個無級聯調度也是一個可恢復調度。這意味著無級聯調度不僅可以防止級聯回滾,還可以確保資料庫在交易失敗時能夠正確復原。

無級聯調度範例
考慮以下幾點:

  • 事務T8寫入A,T9讀取A。
  • 在級聯調度中,T9 只能在 T8 提交後讀取 A。

這保證了除非 T8 成功完成,否則 T9 不會從 T8 讀取數據,從而確保在 T8 失敗時不需要回滾 T9。


事務隔離等級

交易隔離確保並發交易不會以違反資料庫一致性的方式相互幹擾。事務的隔離等級定義了該交易與其他事務隔離的程度。

有不同的隔離等級,範圍從低到高隔離:

  1. 未提交的讀取

    • 此隔離等級允許交易讀取其他未提交交易寫入的資料。此等級可能會導致諸如髒讀之類的問題,其中事務讀取稍後可能回滾的數據,從而導致結果不一致。
  2. 已提交讀取

    • 該層級的交易只能讀取其他交易已提交的資料。雖然這可以防止髒讀,但它仍然可能導致不可重複讀取,其中一個事務讀取相同的資料兩次並獲得不同的結果,因為另一個事務同時修改了資料。
  3. 可重複閱讀

    • 此等級可防止髒讀和不可重複讀取。但是,它仍然允許幻讀,如果其他交易插入或刪除記錄,事務可能會遇到不同的行集。
  4. 可序列化

    • 這是最高的隔離等級。它確保並發事務的結果與事務一個接一個地串行執行的結果相同。這可以防止髒讀、不可重複讀和幻讀,但由於其嚴格的性質,可能會對效能產生影響。

為資料庫或交易選擇的隔離等級會影響資料一致性和效能之間的平衡,較高的隔離等級通常會因並發限制較大而導致效能變慢。


DBMS 中的並發控制

並發控制是資料庫管理系統(DBMS)的關鍵方面,它確保正確的事務執行,同時允許多個事務同時執行。並發控制的目標是在面對事務交錯和故障場景時保持資料庫的一致性和完整性。本節涵蓋基於鎖的協定,包括各種鎖定模式、兩階段鎖定協定死鎖處理機制和基於時間戳的協議.

基於鎖的協議

鎖定是 DBMS 中用來防止並發執行事務之間發生衝突的基本機制。鎖應用於資料項以控制訪問,確保多個事務不會違反資料庫的完整性。在基於鎖定的並發控制中,交易在對資料項目執行操作之前取得鎖,並在操作完成後釋放鎖定。

鎖的類型

有多種模式可以鎖定資料項。在本節中,我們將注意力限制在兩種基本模式:

  1. 共享鎖定(S)
    • 當交易只需要讀取資料項時,它會持有該資料項的共用鎖定。
    • 多個事務可以同時持有同一個資料項的共用鎖定。這允許不同事務並發讀取資料項。
    • 共享鎖定不允許交易修改資料項。

範例

  • 事務 T1 持有項目 A 的共享鎖定並讀取 A。
  • 事務 T2 持有項目 A 的共享鎖定並讀取 A。
  • 兩者都可以讀取數據,但不能寫入A。
  1. 獨佔鎖(X)
    • 當事務需要讀取和寫入資料項時,它會持有該資料項的排他鎖。
    • 任何時候只有一個事務可以持有特定資料項的排他鎖。如果一個交易擁有排它鎖,則其他交易無法取得相同資料項目的共用鎖或排它鎖。

範例

  • 事務 T1 持有項目 A 的獨佔鎖並對其進行寫入。
  • 當 T1 持有 A 上的獨佔鎖時,沒有其他事務可以讀取或寫入 A。

授予鎖

鎖是根據系統遵循的協定來授予的,不同的基於鎖的協定可以控制在事務執行期間如何請求和授予鎖。這些協定有助於避免衝突,例如更新遺失、臨時不一致以及其他事務存取未提交的資料。


兩階段鎖定協定 (2PL)

兩階段鎖定協議是一種廣泛使用的協議,以確保可序列化性 - 一種保證事務執行方式的屬性,其結果相當於在之後執行它們另一個(連續的)。兩階段鎖定透過在事務執行期間強制執行兩個階段來確保可串行化:

  1. 成長階段

    • 在此階段,事務可以取得鎖,但不能釋放任何鎖。
    • 交易可以請求任意數量的鎖,但是一旦釋放鎖,就無法取得任何新的鎖。當執行第一次解鎖操作時,此階段結束。
  2. 收縮階段:

    • 在此階段,交易可以釋放鎖,但無法取得任何新鎖。
    • 一旦交易開始釋放鎖,它就無法鎖定任何其他資料項目。當事務提交或中止時,此階段結束。

兩相鎖定協定保證可串列化,因為它可以防止鎖定圖中的循環,確保執行順序遵循嚴格的可序列化順序。

範例

  • 事務T1和T2需要更新資料項A和B。使用2PL,兩個事務都會在成長階段取得必要的鎖,並在完成操作後(收縮階段)釋放它們。

死鎖處理

死鎖 當兩個或多個事務正在等待對方釋放鎖,導致其中一個都無法繼續進行的情況時,就會發生。這會造成等待事務的循環,除非回滾一個或多個事務,否則無法解決該循環。

預防死鎖

死鎖預防技術旨在透過對事務行為進行限制來避免死鎖的發生。防止死鎖的常見策略是使用時間戳來決定交易的優先順序。

基於時間戳記的死鎖預防方案

有兩種使用時間戳記的著名死鎖預防方案

  1. 等待死亡計畫
    • 這是一種非搶佔式死鎖預防技術。
    • 如果交易 Ti 請求 Tj 持有的資料項,則僅當其時間戳小於 Tj 的時間戳(即 Ti 早於 Tj)時才允許 Ti 等待。
    • 如果 Ti 的時間戳大於 Tj,則 Ti 會回滾(即 Ti「死亡」)。

範例

  • 如果事務 T14、T15 和 T16 的時間戳記分別為 5、10 和 15:
    • 如果 T14 請求 T15 持有的資料項,T14 將等待,因為 T14 較舊。
    • 如果T16請求T15持有的資料項,T16將被回滾,因為T16比T15年輕。
  1. 傷口等待計畫
    • 這是一種搶佔式死鎖預防技術。
    • 如果交易 Ti 請求 Tj 持有的資料項,則僅當其時間戳大於 Tj 的時間戳(即 Ti 比 Tj 年輕)時才允許 Ti 等待。
    • 如果Ti的時間戳小於Tj的時間戳,Ti搶佔Tj,且Tj被回滾(即Tj被Ti「傷害」)。

範例

  • 如果事務 T14、T15 和 T16 的時間戳記分別為 5、10 和 15:
    • 如果T14請求T15持有的資料項,T14將搶佔T15,導致T15回溯。
    • 如果T16請求T15持有的資料項,T16將等待,因為它比T15年輕。

基於時間戳記的協議

除了基於鎖定的協定之外,基於時間戳的協定還管理資料庫中的並發性。這些協定使用時間戳來排序事務並解決衝突,確保系統的行為就像事務是串列執行的一樣。

時間戳及其作用

時間戳記是建立交易時分配給交易的數值。交易的時間戳決定了其優先順序-較低的時間戳記值表示較舊的交易,較高的值表示較新的交易。

  1. W 時間戳(Q):

    • 這表示已成功對資料項目 Q 執行寫入操作的任何交易的最大時間戳記。
    • 它有助於識別修改資料項的最後一筆交易。
  2. R-時間戳(Q):

    • 這表示已成功對資料項 Q 執行讀取操作的任何事務的最大時間戳記。
    • 它有助於識別讀取資料項的最後一個事務。

時間戳排序協議

時間戳排序協定透過根據時間戳對交易執行總排序來確保可序列化。協議要求:

  • 如果一個事務 Ti 寫入資料項 Q,而另一個事務 Tj 讀取或寫入 Q,則 Ti 的時間戳記必須小於 Tj。
  • 類似地,如果 Ti 讀取資料項 Q,Tj 寫入 Q,則 Ti 的時間戳記必須小於 Tj。

該協定根據事務的時間戳記而不是鎖來解決衝突。

範例

  • 時間戳為 10 的事務 T1 寫入資料項 A。
  • 時間戳記為 12 的事務 T2 讀取資料項 A。
  • 時間戳排序協定確保 T1 的寫入操作發生在 T2 的讀取操作之前,從而保持正確的事務順序。

以上是事務和並發控制:DBMS的詳細內容。更多資訊請關注PHP中文網其他相關文章!

來源:dev.to
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
作者最新文章
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板