在項目開發(fā)中，經(jīng)常會需要處理分布式事務(wù)。例如數(shù)據(jù)庫分庫分表之后，原來在一個單庫上的操作可能會跨越多個數(shù)據(jù)庫。系統(tǒng)服務(wù)化拆分之后，原來的在一個系統(tǒng)上的操作可能會跨越多個系統(tǒng)。就連我們平時經(jīng)常使用到的緩存(如redis、memcache等)也可能涉及分布式事務(wù)，因為緩存和數(shù)據(jù)庫是兩個不同的實體，如何保證數(shù)據(jù)在緩存和數(shù)據(jù)庫間的一致性也是要重點考慮的。分布式事務(wù)就是指事務(wù)要處理的資源分別位于分布式系統(tǒng)中的不同節(jié)點之上的事務(wù)。

對于單機(jī)系統(tǒng)，通常我們借助數(shù)據(jù)庫實現(xiàn)本地事務(wù)，例如下面JDBC代碼實現(xiàn)了一個事務(wù)：

Connection con = datasource.getConnection(); 
con.setAutoCommit(false); 
... 
執(zhí)行CRUD操作，可能會涉及到多個表 
... 
con.commit()/con.rollback() 

由于在分布式系統(tǒng)中，多個系統(tǒng)無法共用同一個數(shù)據(jù)庫鏈接，所以無法簡單借用上面的處理方式實現(xiàn)分布式事務(wù)。

下面將介紹幾種本人在實際開發(fā)中使用過的處理分布式事務(wù)的方式，最后再引出分布式事務(wù)的相關(guān)理論并進(jìn)行總結(jié)。

避免出現(xiàn)分布式事務(wù)

由于分布式事務(wù)比較難于處理，所以應(yīng)該盡量避免分布式事務(wù)的發(fā)生。例如對于一個客戶信息系統(tǒng)，由于注冊用戶數(shù)太多導(dǎo)致存儲的數(shù)據(jù)量過大，所以對其進(jìn)行分庫分表存儲。而客戶信息模型又分為多個子模型，對應(yīng)數(shù)據(jù)庫中的多個表，例如客戶基本信息表、客戶登錄賬號表、客戶登錄密碼表、客戶聯(lián)系方式表等等。假設(shè)登錄賬號表和客戶基本信息表的關(guān)聯(lián)關(guān)系如下所示：

user_id和login_id分別是兩個表的主鍵，user_id還作為login_info表的外鍵使兩個表關(guān)聯(lián)。在用戶注冊時會自動生成user_id和login_id的值。 user_info和login_info兩個表分別采用user_id和login_id計算分庫分表規(guī)則 。假設(shè)我們對每個模型分十庫一百表存儲，即存在user_info_00 ~ user_info_99一百個表，其中user_info_00 ~ user_info_09屬于第一個庫，user_info_10 ~ user_info_19屬于第二個庫，依次類推。

在分庫分表之后，如果我們不仔細(xì)的考慮user_id和login_id的生成規(guī)則(例如隨意生成一個數(shù)字字符串或簡單使用遞增sequence)，就可能導(dǎo)致同一個用戶的user_info信息和login_info信息被存儲到兩個不同的庫，這就會導(dǎo)致分布式事務(wù)發(fā)生。

面對這種問題，最好的解決思路就是考慮如何避免分布式事務(wù)的發(fā)生。只要想辦法讓跟一個用戶相關(guān)的所有模型數(shù)據(jù)全部存入到一個庫中，就可以避免分布式事務(wù)了。由于每個模型數(shù)據(jù)的分庫分表路由規(guī)則又是由各個表的主鍵id決定的(例如user_id、login_id)，所以只要對各個表的主鍵生成規(guī)則進(jìn)行定制，就可以保證一個用戶的所有模型數(shù)據(jù)全部存到同一個庫。假設(shè)有下面的id生成規(guī)則：

• 開始的兩位是標(biāo)識模型位，例如user_id以01開頭，login_id以02開頭。
• 接下來的11位是sequence遞增序列號，如果想要更多的ID可以擴(kuò)大這部分的位數(shù)，但對于存儲用戶信息而言，11位的長度足夠。
• 接下來是分庫分表位，如果每個模型的分庫分表算法都相同，那么只要保證每個模型的主鍵ID的分庫分表位都相同，就能保證一個用戶的所有模型數(shù)據(jù)都會存到同一個庫中。
• 最后一位是id校驗位，這一位根據(jù)前面15位的內(nèi)容生成，方便對一個id進(jìn)行校驗。

