前言

---

?相關(guān)系列

• 《分布式 & 目錄》
• 《分布式 & 分布式事務(wù) & 總結(jié)》
• 《分布式 & 分布式事務(wù) & 問題》
  ?
  ?

分布式事務(wù)

---

????所謂分布式事務(wù)是指操作范圍籠罩多個(gè)不同節(jié)點(diǎn)的事務(wù)。例如對(duì)于訂單節(jié)點(diǎn)&庫存節(jié)點(diǎn)而言，一次完整的交易需要同時(shí)調(diào)動(dòng)兩個(gè)節(jié)點(diǎn)。而如果將這個(gè)交易的所有操作作為ACID事務(wù)執(zhí)行，那么該事務(wù)就被稱為分布式事務(wù)。
?
?

2PC @ 2 Phase Commit @ 二階段遞交

---

????2PC&3PC協(xié)議是處理分布式事務(wù)數(shù)據(jù)一致性（與CAP理論的一致性不同，事務(wù)的一致性是指確保數(shù)據(jù)在兩個(gè)“合法”狀態(tài)間的“正確轉(zhuǎn)移”）問題的解決方案，其本質(zhì)是通過確保事務(wù)的原子性來保證一致性。在分布式系統(tǒng)中，節(jié)點(diǎn)雖然可以知曉自身操作的成功與否，但卻無法知曉其他節(jié)點(diǎn)操作的執(zhí)行結(jié)果。因此當(dāng)事務(wù)跨越多個(gè)節(jié)點(diǎn)時(shí)，為了保持事務(wù)的原子性&一致性，需要引入了TM @ 事務(wù)管理器來統(tǒng)一掌握所有RM @ 資源管理器的操作結(jié)果，并決定是否把各資源管理器的操作結(jié)果統(tǒng)一提交/回滾。2PC協(xié)議分為準(zhǔn)備&提交兩個(gè)階段：

• Prepare phase @ 準(zhǔn)備階段：事務(wù)管理器會(huì)向所有資源管理器發(fā)送（2PC/3PC/TCC協(xié)議都只是分布式事務(wù)的實(shí)現(xiàn)思想，因此事務(wù)管理器對(duì)資源管理器的請(qǐng)求發(fā)送無需在意串/并行，但具體的實(shí)現(xiàn)工具/框架就必須考慮這一點(diǎn)，因?yàn)楦鱾€(gè)資源管理器事務(wù)之間可能存在依賴性，例如事務(wù)B的執(zhí)行需要事務(wù)A的執(zhí)行結(jié)果參與）“準(zhǔn)備”請(qǐng)求以確認(rèn)其是否已準(zhǔn)備好遞交事務(wù)。資源管理器在收到“準(zhǔn)備”請(qǐng)求后會(huì)開啟&執(zhí)行本地事務(wù)，但并不真正遞交，而是將Undo和Redo日志寫入本地事務(wù)日志中。Undo日志用于記錄如何回滾事務(wù)，而Redo日志則用于在提交階段重新執(zhí)行事務(wù)操作。盡管在2PC中通常不直接使用Redo日志提交，但它在某些故障恢復(fù)場(chǎng)景中是有用的。本地事務(wù)執(zhí)行結(jié)束后，將成功與否以Yes/No的形式回應(yīng)至事務(wù)管理器；
• Commit phase @ 遞交階段：如果事務(wù)管理器收到所有反饋且發(fā)現(xiàn)資源管理器都已成功執(zhí)行本地事務(wù)則會(huì)決定提交事務(wù)，否則就回滾事務(wù)。各節(jié)點(diǎn)在收到事務(wù)管理器發(fā)送的“遞交/回滾”請(qǐng)求后會(huì)統(tǒng)一將各自的執(zhí)行結(jié)果遞交/回滾。

?

缺點(diǎn)

• 同步阻塞：在整個(gè)分布式事務(wù)未結(jié)束前，所有資源管理器（的事務(wù)涉及業(yè)務(wù)）都會(huì)處于阻塞狀態(tài)；
• 單點(diǎn)故障：事務(wù)管理器是整個(gè)分布式事務(wù)的核心，如果事務(wù)管理器宕機(jī)，那么所有資源管理器都會(huì)被鎖定而無法繼續(xù)執(zhí)行；
• 數(shù)據(jù)不一致：二階段如果出現(xiàn)網(wǎng)絡(luò)分區(qū)/節(jié)點(diǎn)宕機(jī)而導(dǎo)致部分資源管理器未收到事務(wù)遞交指令/事務(wù)遞交失敗，那么就會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。
  ?
  ?

