分布式事務的總結與思考

思來想去，個人覺得要理解 「分布式事務」 ，必須先知道什么是“事務（Transaction）”。

當然，這里提到的“事務”是在事務型數據庫（Transactional Database）知識領域內的。

一個事務包含了若干個數據庫操作，這些操作通常都會對數據庫產生變化。值得一提的是，多個事務之間是互不影響，獨立運行的，事務里的各個操作最終都得以持久化。

事務一個很重要的特性是： "all-or-nothing" 。

通俗來講，事務是對數據的一個邏輯操作，事務內的各個單元操作要么完整執行成功，要么全部都不執行。

因此，數據庫的事務機制為一系列的數據庫操作提供了相對獨立（隔離）的運行環境，保證了 數據的一致性 ，并且使得數據庫能被正確的恢復過來。

0、事務的特性

這一小節講的是數據庫事務四個經典的特性： 「ACID」 。

讀者如果熟悉，可以選擇性略過。

「ACID」是四個單詞的首字母縮寫，首次被提出來是在1983年。

與其說這是事務的四大特性，倒不如認為是一種設計思想，這種思想在以后影響了數據庫系統開發的方方面面。

Atomicity - 原子性

這個特性在上文中也有提到過，即 "all or nothing"：一個事務中的所有操作都順利完成了，才可以認為這個事務是成功的，否則，但凡有一個操作失敗了，就意味著整個事務的失敗，數據庫的相關數據狀態也就不會被改變。

值得一提的是，操作失敗不僅僅是業務或者編碼層面，也包括一些外部因素，比如斷點，磁盤故障等。

Consistency - 一致性

講到事務的一致性，通常指的是數據庫相關的約束條件，包括數據庫自帶的約束以及用戶自定義的約束，比如數據的唯一性（unique），數據的級聯相關性（cascade），觸發器（trigger）等。

這一系列的約束旨在保證事務能將數據庫從一個合理的狀態轉移到另一個合理的狀態，而所寫入的數據也都是遵從上述定義的約束條件。

當然，這里所提到的一致性，沒法從更高的應用層面（通常是業務層）保證數據一致性，僅僅是從程序上規避編碼錯誤導致對約束條件的破壞。比如插入了一個已經存在的主鍵值，或者沒給一個NOT NULL字段賦上一個合理的值……

Durability - 持久性

這個特性比較好理解，一個事務一旦被成功提交，那么所操作的數據將被永久存放在磁盤里了。持久化到磁盤，也是為了防止斷電導致數據丟失，直接放內存中，顯然不是明智的選擇。

Isolation - 隔離性

這個特性是最晚被提出來的，Jim Gray最早只提出上述的三個特性，后來Andreas Reuter和 Theo H?rder在此基礎上，增加了隔離性。

隔離性的提出，是為了解決事務并發的問題，是指并發的兩個事務的執行互不干擾，一個事務不能看到其他事務運行過程的中間狀態。

從隔離性的使用場景能感受到，提出此特性也是有時代背景的，也是人們為了解決并發控制問題而提出的對策。

1、何為「分布式事務」

在事務的基礎上，加上了「分布式」，這意味著要在分布式的環境下滿足事務的ACID特性。而分布式意味著網絡可能是異構的，操作系統也不盡相同，數據庫系統也不只在一臺主機上了。

實際上，隨著數據規模的急劇增長，單體數據庫無法承載如此海量的數據，需要對原有數據進行合理的分庫分表，此外，對于近來盛行的「微服務」架構，每個服務獨立部署，有獨立的數據庫，也不得不面臨分布式事務的問題。

總之，隨著分布式架構的大規模運用，分布式事務是不可回避的問題。

如果我們將「分布式事務」認為是一種事務，那么又該如何設計，使其滿足ACID四大特性呢？

2、兩段式提交

最經典的分布式事務解決方法就是“兩段式提交(two-phase commit)”。

在兩段式提交過程中，涉及兩類角色， 協調者(Coordinator) 和 參與者(Participants) 。

顧名思義，“兩段式提交”將事務的提交過程分為了兩個階段：

• 第一個階段：預提交階段，也可以稱之為投票階段。在這個階段，協調者詢問所有的參與者是否已準備好提交事務，參與者通常都會給出一個“YES or NO”的回答，即我們認為的投票過程。根據事務的Atomic特性，但凡有一個參與者Say NO，那么協調者就認為這個事務提交是失敗的。只有全部參與者給出“YES”的回答，才能讓事務順利提交。

• 第二個階段：提交決定階段。協調者根據上一個階段的投票結果決定是Commit還是Abort，這個決定是全局性的，會通知到所有的參與者執行最終的決定，并回傳一個ack確認信息。

值得注意的是，在進入兩段式提交過程期間，所有的參與者不能臨時改變主意，即投票不可反悔，下面是兩段式提交過程的示意圖：

two-phase commit protocol

仔細想想，兩段提交協議也并不完美。