根據(jù)這個思想，我們可以在用戶注冊的時候先生成user_id，user_id的分庫分表位可以隨機(jī)生成。然后在為其它模型生成主鍵id時(例如login_id)，必須讓這個模型的主鍵id的分庫分表位與user_id的分庫分表位相同。另外一點也要注意，一個表的查詢條件不一定只有主鍵id一個，如果有其它查詢條件列，那就要保證那一列的生成規(guī)則也要包含相同的分庫分表位，否則就不能使用該列進(jìn)行查詢。

通過這種方式，就可以保證一個用戶的所有模型數(shù)據(jù)全部存儲到同一個庫中，有效的避免分布式事務(wù)的發(fā)生。

事務(wù)補(bǔ)償

通常情況下，應(yīng)對高并發(fā)的一個主要手段就是增加分布式緩存(如redis)以提高查詢性能。增加分布式緩存后系統(tǒng)查詢數(shù)據(jù)的流程如下圖：

即先嘗試從緩存中查詢數(shù)據(jù)，如果緩存命中就直接返回結(jié)果，否則嘗試從DB中查詢數(shù)據(jù)。如果查詢DB命中則將數(shù)據(jù)補(bǔ)充到緩存，以備下次查詢時可以命中緩存。

而在更新數(shù)據(jù)時，通常是先更新DB中的數(shù)據(jù)，DB寫入成功后再更新緩存中的數(shù)據(jù)。那么就有一個問題， 如何保證緩存和DB間數(shù)據(jù)的一致性？ 由于緩存和DB是兩個不同的實體，寫入DB成功后再去更新緩存，如果緩存更新失敗(例如網(wǎng)絡(luò)抖動造成短暫的緩存不可用)就會造成緩存和DB的不一致。此時按照上圖的查詢邏輯，先查緩存就會查詢到“臟”的數(shù)據(jù)，就會嚴(yán)重影響業(yè)務(wù)。這也是一個典型的分布式事務(wù)問題——緩存和DB要嘛同時更新成功，要嘛同時更新失敗。解決這個問題的一個較好方式就是事務(wù)補(bǔ)償。

我們可以在DB中創(chuàng)建一張事務(wù)補(bǔ)償表transaction_log，transaction_log表可以和業(yè)務(wù)數(shù)據(jù)在一個庫中，也可以在不同的庫。在更新數(shù)據(jù)前，先將要更新的模型數(shù)據(jù)記錄到transaction_log中。例如我們更新user_info表中的數(shù)據(jù)，就將userId記錄到transaction_log中。

transaction_log記錄成功后，再去更新業(yè)務(wù)數(shù)據(jù)表user_info中的內(nèi)容，最后更新緩存中的userInfo數(shù)據(jù)。緩存更新成功后，就可以刪除transaction_log表中對應(yīng)的記錄。

假設(shè)在更新完user_info表之后，由于網(wǎng)絡(luò)抖動等原因?qū)е戮彺娓率。瑒ttransaction_log表中對應(yīng)的記錄就會一直存在，表示這個事務(wù)沒有完成的一種記錄。

應(yīng)用會創(chuàng)建一個定時任務(wù)，周期性的掃描transaction_log表中的記錄(例如每隔2S掃描一次)。發(fā)現(xiàn)有符合條件的記錄，就嘗試執(zhí)行補(bǔ)償邏輯。例如更新用戶信息時，DB中的user_info表更新成功，但緩存更新失敗，定時任務(wù)發(fā)現(xiàn)transaction_log表中對應(yīng)的記錄沒有刪除且已經(jīng)超過正常等待時間，就嘗試使緩存和DB一致(可以刪除緩存中對應(yīng)的數(shù)據(jù)，也可以根據(jù)userId重新查詢DB再補(bǔ)充的緩存)。補(bǔ)償任務(wù)執(zhí)行完成后，就可以刪除transaction_log表中對應(yīng)的記錄。如果補(bǔ)償任務(wù)執(zhí)行再次失敗，就保留transaction_log表中的記錄，等待下個周期再次執(zhí)行。

事務(wù)補(bǔ)償這種方式保證的是事務(wù)的最終一致性，即如果發(fā)生意外，會存在一個時間窗口(例如2S)，在這個窗口內(nèi)DB和緩存間是不一致的，但能保證最終兩者的數(shù)據(jù)是一致的。至于定時任務(wù)周期的設(shè)定，要結(jié)合業(yè)務(wù)對“臟”數(shù)據(jù)的敏感程度以及系統(tǒng)的負(fù)載。

事務(wù)型消息

對于一個金融系統(tǒng)，假設(shè)有一個需求是用戶注冊成功后自動為用戶創(chuàng)建一個賬戶。客戶的信息維護(hù)在客戶中心系統(tǒng)，客戶的賬戶信息維護(hù)的賬務(wù)中心系統(tǒng)，如果用戶注冊成功，必須保證客戶的賬戶在賬務(wù)系統(tǒng)創(chuàng)建成功。這顯然也是一個分布式事務(wù)問題。