3PC @ 3 Phase Commit @ 三階段遞交

---

????3PC協(xié)議在2PC協(xié)議的基礎(chǔ)上引入了檢查/超時(shí)機(jī)制，用于避免/處理2PC的“同步阻塞/單點(diǎn)故障/數(shù)據(jù)不一致”問題。3PC協(xié)議分為以下三個(gè)階段：

• CanCommit @ 可/詢問遞交：事務(wù)管理器向各資源管理器詢問是否可以支持執(zhí)行/提交事務(wù)。各資源管理器接收到詢問后根據(jù)自身情況向事務(wù)管理器返回Yes/No回應(yīng)。如果事務(wù)管理器沒有在指定時(shí)間內(nèi)接收到所有回應(yīng)/接收到No回應(yīng)，則分布式事務(wù)中斷/取消。可/詢問遞交階段是3PC協(xié)議引入的新階段，目的是事先檢查資源管理器的狀態(tài)能否支持分布式事務(wù)的執(zhí)行/遞交，從而避免無意義的分布式事務(wù)執(zhí)行以增強(qiáng)協(xié)議的可靠性&容錯(cuò)率；
• PreCommit @ 預(yù)提交：在接收到所有Yes回應(yīng)的情況下，分布式事務(wù)會(huì)進(jìn)入預(yù)遞交階段。該階段中事務(wù)管理器會(huì)向各資源管理器發(fā)送預(yù)遞交請(qǐng)求，而接收到請(qǐng)求的各資源管理器會(huì)開啟&執(zhí)行本地事務(wù)但不遞交，并將Undo和Redo日志寫入本地事務(wù)日志中，隨后向事務(wù)管理器發(fā)送Ack回應(yīng)。而如果事務(wù)管理器沒有在指定時(shí)間內(nèi)接收到所有Ack回應(yīng)/接收到Abort回應(yīng)，則事務(wù)管理器會(huì)向各資源管理器發(fā)送Abort請(qǐng)求，從而令各資源管理器回滾本地事務(wù)。而在這階段中如果部分已開啟&執(zhí)行本地執(zhí)行的資源管理器未能在指定時(shí)間內(nèi)接收到Abort請(qǐng)求，則其也會(huì)因?yàn)槌瑫r(shí)而自動(dòng)回滾本地事務(wù)；
• DoCommit @ 最終提交：在接收到所有Ack回應(yīng)后，分布式事務(wù)會(huì)進(jìn)入最終遞交階段。該階段中事務(wù)管理器會(huì)向各資源管理器發(fā)送最終遞交請(qǐng)求，而接收到請(qǐng)求的各資源管理器會(huì)遞交事務(wù)，并向事務(wù)管理器發(fā)送Ack回應(yīng)表示事務(wù)遞交已完成。注意！該階段中而如果有部分資源管理器未能在指定時(shí)間內(nèi)接收到最終遞交請(qǐng)求，則該資源管理器就可能因?yàn)槌瑫r(shí)而自動(dòng)回滾本地事務(wù)，從而無法保證分布式事務(wù)的原子性，并進(jìn)一步破壞數(shù)據(jù)一致性。因此3PC協(xié)議同樣無法完全避免2PC協(xié)議的數(shù)據(jù)不一致問題。
  ?

優(yōu)點(diǎn)

• 可靠性&容錯(cuò)率提升：檢查機(jī)制增強(qiáng)了分布式事務(wù)的可靠性&容錯(cuò)率；
• 超時(shí)機(jī)制減少了對(duì)阻塞時(shí)間：超時(shí)機(jī)制減少了資源管理器等待事務(wù)管理器指令的阻塞時(shí)間；
• 減少了單點(diǎn)故障對(duì)系統(tǒng)的影響：超時(shí)機(jī)制降低了事務(wù)管理器單點(diǎn)故障對(duì)系統(tǒng)的影響。
  ?

缺點(diǎn)

• 復(fù)雜性增加：3PC協(xié)議相比2PC協(xié)議而言需要處理更多狀態(tài)轉(zhuǎn)換&超時(shí)邏輯，這為增加了實(shí)現(xiàn)的難度&出錯(cuò)的可能性；
• 性能開銷：更復(fù)雜的流程同步帶來了是性能開銷的增加；
• 數(shù)據(jù)不一致：3PC協(xié)議依然未能解決數(shù)據(jù)不一致問題，雖然檢查&超時(shí)有助于降低這一點(diǎn)，但網(wǎng)絡(luò)分區(qū)造成的數(shù)據(jù)不一致問題依然是存在的。
  ?
  ?

