這篇文章將介紹什么是分布式事務(wù)，分布式事務(wù)解決什么問題，對分布式事務(wù)實(shí)現(xiàn)的難點(diǎn)，解決思路，不同場景下方案的選擇，通過圖解的方式進(jìn)行梳理、總結(jié)和比較。

相信耐心看完這篇文章，談到分布式事務(wù)，不再只是有“2PC”、“3PC”、“MQ的消息事務(wù)”、“最終一致性”、“TCC”等這些知識碎片，而是能夠?qū)⒅R連成一片，形成知識體系。

1 什么是事務(wù)

介紹分布式事務(wù)之前，先介紹什么是事務(wù)。

事務(wù)的具體定義

事務(wù)提供一種機(jī)制將一個(gè)活動涉及的所有操作納入到一個(gè)不可分割的執(zhí)行單元，組成事務(wù)的所有操作只有在所有操作均能正常執(zhí)行的情況下方能提交，只要其中任一操作執(zhí)行失敗，都將導(dǎo)致整個(gè)事務(wù)的回滾。

簡單地說，事務(wù)提供一種“ 要么什么都不做，要么做全套（All or Nothing）”機(jī)制。

數(shù)據(jù)庫事務(wù)的ACID屬性

事務(wù)是基于數(shù)據(jù)進(jìn)行操作，需要保證事務(wù)的數(shù)據(jù)通常存儲在數(shù)據(jù)庫中，所以介紹到事務(wù)，就不得不介紹數(shù)據(jù)庫事務(wù)的ACID特性，指數(shù)據(jù)庫事務(wù)正確執(zhí)行的四個(gè)基本特性的縮寫。包含：

原子性（Atomicity） 整個(gè)事務(wù)中的所有操作，要么全部完成，要么全部不完成，不可能停滯在中間某個(gè)環(huán)節(jié)。事務(wù)在執(zhí)行過程中發(fā)生錯(cuò)誤，會被回滾（Rollback）到事務(wù)開始前的狀態(tài)，就像這個(gè)事務(wù)從來沒有執(zhí)行過一樣。例如：銀行轉(zhuǎn)賬，從A賬戶轉(zhuǎn)100元至B賬戶，分為兩個(gè)步驟：
（1）從A賬戶取100元
（2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了100元。
一致性（Consistency） 在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫數(shù)據(jù)的一致性約束沒有被破壞。例如：現(xiàn)有完整性約束A+B=100，如果一個(gè)事務(wù)改變了A，那么必須得改變B，使得事務(wù)結(jié)束后依然滿足A+B=100，否則事務(wù)失敗。
隔離性（Isolation） 數(shù)據(jù)庫允許多個(gè)并發(fā)事務(wù)同時(shí)對數(shù)據(jù)進(jìn)行讀寫和修改的能力，如果一個(gè)事務(wù)要訪問的數(shù)據(jù)正在被另外一個(gè)事務(wù)修改，只要另外一個(gè)事務(wù)未提交，它所訪問的數(shù)據(jù)就不受未提交事務(wù)的影響。隔離性可以防止多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。例如：現(xiàn)有有個(gè)交易是從A賬戶轉(zhuǎn)100元至B賬戶，在這個(gè)交易事務(wù)還未完成的情況下，如果此時(shí)B查詢自己的賬戶，是看不到新增加的100元的。
持久性（Durability） 事務(wù)處理結(jié)束后，對數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會丟失。

本地事務(wù)ACID大家應(yīng)該都知道了，統(tǒng)一提交，失敗回滾，嚴(yán)格保證了同一事務(wù)內(nèi)數(shù)據(jù)的一致性！而分布式事務(wù)不能實(shí)現(xiàn)這種ACID，它只能實(shí)現(xiàn)CAP原則里的某兩個(gè)，CAP也是分布式事務(wù)的一個(gè)廣泛被應(yīng)用的原型，CAP(Consistency, Availability, Partition Tolerance), 闡述了一個(gè)分布式系統(tǒng)的三個(gè)主要方面, 只能同時(shí)擇其二進(jìn)行實(shí)現(xiàn). 常見的有CP系統(tǒng), AP系統(tǒng)。

應(yīng)用于CP和AP的原則在業(yè)界出現(xiàn)了一些框架：

CP系統(tǒng)就有二階段提交(強(qiáng)一致性)

AP系統(tǒng)就有TCC(補(bǔ)償型事務(wù))

其中最近接觸的aspnetcore.cap就是一個(gè)滿足最終一致性的異步消息方案實(shí)現(xiàn)的，其中它為MySQL,sqlserver都提供了解決方案，消息隊(duì)列可以有kafka和rabbitmq兩種選擇，根據(jù)自己的需要去安裝，源代碼在github上有開源，nuget上也有對應(yīng)的包包！

方案簡介

本地消息表的方案最初是由ebay提出，核心思路是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理。