處理這個問題，顯然也可以采用上一小節(jié)介紹的事務(wù)補(bǔ)償機(jī)制來處理。但注冊和開戶并不要求一定是同步完成，且需要感知用戶注冊成功事件的系統(tǒng)并不只有賬務(wù)系統(tǒng)一個(例如營銷系統(tǒng)可能也需要感知用戶注冊成功的事件，給用戶發(fā)優(yōu)惠券)，所以使用消息機(jī)制異步通知更加合適。那么問題就變成了“如果用戶注冊成功，一定要保證消息發(fā)送成功”。

應(yīng)對這種場景，可以使用事務(wù)型消息。但前提條件是使用的MQ中間件必須支持事務(wù)型消息，比如阿里的RocketMQ。目前市面上其它一些主流的MQ中間件都不支持事務(wù)型消息，比如Kafka和RabbitMQ都不支持。

下面的序列圖是事務(wù)型消息的執(zhí)行流程：

• 相比于普通消息，發(fā)布者發(fā)送消息后，MQ并不是馬上將消息發(fā)送給訂閱者，而僅僅是將消息持久化存儲下來。
• 發(fā)送消息成功之后，發(fā)布者執(zhí)行本地事務(wù)。例如我們例子中提到的用戶注冊。
• 根據(jù)本地事務(wù)執(zhí)行是否成功，發(fā)布者決定對之前已經(jīng)發(fā)送的消息是commit還是rollback。如果是rollback，MQ會刪除之前存儲的消息。假設(shè)我們這里發(fā)送commit。
• MQ接收到發(fā)布者發(fā)送的commit后，才會將消息發(fā)送給訂閱者。之后，就可以利用MQ的消息可靠傳輸特性促使訂閱者完成剩余事務(wù)操作，例如上面例子中提到的開戶操作。

細(xì)心的小伙伴會發(fā)現(xiàn)，如果在上圖中的第5步發(fā)生問題導(dǎo)致發(fā)送commit失敗，不還是會導(dǎo)致消息發(fā)布者和消息訂閱者間事務(wù)的不一致嗎？為了防止這種情況的發(fā)生，增加MQ超時回調(diào)機(jī)制。

下面的序列圖是事務(wù)型消息commit失敗時的執(zhí)行流程：

當(dāng)MQ長時間收不到發(fā)布者的commit/rollback通知時，MQ會回調(diào)發(fā)布者應(yīng)用詢問本地事務(wù)是否執(zhí)行成功，是commit還是rollback之前的消息。發(fā)布者需要提供對應(yīng)的callback，在callback中判斷本地事務(wù)是否執(zhí)行成功。

TCC兩階段提交

在某些場景下，一個分布式事務(wù)可能會涉及到多個參與者，且每個參與者需要根據(jù)自己當(dāng)時的狀態(tài)對事務(wù)進(jìn)行響應(yīng)。

假設(shè)這樣一個場景，一個電商網(wǎng)站可以允許用戶在支付時選擇多種支付方式。例如總共需要支付100元錢，用戶可以選擇積分支付10元，賬戶余額支付90元。用戶的積分由營銷系統(tǒng)負(fù)責(zé)，賬戶余額由賬務(wù)系統(tǒng)負(fù)責(zé)，訂單的狀態(tài)管理由訂單系統(tǒng)負(fù)責(zé)。

• 首先，要先確保事務(wù)的各個參與者滿足條件才能執(zhí)行事務(wù)。例如積分系統(tǒng)要確保用戶的積分超過10元錢，賬務(wù)系統(tǒng)要確保用戶的賬戶余額大于90元錢才能發(fā)起這次交易。
• 其次，就是要滿足事務(wù)的原子性。這里的用戶積分、用戶余額、訂單狀態(tài)，要嘛全部處理成功，要嘛全部保持不變。

應(yīng)對這種分布式事務(wù)場景，可以采用TCC兩階段提交的方式進(jìn)行處理。

TCC將整個事務(wù)分成兩個階段——try和commit/cancel。TCC整個流程具有三種角色——事務(wù)發(fā)起者、事務(wù)參與者、事務(wù)協(xié)調(diào)者。以上面的訂單支付為例，采用TCC實現(xiàn)處理事務(wù)的流程如下：