TCC @ Try Confirm Cancel @ 嘗試確認(rèn)取消

---

????TCC協(xié)議是一種不同于2PC/3PC協(xié)議的分布式事務(wù)解決方案，其核心思想是“補(bǔ)償機(jī)制”，即在分布式事務(wù)出現(xiàn)異常/失敗時(shí)通過執(zhí)行相反的操作來補(bǔ)償之前的行為，從而達(dá)到事務(wù)的一致性。TCC將分布式事務(wù)劃分為以下三個(gè)階段：

• Try @ 嘗試：事務(wù)管理器向事務(wù)協(xié)調(diào)器申請(qǐng)開啟分布式事務(wù)并獲得全局事務(wù)ID，隨后將該全局事務(wù)ID發(fā)送至各資源管理器。資源管理器接收到全局事務(wù)ID后會(huì)向事務(wù)協(xié)調(diào)器注冊(cè)分支事務(wù)ID，從而將分支事務(wù)ID納入該全局事務(wù)ID下管理。此后資源管理器便會(huì)開啟&執(zhí)行本地事務(wù)并預(yù)留必要的資源，以便后續(xù)遞交事務(wù)時(shí)使用，并向事務(wù)管理器報(bào)告當(dāng)前分支事務(wù)的開啟&執(zhí)行情況；
• Confirm @ 確認(rèn)：如果在嘗試階段中的所有的資源管理器都成功開啟&執(zhí)行了本地事務(wù)，那么分布式事務(wù)就會(huì)進(jìn)入確認(rèn)階段。在確認(rèn)階段中事務(wù)管理器會(huì)向各資源管理器發(fā)送確認(rèn)請(qǐng)求，從而令其能夠真正的遞交事務(wù)，并于事務(wù)管理器中標(biāo)記分支事務(wù)已成功遞交；
• Cancel @ 取消：如果在嘗試&確認(rèn)階段中存在資源管理器未能成功開啟&執(zhí)行&遞交本地事務(wù)的情況，那么分布式事務(wù)就會(huì)進(jìn)入取消階段。在取消階段中事務(wù)管理器會(huì)向各資源管理器發(fā)送取消請(qǐng)求，從而回滾尚未遞交的事務(wù)/執(zhí)行相反的操作彌補(bǔ)已遞交的事務(wù)，并于事務(wù)管理器中標(biāo)記分支事務(wù)已成功取消。而對(duì)于因?yàn)楦鞣N原因未能接收到取消請(qǐng)求的資源管理器，由于超時(shí)機(jī)制的存在其也會(huì)自動(dòng)執(zhí)行取消行為，從而極大程度的確保了事務(wù)的原子性。
  ?

優(yōu)點(diǎn)

• 極大確保了原子性：補(bǔ)償機(jī)制的存在使得已遞交的事務(wù)也可以被取消，從而降低因?yàn)榫W(wǎng)絡(luò)分區(qū)而數(shù)據(jù)不一致的風(fēng)險(xiǎn)；
• 避免數(shù)據(jù)庫鎖沖突的低性能風(fēng)險(xiǎn)：TCC通過將數(shù)據(jù)庫的二階段提交上升到微服務(wù)來實(shí)現(xiàn)，避免了數(shù)據(jù)庫二階段提交中鎖沖突導(dǎo)致的長(zhǎng)事務(wù)低性能風(fēng)險(xiǎn)；
• 異步高性能：TCC采用了先try檢查，然后異步實(shí)現(xiàn)confirm的方式，提高了系統(tǒng)的性能和可擴(kuò)展性。
  ?

缺點(diǎn)

• 侵入性強(qiáng)：微服務(wù)的每個(gè)事務(wù)都必須實(shí)現(xiàn)Try/Confirm/Cancel三個(gè)方法，增加了開發(fā)成本和后期維護(hù)改造的成本；
• 等冪性：為了達(dá)到事務(wù)的一致性要求，Try/Confirm/Cancel接口必須實(shí)現(xiàn)等冪性操作，這增加了實(shí)現(xiàn)的復(fù)雜性；
• 事務(wù)日志損耗性能：事務(wù)管理器需要記錄事務(wù)日志，這必定會(huì)損耗一定的性能，并可能使得整個(gè)TCC事務(wù)時(shí)間拉長(zhǎng)。