方案通過在事務(wù)主動發(fā)起方額外新建事務(wù)消息表，事務(wù)發(fā)起方處理業(yè)務(wù)和記錄事務(wù)消息在本地事務(wù)中完成，輪詢事務(wù)消息表的數(shù)據(jù)發(fā)送事務(wù)消息，事務(wù)被動方基于消息中間件消費(fèi)事務(wù)消息表中的事務(wù)。

這樣設(shè)計(jì)可以避免”業(yè)務(wù)處理成功 + 事務(wù)消息發(fā)送失敗"，或"業(yè)務(wù)處理失敗 + 事務(wù)消息發(fā)送成功"的棘手情況出現(xiàn)，保證2個(gè)系統(tǒng)事務(wù)的數(shù)據(jù)一致性。

處理流程

下面把分布式事務(wù)最先開始處理的事務(wù)方成為事務(wù)主動方，在事務(wù)主動方之后處理的業(yè)務(wù)內(nèi)的其他事務(wù)成為事務(wù)被動方。

為了方便理解，下面繼續(xù)以電商下單為例進(jìn)行方案解析，這里把整個(gè)過程簡單分為扣減庫存，訂單創(chuàng)建2個(gè)步驟，庫存服務(wù)和訂單服務(wù)分別在不同的服務(wù)器節(jié)點(diǎn)上，其中庫存服務(wù)是事務(wù)主動方，訂單服務(wù)是事務(wù)被動方。

事務(wù)的主動方需要額外新建事務(wù)消息表，用于記錄分布式事務(wù)的消息的發(fā)生、處理狀態(tài)。

整個(gè)業(yè)務(wù)處理流程如下：

步驟1 事務(wù)主動方處理本地事務(wù)。 事務(wù)主動發(fā)在本地事務(wù)中處理業(yè)務(wù)更新操作和寫消息表操作。上面例子中庫存服務(wù)階段再本地事務(wù)中完成扣減庫存和寫消息表(圖中1、2)。

步驟2 事務(wù)主動方通過消息中間件，通知事務(wù)被動方處理事務(wù)通知事務(wù)待消息。消息中間件可以基于Kafka、RocketMQ消息隊(duì)列，事務(wù)主動方法主動寫消息到消息隊(duì)列，事務(wù)消費(fèi)方消費(fèi)并處理消息隊(duì)列中的消息。上面例子中，庫存服務(wù)把事務(wù)待處理消息寫到消息中間件，訂單服務(wù)消費(fèi)消息中間件的消息，完成新增訂單（圖中3 - 5）。

步驟3 事務(wù)被動方通過消息中間件，通知事務(wù)主動方事務(wù)已處理的消息。 上面例子中，訂單服務(wù)把事務(wù)已處理消息寫到消息中間件，庫存服務(wù)消費(fèi)中間件的消息，并將事務(wù)消息的狀態(tài)更新為已完成(圖中6 - 8)

為了數(shù)據(jù)的一致性，當(dāng)處理錯(cuò)誤需要重試，事務(wù)發(fā)送方和事務(wù)接收方相關(guān)業(yè)務(wù)處理需要支持冪等。具體保存一致性的容錯(cuò)處理如下：

1、當(dāng)步驟1處理出錯(cuò)，事務(wù)回滾，相當(dāng)于什么都沒發(fā)生。
2、當(dāng)步驟2、步驟3處理出錯(cuò)，由于未處理的事務(wù)消息還是保存在事務(wù)發(fā)送方，事務(wù)發(fā)送方可以定時(shí)輪詢?yōu)槌瑫r(shí)消息數(shù)據(jù)，再次發(fā)送的消息中間件進(jìn)行處理。事務(wù)被動方消費(fèi)事務(wù)消息重試處理。
3、如果是業(yè)務(wù)上的失敗，事務(wù)被動方可以發(fā)消息給事務(wù)主動方進(jìn)行回滾。
4、如果多個(gè)事務(wù)被動方已經(jīng)消費(fèi)消息，事務(wù)主動方需要回滾事務(wù)時(shí)需要通知事務(wù)被動方回滾。

方案總結(jié)

方案的優(yōu)點(diǎn)如下：

從應(yīng)用設(shè)計(jì)開發(fā)的角度實(shí)現(xiàn)了消息數(shù)據(jù)的可靠性，消息數(shù)據(jù)的可靠性不依賴于消息中間件，弱化了對MQ中間件特性的依賴。
方案輕量，容易實(shí)現(xiàn)。

缺點(diǎn)如下：

與具體的業(yè)務(wù)場景綁定，耦合性強(qiáng)，不可公用。
消息數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)同庫，占用業(yè)務(wù)系統(tǒng)資源。
業(yè)務(wù)系統(tǒng)在使用關(guān)系型數(shù)據(jù)庫的情況下，消息服務(wù)性能會受到關(guān)系型數(shù)據(jù)庫并發(fā)性能的局限。

對消息確保型－最終一致性的分布式事務(wù)的理解：