2.4　分布式事務一致性

事務的一致性在分布式系統下會遇到新的數據異常，引發新的挑戰。但解決數據異常的思路，即并發訪問控制算法，沒有本質上的改變：基本上還是在沖突關系中確認是否存在環，如存在則表示不可串行化（更加深入的討論參見第4章和第5章）。

事務的一致性和在分布式系統下遇到的分布式一致性，二者需要很好地結合。

本節先簡略回顧單機事務的一致性問題，然后從如上兩個層面來討論分布式事務的一致性。

2.4.1　單機事務的一致性

數據庫需要保證事務的ACID特性，其中C代表的一致性是數據庫ACID特性要保障的數據間關系的目標；A和D是保障數據一致性的兩種機制；I是在確保數據一致性（關于數據一致性更為詳細的討論見參考文獻[21]）正確的基礎上，通過允許特定的數據異常發生來換取性能提升的一種機制。這些都屬于數據庫的事務一致性。

維基百科對ACID的定義如下（注意我們使用粗體+斜體的形式標出了關鍵詞）。

• Atomicity：Atomicity requires that each transaction “all or nothing”。if one part of the transaction fails, then the entire transaction fails, and the database state is left unchanged. An atomic system must guarantee atomicity in each and every situation, including power failures, errors, and crashes. To the outside world, a committed transaction appears (by its effects on the database) to be indivisible (“atomic”), and an aborted transaction does not happen.（原子性：原子性要求每個事務全部成功式失敗。如果事務中一部分失敗，那么整個事務失敗，數據庫狀態保持不變。原子系統必須保證每種情況下的原子性，包括電源故障、錯誤和崩潰。在外界看來，提交的事務（通過它對數據庫的影響）是不可分割的（原子的），中止事務不會發生。）
• Consistency：The consistency property ensures that any transaction will bring the database from one valid state to another. Any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This does not guarantee correctness of the transaction in all ways the application programmer might have wanted (that is the responsibility of application-level code) but merely that any programming errors cannot result in the violation of any defined rules.（一致性：一致性用于確保任何事務都能將數據庫從一個有效狀態進入另一個有效狀態。根據所有定義的規則，寫入數據庫的任何數據都必須是有效的，包括約束、級聯、觸發器及其任意組合。但這并不能保證事務以應用程序可能希望的所有方式被正確性處理（這是應用程序的責任），而是僅能確保任何編程錯誤都不能導致違反已定義的規則。）
• Isolation：The isolation property ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially, i.e., one after the other. Providing isolation is the main goal of concurrency control. Depending on the concurrency control method (i.e., if it uses strict - as opposed to relaxed - serializability), the effects of an incomplete transaction might not even be visible to another transaction.（隔離性：隔離性用于確保事務的并發執行會產生一個系統狀態，如果事務是串行執行的，即一個接一個地執行，則事務會獲得這個系統狀態。提供隔離性是并發控制的主要目標。根據并發控制方法，即使用嚴格的而不是弱的序列化，不完整事務的影響甚至可能導致對另一個事務都是不可見的。）
• Durability：The durability property ensures that once a transaction has been committed, it will remain so, even in the event of power loss, crashes, or errors. In a relational database, for instance, once a group of SQL statements execute, the results need to be stored permanently (even if the database crashes immediately thereafter). To defend against power loss, transactions (or their effects) must be recorded in a non-volatile memory.（持久性：持久性用于確保一旦事務被提交，即使在系統斷電、崩潰或錯誤的情況下，它也會保持這種狀態。例如，在關系數據庫中，一旦執行了一組SQL語句，結果就需要永久存儲，即使之后數據庫立即崩潰。為了防止斷電，事務或其影響必須記錄在非易失性存儲器中。）

對于原子性，上面的定義強調了兩種結果——all或nothing，即事務要么成功要么失敗。這兩種結果因兩種動作而產生，即Commit（提交）和Abort（中止）；兩種結果對應的是事務的兩種狀態，即COMMITTED和ABORTED。另外，定義中還強調了作為事務的一部分（一個邏輯工作單元中的一個操作），如果失敗則整個事務應該是nothing的，換句話說，事務應“一損俱損”但不是“一榮俱榮”。