• 第一階段try，訂單系統(tǒng)分別調(diào)用promotion和account兩個系統(tǒng)，詢問該用戶是否有足夠的積分和賬戶余額。為了防止資源爭搶，在這個階段會對資源進(jìn)行鎖定，即營銷系統(tǒng)會鎖住用戶的10元積分，賬務(wù)系統(tǒng)會鎖住用戶的90元賬戶余額。
• 如果在try階段有任何一個參與者處理失敗(例如用戶積分不夠10元或者用戶的余額不夠90元)，則事務(wù)發(fā)起方(訂單系統(tǒng))會通知事務(wù)協(xié)調(diào)組件，后者會通知所有的事務(wù)參與者cancel在try階段鎖定的資源。
• 如果在try階段所有的參與者都處理成功，則事務(wù)發(fā)起方通知協(xié)調(diào)者commit這個事務(wù)，協(xié)調(diào)者會通知所有的參與者完成事務(wù)的commit。這時系統(tǒng)會完成真正的余額和積分扣減。2.2步是假設(shè)訂單系統(tǒng)也要更新訂單的狀態(tài)。

但僅是這樣處理還是有一致性問題，例如在第二階段commit時如果發(fā)生宕機(jī)、網(wǎng)絡(luò)抖動等異常情況，就可能導(dǎo)致事務(wù)處于“非最終一致”狀態(tài)(參與者只執(zhí)行了try階段，沒有執(zhí)行第二階段。或部分參與者第二階段commit成功，部分參與者commit失敗)。為了應(yīng)對這種情況，需要增加事務(wù)日志，以便發(fā)生異常時回復(fù)事務(wù)。

可以利用DB這種可靠存儲來記錄事務(wù)日志。日志中應(yīng)包含事務(wù)執(zhí)行過程中的上下文、事務(wù)執(zhí)行狀態(tài)、事務(wù)的參與者等信息。事務(wù)日志可以由事務(wù)發(fā)起發(fā)負(fù)責(zé)記錄，也可以交由事務(wù)協(xié)調(diào)方進(jìn)行記錄。

事務(wù)日志可以由主事務(wù)記錄日志和從事務(wù)記錄日志組成：

• 主事務(wù)記錄日志 用于記錄事務(wù)發(fā)起方信息以及事務(wù)執(zhí)行的整體狀態(tài)。
• 從事務(wù)記錄日志 用于記錄所有的事務(wù)參與者信息，以及每個參與者所屬的從事務(wù)的執(zhí)行狀態(tài)。與主事務(wù)記錄日志是一對多的關(guān)系。

有了事務(wù)日志后，就可以周期性的不斷掃描事務(wù)日志，找到異常中斷的事務(wù)。根據(jù)事務(wù)日志中記錄的信息，推動剩余的參與者commit或者cancel，以便使整個分布式事務(wù)達(dá)到“最終一致性”。

下面是commit階段發(fā)生異常時的事務(wù)補(bǔ)償邏輯：

TCC兩階段提交的實現(xiàn)需要注意如下事項：

1. 事務(wù)中的任何一個參與者都要確保在try階段操作成功，在第二階段就一定能commit成功。
2. 參與者在實現(xiàn)commit和cancel接口時要考慮冪等，對重復(fù)的commit/cancel請求要能夠正確處理。
3. 業(yè)務(wù)上要考慮對兩階段中間狀態(tài)(一階段已完成，二階段未開始)的處理。一般可以通過一些特殊文案，比如顯示當(dāng)前被凍結(jié)的賬戶余額。
4. 對于狀態(tài)型數(shù)據(jù)，當(dāng)多個事務(wù)共同操作同一個資源時，要確保資源隔離。例如賬戶余額，確保不同的事務(wù)操作的金額是隔離的，彼此互不影響。
5. 由于網(wǎng)絡(luò)丟包、亂序等因素的影響，可能會導(dǎo)致參與者接收到一階段try請求后，永遠(yuǎn)收不到commit/cancel請求，導(dǎo)致參與者的資源一直被鎖定，永遠(yuǎn)不會被釋放，這種情況叫做事務(wù)懸掛。為了防止事務(wù)懸掛的發(fā)生，可以在第一階段try成功后，指定一個最大等待時間。超過這個最大等待時間就自動釋放被鎖定的資源。

總結(jié)

傳統(tǒng)的單機(jī)事務(wù)應(yīng)滿足A(原子性)、C(一致性)、I(隔離型)、D(持久性)四個特性，屬于剛性事務(wù)。由于分布式系統(tǒng)具有多個節(jié)點的特點，要求完全滿足ACID這四個規(guī)范會非常的困難。所以就誕生了柔性事務(wù)BASE理論(Basic availability、Soft state、Eventual consistency)。

相比于單機(jī)事務(wù)，分布式事務(wù)在A和D上仍能夠嚴(yán)格保證，但在C和I上就要有一定程度的限制放寬(允許看到中間狀態(tài)數(shù)據(jù)、最終一致性)。