分布式事務(wù)知識小結(jié)
1. 事務(wù)的ACID
-
原子性（Atomicity），可以理解為一個事務(wù)內(nèi)的所有操作要么都執(zhí)行，要么都不執(zhí)行。
-
一致性（Consistency），可以理解為數(shù)據(jù)是滿足完整性約束的，也就是不會存在中間狀態(tài)的數(shù)據(jù)，比如你賬上有400，我賬上有100，你給我打200塊，此時你賬上的錢應(yīng)該是200，我賬上的錢應(yīng)該是300，不會存在我賬上錢加了，你賬上錢沒扣的中間狀態(tài)。
-
隔離性（Isolation），指的是多個事務(wù)并發(fā)執(zhí)行的時候不會互相干擾，即一個事務(wù)內(nèi)部的數(shù)據(jù)對于其他事務(wù)來說是隔離的。
- 持久性（Durability），指的是一個事務(wù)完成了之后數(shù)據(jù)就被永遠(yuǎn)保存下來，之后的其他操作或故障都不會對事務(wù)的結(jié)果產(chǎn)生影響。
2. Redis的事務(wù)
-
Redis 的事務(wù)不能保證所有操作要么都執(zhí)行要么都不執(zhí)行。
-
Redis事務(wù)中的某個命令失敗了，之后的命令還是會被處理，Redis 不會停止命令，意味著也不會回滾。
- Redis認(rèn)為如果命令出錯是語法使用錯誤，應(yīng)該在開發(fā)的時候就被檢測出來，不應(yīng)在生產(chǎn)環(huán)境中出現(xiàn)?；貪L并不能免于編程錯誤。
3. 2PC
-
是一種強(qiáng)一致性設(shè)計
-
引入一個事務(wù)協(xié)調(diào)者的角色來協(xié)調(diào)管理各參與者（也可稱之為各本地資源）的提交和回滾，二階段分別指的是準(zhǔn)備（投票）和提交兩個階段
-
正常情況
- 準(zhǔn)備階段：協(xié)調(diào)者會給各參與者發(fā)送準(zhǔn)備命令，理解成除了提交事務(wù)之外啥事都做完。同步等待所有資源的響應(yīng)進(jìn)入提交階段。
- 提交階段：協(xié)調(diào)者則向所有參與者發(fā)送提交事務(wù)命令（提交事務(wù)或者回滾事務(wù)），然后等待所有事務(wù)都提交成功之后，返回事務(wù)執(zhí)行成功。
-
異常情況
- 若準(zhǔn)備階段有一個參與者返回失敗，那么協(xié)調(diào)者就會向所有參與者發(fā)送回滾事務(wù)的請求，即分布式事務(wù)執(zhí)行失敗。
- 第二階段執(zhí)行的是回滾事務(wù)操作，那么答案是不斷重試，直到所有參與者都回滾了，不然那些在第一階段準(zhǔn)備成功的參與者會一直阻塞著
- 第二階段執(zhí)行的是提交事務(wù)操作，那么答案也是不斷重試，因為有可能一些參與者的事務(wù)已經(jīng)提交成功了，這個時候只有一條路，就是頭鐵往前沖，不斷的重試，直到提交成功，到最后真的不行只能人工介入處理
-
協(xié)調(diào)者故障分析
- 2PC 是同步阻塞協(xié)議
- 協(xié)調(diào)者有超時機(jī)制
- 協(xié)調(diào)者是一個單點，存在單點故障問題
- 協(xié)調(diào)者在發(fā)送準(zhǔn)備命令之前掛了，事務(wù)沒開始，無影響
- 協(xié)調(diào)者在發(fā)送準(zhǔn)備命令之后掛了，處于事務(wù)資源鎖定的狀態(tài)，事務(wù)無法執(zhí)行，阻塞其他操作
- 協(xié)調(diào)者在發(fā)送回滾事務(wù)命令之前掛了，事務(wù)無法繼續(xù)提交，第一階段準(zhǔn)備成功的參與者都阻塞
- 協(xié)調(diào)者在發(fā)送回滾事務(wù)命令之后掛了，大的概率都會回滾成功，資源都會釋放。但是如果出現(xiàn)網(wǎng)絡(luò)分區(qū)問題，某些參與者將因為收不到命令而阻塞
- 協(xié)調(diào)者在發(fā)送提交事務(wù)命令之前掛了，資源都阻塞
- 協(xié)調(diào)者在發(fā)送提交事務(wù)命令之后掛了，大的概率都會回滾成功，資源都會釋放。但是如果出現(xiàn)網(wǎng)絡(luò)分區(qū)問題，某些參與者將因為收不到命令而阻塞
-
通過選舉得到新協(xié)調(diào)者
- 每個參與者自身的狀態(tài)只有自己和協(xié)調(diào)者知道，因此新協(xié)調(diào)者無法通過在場的參與者的狀態(tài)推斷出掛了的參與者是什么情況
- 極端情況下還是無法避免數(shù)據(jù)不一致問題
-
總結(jié)
- 同步阻塞的，盡量保證強(qiáng)一致性的分布式事務(wù)
- 總體而言效率低，并且存在單點故障問題，在極端條件下存在數(shù)據(jù)不一致的風(fēng)險
- 不能做到數(shù)據(jù)一致，需要補(bǔ)償機(jī)制
4. 3PC
- 在參與者中也引入了超時機(jī)制
- CanCommit、PreCommit 和 DoCommit
- 正常情況
- 準(zhǔn)備階段：詢問參與者狀態(tài)、負(fù)載
- 預(yù)提交階段：同2PC準(zhǔn)備階段
- 提交階段：同2PC提交階段
- 優(yōu)勢
- 不會直接鎖資源而是先詢問情況
- 加入超時機(jī)制
- 如果是等待預(yù)提交命令超時，那該干啥就干啥了
- 如果是等待提交命令超時，那么參與者就會提交事務(wù)了
- 劣勢
- 多一個階段，性能會差一些，大部分情況資源都可用
- 超時機(jī)制依然存在數(shù)據(jù)不一致情況
- 比如在等待提交命令時候超時了，參與者默認(rèn)執(zhí)行的是提交事務(wù)操作，但是有可能執(zhí)行的是回滾操作，這樣數(shù)據(jù)就不一致了
- 總結(jié)
- 引入預(yù)提交階段來使得參與者之間的狀態(tài)得到統(tǒng)一。如果調(diào)度者掛了，新協(xié)調(diào)者來的時候發(fā)現(xiàn)有一個參與者處于預(yù)提交或者提交階段，那么表明已經(jīng)經(jīng)過了所有參與者的確認(rèn)了，所以此時執(zhí)行的就是提交命令。
- 引入了參與者超時機(jī)制，但整體的交互過程更長了，性能有所下降，并且還是會存在數(shù)據(jù)不一致問題。因為掛了的參與者到底有沒有執(zhí)行事務(wù)無法斷定。需要補(bǔ)償機(jī)制
5. TCC
-
TCC
- Try 指的是預(yù)留，即資源的預(yù)留和鎖定，注意是預(yù)留。
- Confirm 指的是確認(rèn)操作，這一步其實就是真正的執(zhí)行了。
- Cancel 指的是撤銷操作，可以理解為把預(yù)留階段的動作撤銷了。
-
思想上類似2PC，TCC 就是通過代碼人為實現(xiàn)了兩階段提交
-
TCC模型還有個事務(wù)管理者的角色，變成多點，引入集群。用來記錄TCC全局事務(wù)狀態(tài)并提交或者回滾事務(wù)
-
引入超時，超時后進(jìn)行補(bǔ)償，并且不會鎖定整個資源
-
優(yōu)勢
- TCC可以跨數(shù)據(jù)庫、跨不同的業(yè)務(wù)系統(tǒng)來實現(xiàn)事務(wù)
-
劣勢
- TCC 對業(yè)務(wù)的侵入較大和業(yè)務(wù)緊耦合
撤銷和確認(rèn)操作的執(zhí)行可能需要重試，因此還需要保證操作的冪等
6. 本地消息表
-
利用各系統(tǒng)本地的事務(wù)來實現(xiàn)分布式事務(wù)
-
有一張存放本地消息的表，一般都是放在數(shù)據(jù)庫中，然后在執(zhí)行業(yè)務(wù)的時候?qū)I(yè)務(wù)的執(zhí)行和將消息放入消息表中的操作放在同一個事務(wù)中，保證消息放入本地表中業(yè)務(wù)肯定是執(zhí)行成功的
-
后臺任務(wù)定時去讀取本地消息表，篩選出還未成功的消息再調(diào)用對應(yīng)的服務(wù)，服務(wù)更新成功了再變更消息的狀態(tài)。
-
重試就得保證對應(yīng)服務(wù)的方法是冪等的，而且一般重試會有最大次數(shù)，超過最大次數(shù)可以記錄下報警讓人工處理
-
實現(xiàn)的是最終一致性
7. 消息事務(wù)
-
利用MQ事務(wù)
-
先給 Broker 發(fā)送事務(wù)消息即半消息，半消息不是說一半消息，而是這個消息對消費者來說不可見，然后發(fā)送成功后發(fā)送方再執(zhí)行本地事務(wù)
-
再根據(jù)本地事務(wù)的結(jié)果向 Broker 發(fā)送 Commit 或者RollBack命令
-
RocketMQ的發(fā)送方會提供一個反查事務(wù)狀態(tài)接口，如果一段時間內(nèi)半消息沒有收到任何操作請求，那么 Broker 會通過反查接口得知發(fā)送方事務(wù)是否執(zhí)行成功，然后執(zhí)行Commit 或者RollBack命令。
-
如果是 Commit 那么訂閱方就能收到這條消息，然后再做對應(yīng)的操作，做完了之后再消費這條消息即可
-
如果是RollBack那么訂閱方收不到這條消息，等于事務(wù)就沒執(zhí)行過
-
消息事務(wù)實現(xiàn)的也是最終一致性
8. 最大努力通知
- 本地消息表也可以算最大努力，事務(wù)消息也可以算最大努力。
- 最大努力通知其實只是表明了一種柔性事務(wù)的思想：我已經(jīng)盡力我最大的努力想達(dá)成事務(wù)的最終一致了。
- 適用于對時間不敏感的業(yè)務(wù)，例如短信通知。
9. Saga
-
長事務(wù)的解決方案，更適合于“業(yè)務(wù)流程長、業(yè)務(wù)流程多”的場景
-
特別是針對參與事務(wù)的服務(wù)是遺留系統(tǒng)服務(wù)，此類服務(wù)無法提供TCC模式下的三個接口，就可以采用Saga模式
-
針對每一個分布式事務(wù)的每個執(zhí)行操作或者是步驟都是一個 Ti，例如扣減庫存是T1、創(chuàng)建訂單是T2、支付服務(wù)是T3。那么針對每個Ti都對應(yīng)一個補(bǔ)償動作Ci，例如回復(fù)庫存C1、訂單回滾C2、支付回滾C3
-
優(yōu)勢
- 一階段提交本地事務(wù)，無鎖，高性能
- 參與者可異步執(zhí)行，高吞吐
- 補(bǔ)償服務(wù)易于實現(xiàn)，因為一個更新操作的反向操作是比較容易理解的
-
劣勢
- 不保證隔離性（可以看到其他事務(wù)）
- Saga操作模式更像發(fā)電子郵件，發(fā)出的電子郵件是正確的，接收者按正常方式解讀。如果郵件發(fā)錯了，就再發(fā)一封告訴接收者，請忽略上一封郵件。但有時候這個操作已經(jīng)不可逆了。
- 舉例
- 分布式事務(wù)內(nèi)先給用戶A充值，然后給用戶B扣減余額，如果在給A用戶充值成功，在事務(wù)提交以前，A用戶把余額消費掉了，如果事務(wù)發(fā)生回滾，這時則沒有辦法進(jìn)行補(bǔ)償了。
- 應(yīng)對方法
- 業(yè)務(wù)流程設(shè)計時遵循“寧可長款，不可短款”的原則，長款意思是客戶少了錢機(jī)構(gòu)多了錢，以機(jī)構(gòu)信譽(yù)可以給客戶退款，反之則是短款，少的錢可能追不回來了，所以在業(yè)務(wù)流程設(shè)計上一定是先扣款；
- 有些業(yè)務(wù)場景可以允許讓業(yè)務(wù)最終成功，在回滾不了的情況下可以繼續(xù)重試完成后面的流程，達(dá)到最終一致性的目的
- 不保證隔離性（可以看到其他事務(wù)）
-
兩種恢復(fù)策略
-
向前恢復(fù)：對于執(zhí)行不通過的事務(wù)，會嘗試重試事務(wù)，這里有一個假設(shè)就是每個子事務(wù)最終都會成功。這種方式適用于必須要成功的場景
-
向后恢復(fù)：在執(zhí)行事務(wù)失敗時，補(bǔ)償所有已完成的事務(wù)，是“一退到底”的方式。
-
-
兩種模式
-
編排
- 是一種去中心化的模式，參與者之間通過消息機(jī)制進(jìn)行溝通，通過監(jiān)聽器的方式監(jiān)聽其他參與者發(fā)出的消息，從而執(zhí)行后續(xù)的邏輯處理
- 優(yōu)點
- 簡單：每個子事務(wù)進(jìn)行操作時只用發(fā)布事件消息，其他子事務(wù)監(jiān)聽處理。
- 松耦合：參與者（服務(wù)）之間通過訂閱事件進(jìn)行溝通，組合會更加靈活。
- 缺點
- 理解困難
- 存在服務(wù)的循環(huán)依賴是
-
控制
- 定義一個控制類，它會告訴參與者（服務(wù)）應(yīng)該執(zhí)行哪些操作（子事務(wù)）。 Saga控制類通過命令以及異步回復(fù)的方式與參與者進(jìn)行交互。
- 優(yōu)點
- 避免循環(huán)依賴
- 降低復(fù)雜性：所有事務(wù)交給控制器完成
- 容易測試
- 容易擴(kuò)展
- 缺點
- 依賴控制器：控制器中集中太多邏輯的風(fēng)險
- 增加管理難度：還需要額外管理控制類服務(wù)
-
10. 總結(jié)
- 2PC 和 3PC 是一種強(qiáng)一致性事務(wù)，不過還是有數(shù)據(jù)不一致，阻塞等風(fēng)險，而且只能用在數(shù)據(jù)庫層面。
- TCC 是一種補(bǔ)償性事務(wù)思想，適用的范圍更廣，在業(yè)務(wù)層面實現(xiàn)，因此對業(yè)務(wù)的侵入性較大，每一個操作都需要實現(xiàn)對應(yīng)的三個方法
- Saga是一種長事務(wù)的解決方案，比TCC更簡單，但不能保證隔離性
- 本地消息、事務(wù)消息和最大努力通知其實都是最終一致性事務(wù)，因此適用于一些對時間不敏感的業(yè)務(wù)