一致性是一個令人困惑的話題。什么樣的情況才算是一致？一個人，言行一致？一組數據，數據與數據之間保持一致？還是如上面的定義所強調的——from one valid state to another（從一個有效狀態進入另一個有效狀態）？事務的操作使得“特定數據”的狀態發生變遷，但前后的結果對應的狀態一直是valid（有效）的。那么，什么才是有效的？把salary列的值由1改為2就是有效的嗎？答案是：數據在事務的操作下，一直符合all defined rules（所有定義的規則），而這樣的規則通常是約束、級聯、觸發器及其任意組合，即這些規則是數據的“邏輯語義”。比如，寫偏序異常，違反的就是特定數據間的約束。約束，屬于用戶語義限定的數據的一致性。對于一個數據庫來說，系統級一致性有另外一層含義，即要想使數據在數據庫系統中保持一致，則數據庫系統必須符合可串行（serializability）和可恢復（recoverability）這兩個特性。可串行性很重要，其在隔離性下定義，下面會詳細描述。可恢復性是指已經提交的事務未曾讀過被回滾的事務寫過的數據（注意不是指數據庫宕機重啟后所做的恢復操作，而是不會發生“臟讀”）。可恢復性也很重要，當事務回滾，被回滾的事務就不應當對數據的一致性造成影響，數據庫的一致性狀態是可恢復的。所以，可串行性保障了數據不被并發操作改壞，可恢復性則保障了事務被回滾后數據可回到之前的有效狀態[1]。

對于隔離性，上面的定義強調了concurrent execution（一次執行），這是指存在多個事務（多個會話中在但同一時間段內運行的不同事務）同時運行時，若它們運行的順序就好像是serially（串行）的，那么就意味著出現了“并發”看起來像是“串行”的情況，但這并不是說“并發”的這些個動作確實是“串行”的，而是說“并發”的這些個動作對數據操作之后，數據的最終狀態應該是有效的，而有效的數據看起來像是“串行”動作造成的。另外，隔離性定義的是可串行化，不要把隔離性與“隔離級別”及“隔離級別”中的“SERIALIZABLE”相混淆。“隔離級別”是為了提高并發度，從而弱化數據在并發讀寫下的“一致性”（如寫偏序），且允許出現參考文獻[21]的1.1節所述的數據一致性層級，在這個層級中，只有最高層的SERIALIZABLE才能做到隔離性。

對于持久性，上面的定義強調的是對于已提交（COMMITTED狀態）的數據，要能夠永久保存，這除了涉及物理存儲外，還需要防止處于已提交狀態的數據因數據庫引擎沒有來得及把數據保存到物理存儲上（如掉電）而丟失了。所以，從持久性的定義看，持久性對在原子性中提到的中止（ABORTED狀態）不關注。

上面我們討論了ACID特性，這幾個特性屬于事務的特性。事務的一致性，是數據處理的目標，事務的隔離性是事務處理為實現一致性而對并發事務提出的技術要求（要求并發事務之間互不影響，即是隔離開的）。

參考文獻[186]認為，事務的一致性就是在以事務為數據操作單位的基礎上，使得事務發生前、發生后的數據狀態是滿足一致性約束的。相關論述如下：一致性約束是顯式定義的，如果狀態實體的內容滿足所有的一致性約束，我們就說狀態是一致的。每個事務單獨執行時，都會從一個一致性狀態轉換為另一個新的一致性狀態，也就是說，事務會保持一致性。

2.4.2　分布式事務的一致性

分布式數據庫系統的事務處理機制，需要遵從單機的事務處理機制，解決單機事務處理遇到的多種數據異常，同時解決分布式系統下特有的數據異常（見參考文獻[21]的1.1節，其中描述了單機事務需要解決的數據異常）。1.1.2節簡略概述了這些數據異常，并給出分布式數據庫需要解決的分布式系統下特有的數據異常。這些數據異常對數據庫系統提出挑戰，只有解決了這些數據異常，才算實現了分布式事務的一致性。

分布式事務的一致性可以用單機系統下的一致性來表達：分布式事務的一致性是指確保任何事務都能將數據庫從一個有效狀態轉換到另一個有效狀態。