兩段式提交時一個典型的 中心化架構 協議，被指定為協調者的節點如果沒有做高可用措施的話，協調者的宕機意味著事務再也無法正常提交了。與此同時，各個節點（包括協調者和參與者）只有在永無故障的前提下（雖然絕大多數的時候是OK的），才能使得事務順利提交。

這些假設條件無疑是嚴苛的，因為要達到 強一致性 的目的。

不過，這也使得兩段式提交協議在某些時候是比較脆弱的。兩段式提交協議的性能比較差， 消息交互多，且受最慢節點影響。

基于兩段式提交的分布式事務在提交事務時需要在多個節點之間進行協調，最大限度地推后了提交事務的時間點。

客觀上延長了事務的執行時間，同時也會

提高事務在訪問共享資源時發生沖突和死鎖的幾率

。隨著數據庫節點的增多，這種趨勢會越來越嚴重，從而成為系統在數據庫層面上水平伸縮的"枷鎖"。 這是很多Sharding系統不采用分布式事務的主要原因。

就好比你在旅游網站上訂了一個行程，除了生成一個出行訂單外，還需要去航空公司為你預訂相應的機票，還要去酒店為你預訂每天的房間。如果根據兩段式提交協議，只有當訂單、機票和房間都準備好了，這個行程才算預訂好了，這在顯然是不合理的。對于這種長生命周期的分布式事務就不適合兩段式提交。

3、三段式提交

顯然，三段式提交協議是基于兩段式提交而生的，為了解決兩段式提交帶來的阻塞等待問題，三段式提交引入TIMEOUT機制，可在超時后自動釋放資源。

和兩段式提交一樣，三段式提交協議有兩類角色， 協調者(Coordinator) 和 參與者(Participants) ，由三個階段構成。

• 第一個階段：詢問階段。協調者詢問每個參與者是否可以進行提交，這時候會出現多種情況。參與者明確自己是否能提交，可以給出“YES or NO”的準確回答，也有可能因為各種因素，導致不能確定，直到此次詢問超時，返回“NO”。

• 第二個階段：預提交階段。根據上階段得到的應答，協調者決定事務Commit or Abort，將投票最終結果發送給各個參與者，參與者收到此決定后再繼續下面的操作，只不過到了此階段，雙方都有超時機制了。協調者也有可能因為各種原因不能及時做出決定，超時后就自動給出了Abort決定，與此同時，參與者收到了協調者的決定，需要回傳ACK信息以確定，如果沒有在規定的時間窗口內確認，協調者認為事務應該Abort。

• 第三個階段：正式提交階段。在上一個階段，各個參與者已經收到了事務Commit or Abort的確認信息，其實這個階段可以認為是一個二次確認階段，協調者會發送一個DoCommit指令，參與者才真正開始進行事務的操作，并給協調者回復一個ACK。如果此時協調者接收ACK超時，協調者也會Abort整個事務。值得注意的是，如果協調者本身發送DoCommit就超時了，參與者也不會直接Abort事務，而是按照第二個階段的結果執行。

下面附上兩段式提交與三段式提交的框架圖：

4、TCC

TCC包含了三個階段： T ry， C onfirm， C ancel，因此而得名「TCC」。

TCC的概念屬于國產，因為支付寶的技術布道而廣為人知。

其實，TCC算是一種編程模型，通常被理解為是一種柔性事務解決方案。

• Try ，嘗試執行業務。完成所有業務檢查，預留相應的業務資源。

• Confirm ，如果Try階段執行成功，則此階段利用Try階段預留的資源，不再進行業務檢查，而是執行真正的業務提交。并且Confirm階段的操作滿足冪等性，以便支持重試。這個階段有一個假設：只要Try階段成功，那么Confirm階段一定成功。

• Cancel ，此階段是發生在Try階段出現失敗的時候，回滾之前的操作，釋放Try階段預留的業務資源，同樣也滿足冪等性。

借用一個例子：

用戶下完訂單后，使用紅包帳戶和資金帳戶來付款，紅包帳戶服務和資金帳戶服務在不同的系統中。一個是CapitalTradeOrderService，代表著資金帳戶服務,另一個是RedPacketTradeOrderService，代表著紅包帳戶服務。

下完訂單后，訂單狀態為DRAFT，在TRY階段，訂單支付服務將訂單狀態變成PAYING，同時遠程調用紅包帳戶服務和資金帳戶服務，將付款方的余額減掉（預留業務資源)；

如果在Try階段，任何一個服務失敗，將會調用這些服務對應的cancel方法，訂單支付服務將訂單狀態變成PAY_FAILED，同時遠程調用紅包帳戶服務和資金帳戶服務，將付款方余額減掉的部分增加回去；

如果Try階段正常完成，則進入Confirm階段，在Confirm階段，訂單支付服務將訂單狀態變成CONFIRMED，同時遠程調用紅包帳戶服務和資金帳戶服務對應的Confirm方法，將收款方的余額增加。

總結

本文對事務進行了簡單介紹，重點分析了事務的ACID四大特性，接著介紹分布式事務的解決方案。

希望對你有所幫助！

THANKS！

 

來自：http://mp.weixin.qq.com/s/UKNK9UzdiZzrNCd5U_4Ytg