|
提到事務(wù)兩個字，相信每一個開發(fā)人員都不陌生，從我們第一次開始接觸數(shù)據(jù)庫的時候，也就開始和事務(wù)打交道；而且是一直打交道，很可能要打一輩子交道。
為什么這么說呢，大家都知道，互聯(lián)網(wǎng)經(jīng)過這么幾年快速的發(fā)展，互聯(lián)網(wǎng)技術(shù)也更新迭代了很多個版本，從最初的單體架構(gòu)，到現(xiàn)在的分布式、微服務(wù)架構(gòu)。
系統(tǒng)同樣也越來越復(fù)雜了，也就意味著問題越來越多了，原來單體架構(gòu)時的一個小問題，放在了現(xiàn)在可能就是個大問題，需要系統(tǒng)的去解決，就不能像之前那樣，湊合過唄，畢竟夫妻和諧也是很重要的。
所以，單體階段可能只需要處理好數(shù)據(jù)庫的本地事務(wù)就可以了，但是到了分布式系統(tǒng)中，事務(wù)的事兒，也就變成了一件大事兒。
這篇文章，我們就來聊聊怎么來處理好這個大事兒，以及現(xiàn)在業(yè)內(nèi)常用的解決方案有哪些？
什么是事務(wù)？
為了讓大家更好的能理解分布式的那些兒，我們還是先來回顧一下基礎(chǔ)的知識，比如第一個概念，什么是事務(wù)？咱們先來看下官方的解釋。
事務(wù)就是用戶定義的一系列數(shù)據(jù)庫操作，這些操作可以視為一個完成的邏輯處理工作單元，要么全部執(zhí)行，要么全部不執(zhí)行，是不可分割的工作單元。
說人話就是，事務(wù)是指程序中一系列嚴(yán)密的邏輯操作，而且所有操作必須全部成功完成，否則在每個操作中所做的所有更改都會被撤銷。
可以通俗理解為，大家要一起去搶銀行，要么都活著回來，要都永遠(yuǎn)別回來了（牢里），就是一根繩上的螞蚱，不求同年同月同日生，但求同年同月同日死，聽上去還頗有些悲壯的感覺。
什么是分布式事務(wù)？
好了，事務(wù)我們知道怎么回事兒了，那什么是分布式事務(wù)呢？它有特殊在哪里呢？接下來我們就來一探究竟。
所謂分布式事務(wù)，就是指事務(wù)的資源分別位于不同的分布式系統(tǒng)的不同節(jié)點之上的事務(wù)；這個又是啥意思嘞？舉個栗子：
在早期單體架構(gòu)時，通常情況下都是單庫單表場景，但是現(xiàn)在不是到了分布式環(huán)境下了嘛，業(yè)務(wù)數(shù)據(jù)非常龐大，所以當(dāng)業(yè)務(wù)數(shù)據(jù)量達(dá)到單庫單表的極限時，就需要考慮分庫分表，將之前的單庫單表拆分成多庫多表；分庫分表之后，原來在單個數(shù)據(jù)庫上的事務(wù)操作，可能就變成跨多個數(shù)據(jù)庫的操作，此時就需要使用分布式事務(wù)。如果你還不明白，那就再舉個栗子：
我們的一個系統(tǒng)有 3個功能模塊：用戶模塊、商品模塊和訂單模塊，我們現(xiàn)在有一個操作需要按順序去調(diào)用完成這3個模塊中的接口，這個操作是一個整體，包含在一個事務(wù)中，要么同時成功要么同時失敗回滾。不成功便成仁，這個都沒有問題。
但是當(dāng)我們把這個系統(tǒng)拆分成分布式系統(tǒng)架構(gòu)的時候，事務(wù)就不是上面那么玩兒了，原來的用戶模塊、商品模塊和訂單模塊，都升級變成了用戶系統(tǒng)、商品系統(tǒng)和訂單系統(tǒng)，每個系統(tǒng)都是獨立部署，甚至擁有獨立的數(shù)據(jù)庫。
這么一來，分布式事務(wù)就復(fù)雜多了，怎么才能保證三個不同的系統(tǒng)，針對同一個操作能保持一致性，因為這個三個系統(tǒng)之間要么是RPC通訊，要么是HTTP通信，這就增加了事情的難度。不過，方法總比問題多，程序員是一幫聰明絕頂?shù)娜耍?/div>
分布式事務(wù)常見解決方案
分布式事務(wù)常見的解決方案，現(xiàn)在通用的基本就如下這三種：
· 兩階段提交（2PC, Two Phase Commit）
· 本地消息表（eBay模式）
· 補償模式TCC
接下來我們就分別來看下幾種解決方案的特點。
兩階段提交（2PC,Two Phase Commit）方案
我們先來看下兩階段提交，兩階段提交其實就是為了保證分布在不同節(jié)點上的分布式事務(wù)的一致性，我們需要引入一個協(xié)調(diào)者來管理所有的節(jié)點，負(fù)責(zé)各個本地資源的提交和回滾，并確保這些節(jié)點正確提交操作結(jié)果，若提交失敗則放棄事務(wù)。
它有兩個階段
· 第一階段：準(zhǔn)備階段（prepare） 協(xié)調(diào)者通知參與者準(zhǔn)備提交訂單，參與者開始投票。參與者完成準(zhǔn)備工作向協(xié)調(diào)者回應(yīng)Yes
· 第二階段：提交(commit)/回滾(rollback)階段 協(xié)調(diào)者根據(jù)參與者的投票結(jié)果發(fā)起最終的提交指令。如果有參與者沒有準(zhǔn)備好則發(fā)起回滾指令
本地消息表（eBay模式）
本地消息表，為什么又稱為eBay模式呢？那是因為eBay的架構(gòu)師Dan Pritchett，曾在一篇解釋BASE原理的論文《Base：AnAcid Alternative》中提到一個eBay分布式系統(tǒng)一致性問題的解決方案。
它的核心思想是將需要分布式處理的任務(wù)通過消息或者日志的方式來異步執(zhí)行，消息或日志可以存到本地文件、數(shù)據(jù)庫或消息隊列，再通過業(yè)務(wù)規(guī)則進(jìn)行失敗重試，它要求各服務(wù)的接口是冪等的。
本地消息表與業(yè)務(wù)數(shù)據(jù)表處于同一個數(shù)據(jù)庫中，這樣就能利用本地事務(wù)來保證在對這兩個表的操作滿足事務(wù)特性，并且使用了消息隊列來保證最終一致性。
· 在分布式事務(wù)操作的一方完成寫業(yè)務(wù)數(shù)據(jù)的操作之后向本地消息表發(fā)送一個消息，本地事務(wù)能保證這個消息一定會被寫入本地消息表中。
· 之后將本地消息表中的消息轉(zhuǎn)發(fā)到 Kafka 等消息隊列中，如果轉(zhuǎn)發(fā)成功則將消息從本地消息表中刪除，否則繼續(xù)重新轉(zhuǎn)發(fā)。
·在分布式事務(wù)操作的另一方從消息隊列中讀取一個消息，并執(zhí)行消息中的操作。
TCC補償事務(wù)
TCC補償事務(wù)，全稱Try-Confirm-Cancel，又叫做柔性事務(wù)。TCC補償事務(wù)方案可能是目前最火的一種柔性事務(wù)方案了。它的核心思想是：針對每個操作，都要注冊一個與其對應(yīng)的確認(rèn)和補償（撤銷）操作。
關(guān)于TCC（Try-Confirm-Cancel）的概念，最早是由PatHelland于2007年發(fā)表的一篇名為《Lifebeyond Distributed Transactions:an Apostate’s Opinion》的論文提出。
在該論文中，TCC還是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作為名稱的是Atomikos公司，其注冊了TCC商標(biāo)（外國人的版權(quán)意識真強）。
它也分三個階段:
· Try階段主要是對業(yè)務(wù)系統(tǒng)做檢測及資源預(yù)留。
· Confirm 階段主要是對業(yè)務(wù)系統(tǒng)做確認(rèn)提交，Try階段執(zhí)行成功并開始執(zhí)行 Confirm階段時，默認(rèn) Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。
· Cancel 階段主要是在業(yè)務(wù)執(zhí)行錯誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務(wù)取消，預(yù)留資源釋放。
好了，到這里基本就把分布式事務(wù)的事兒，翻了個底朝天，其實也就那么回事兒；理論都有了，剩下的就是我們自己在真實的業(yè)務(wù)場景中去實戰(zhàn)了！
 |