事務的一致性著眼于數據庫內部，從數據庫引擎的角度看，數據狀態的變遷滿足完整性（邏輯語義上的完整性，非只包括數據庫中可通過形式化定義的如CHECK約束般的完整性）約束。

對于1.1.2節描述的Serial-Concurrent-Phenomenon異常，其寫操作是一個分布式寫操作，寫操作沒有滿足原子性（全局提交完成才算完成，而不是局部節點提交完成即局部提交的數據可見），因此帶來了此異常。

對于1.1.2節描述的Cross-Phenomenon異常，局部事務依賴局部節點（單機節點）的事務處理機制來判別本地發生的局部事務與本地發生的全局事務中的一部分之間的關系。這是典型的一葉障目，不能判斷所有事務在邏輯全局上是否構成了環，因此可能違背了全部事務的可串行化原則。

對于1.1.2節描述的寫偏序、讀偏序、只讀事務數據異常，在單機系統和分布式系統下均存在，它們的共同之處在于，違反了數據上的應用語義邏輯，從廣義的角度看，這種邏輯也是一種完整性約束。

2.4.3　分布式一致性與分布式事務一致性的關系

數據庫系統一旦和分布式系統結合，那么在“一致性”這個概念上就易產生混淆。分布式系統會帶來“多節點之間對數據讀、寫的時序在邏輯上是否一致”的問題。這個問題會影響分布式數據庫的事務一致性（參見1.1.2節、2.4.1節），也會影響分布式系統的分布式一致性（參見1.1.3節、2.2節、2.3節）。

事務的一致性著眼于在數據系統內部，從數據庫引擎的角度保護并發操作不對數據的狀態變遷過程造成影響（保持隔離性，確保一致性）。分布式一致性著眼于分布式系統外部，從外部用戶的視角看，其可確保讀到的數據，符合用戶對并發操作發生的順序的認知。

而分布式事務型數據庫，結合了事務的一致性和分布式一致性，內部操作以事務為單位，并同時使得外部觀察符合外部一致性，因此分布式事務是二者有機的結合。結合之后的結果，以及最強的分布式事務隔離級別（嚴格可串行化和順序可串行化，本書定義的隔離級別），數據庫內部不會產生1.1.2節介紹的各種數據異常，但同時又能滿足線性一致性。如圖2-9所示，結合事務一致性后，PC讀取的x的值，依賴于PA的兩個寫操作是同一個事務還是不同的事務。

如果PA的兩個寫操作分別屬于兩個事務，那么即使PA、PB和PC是并發操作，結果也會滿足圖2-9所示情況。如果PA的兩個寫操作是同一個事務，那么表明PA和PC是并發操作，結果滿足圖2-9所示情況。如果采用封鎖并發訪問控制算法，則PC的讀操作只能被阻塞，讀取不到值，等PA的事務完成后讀到的x值為2；如果采用MVCC并發訪問控制算法，則PC的讀操作只能讀到舊版本的值，即讀到的x舊值0。

上述結果表明，操作以事務為單位，會對分布式系統的一致性的結果產生影響。

再如，式2-11所示是因果一致性的一個例子，如果按照圖2-10所示，情況不同，讀到的值也會不同。

如圖2-10a所示，P1和P2進程上分別發生了兩個事務，P2上的讀和寫操作為同一個事務，此時，P3讀到x的值為b之后，則可不能再讀到x的值為a，如果允許P3讀到x的a值則違反了因果一致性；P4如果先讀到x的值a，則P4的讀操作一定是發生在P2事務開始之前。

如圖2-10b所示，P1和P2進程上分別發生了兩個事務，P3和P4不能精確判別P1和P2進程上發生的兩個事務之間的先后關系，因此P3和P4讀取數據不可能不同。如果x數據項只有一個副本，則在這個副本上，修改操作的次序總是能確定的，此時不會產生P3和P4以不同順序讀取到x值的情況，但如果x數據項有多個副本，且副本之間不同步，則可能會產生P3和P4以不同順序讀到x值的情況。

---

[1]實現數據庫時需要保證：對于并發的事務T1和T2，如果T2讀取了由T1所寫的數據項，則T1應先于T2提交。如果不這樣，當T2先提交，但T1被回滾后，則事務T2不可能再被恢復。