云計算
背景
分布式事務(wù)是企業(yè)集成中的一個技術(shù)難點，也是每一個分布式系統(tǒng)架構(gòu)中都會涉及到的一個東西，特別是在微服務(wù)架構(gòu)中，幾乎可以說是無法避免。
acid
指數(shù)據(jù)庫事務(wù)正確執(zhí)行的四個基本要素：
原子性（atomicity）
一致性（consistency）
隔離性（isolation）
持久性（durability）
cap
cap原則又稱cap定理，指的是在一個分布式系統(tǒng)中，一致性（consistency）、可用性（availability）、分區(qū)容忍性（partition tolerance）。cap 原則指的是，這三個要素最多只能同時實現(xiàn)兩點，不可能三者兼顧。
一致性：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值。
可用性：在集群中一部分節(jié)點故障后，集群整體是否還能響應(yīng)客戶端的讀寫請求。
分區(qū)容忍性：以實際效果而言，分區(qū)相當(dāng)于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在c和a之間做出選擇。
base理論
base理論是對cap中的一致性和可用性進行一個權(quán)衡的結(jié)果，理論的核心思想就是：我們無法做到強一致，但每個應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。
basically available（基本可用）
soft state（軟狀態(tài)）
eventually consistent（最終一致性）
解決方案
01
兩階段提交（2pc）
兩階段提交2pc是分布式事務(wù)中最強大的事務(wù)類型之一，兩段提交就是分兩個階段提交，第一階段詢問各個事務(wù)數(shù)據(jù)源是否準(zhǔn)備好，第二階段才真正將數(shù)據(jù)提交給事務(wù)數(shù)據(jù)源。
為了保證該事務(wù)可以滿足acid，就要引入一個協(xié)調(diào)者（cooradinator）。其他的節(jié)點被稱為參與者（participant）。協(xié)調(diào)者負(fù)責(zé)調(diào)度參與者的行為，并最終決定這些參與者是否要把事務(wù)進行提交。處理流程如下：
階段一
a)?協(xié)調(diào)者向所有參與者發(fā)送事務(wù)內(nèi)容，詢問是否可以提交事務(wù)，并等待答復(fù)。
b)?各參與者執(zhí)行事務(wù)操作，將 undo 和 redo 信息記入事務(wù)日志中（但不提交事務(wù)）。
c)?如參與者執(zhí)行成功，給協(xié)調(diào)者反饋 yes，否則反饋 no。
?階段二
如果協(xié)調(diào)者收到了參與者的失敗消息或者超時，直接給每個參與者發(fā)送回滾(rollback)消息；否則，發(fā)送提交(commit)消息。兩種情況處理如下：
情況1：當(dāng)所有參與者均反饋 yes，提交事務(wù)
a)?協(xié)調(diào)者向所有參與者發(fā)出正式提交事務(wù)的請求（即 commit 請求）。
b)?參與者執(zhí)行 commit 請求，并釋放整個事務(wù)期間占用的資源。
c)?各參與者向協(xié)調(diào)者反饋 ack(應(yīng)答)完成的消息。
d)?協(xié)調(diào)者收到所有參與者反饋的 ack 消息后，即完成事務(wù)提交。
情況2：當(dāng)有一個參與者反饋 no，回滾事務(wù)
a)?協(xié)調(diào)者向所有參與者發(fā)出回滾請求（即 rollback 請求）。
b)?參與者使用階段 1 中的 undo 信息執(zhí)行回滾操作，并釋放整個事務(wù)期間占用的資源。
c)?各參與者向協(xié)調(diào)者反饋 ack 完成的消息。
d)?協(xié)調(diào)者收到所有參與者反饋的 ack 消息后，即完成事務(wù)。
問題
1)?性能問題：所有參與者在事務(wù)提交階段處于同步阻塞狀態(tài)，占用系統(tǒng)資源，容易導(dǎo)致性能瓶頸。
2)?可靠性問題：如果協(xié)調(diào)者存在單點故障問題，或出現(xiàn)故障，提供者將一直處于鎖定狀態(tài)。
3)?數(shù)據(jù)一致性問題：在階段 2 中，如果出現(xiàn)協(xié)調(diào)者和參與者都掛了的情況，有可能導(dǎo)致數(shù)據(jù)不一致。
優(yōu)點：盡量保證了數(shù)據(jù)的強一致，適合對數(shù)據(jù)強一致要求很高的關(guān)鍵領(lǐng)域。（其實也不能100%%u4fdd證強一致）。
缺點：實現(xiàn)復(fù)雜，犧牲了可用性，對性能影響較大，不適合高并發(fā)高性能場景。
02
三階段提交（3pc）
三階段提交是在二階段提交上的改進版本，3pc最關(guān)鍵要解決的就是協(xié)調(diào)者和參與者同時掛掉的問題，所以3pc把2pc的準(zhǔn)備階段再次一分為二，這樣三階段提交。處理流程如下：
階段一
a)?協(xié)調(diào)者向所有參與者發(fā)出包含事務(wù)內(nèi)容的 cancommit 請求，詢問是否可以提交事務(wù)，并等待所有參與者答復(fù)。
b)?參與者收到 cancommit 請求后，如果認(rèn)為可以執(zhí)行事務(wù)操作，則反饋 yes 并進入預(yù)備狀態(tài)，否則反饋 no。
階段二
協(xié)調(diào)者根據(jù)參與者響應(yīng)情況，有以下兩種可能。
情況1：所有參與者均反饋 yes，協(xié)調(diào)者預(yù)執(zhí)行事務(wù)
a)?協(xié)調(diào)者向所有參與者發(fā)出 precommit 請求，進入準(zhǔn)備階段。
b)?參與者收到 precommit 請求后，執(zhí)行事務(wù)操作，將 undo 和 redo 信息記入事務(wù)日志中（但不提交事務(wù)）。
c)?各參與者向協(xié)調(diào)者反饋 ack 響應(yīng)或 no 響應(yīng)，并等待最終指令。
情況2：只要有一個參與者反饋 no，或者等待超時后協(xié)調(diào)者尚無法收到所有提供者的反饋，即中斷事務(wù)
a)?協(xié)調(diào)者向所有參與者發(fā)出 abort 請求。
b)?無論收到協(xié)調(diào)者發(fā)出的 abort 請求，或者在等待協(xié)調(diào)者請求過程中出現(xiàn)超時，參與者均會中斷事務(wù)。
階段三
該階段進行真正的事務(wù)提交，也可以分為以下兩種情況。
情況 1：所有參與者均反饋 ack 響應(yīng)，執(zhí)行真正的事務(wù)提交
a)?如果協(xié)調(diào)者處于工作狀態(tài)，則向所有參與者發(fā)出 do commit 請求。
b)?參與者收到 do commit 請求后，會正式執(zhí)行事務(wù)提交，并釋放整個事務(wù)期間占用的資源。
c)?各參與者向協(xié)調(diào)者反饋 ack 完成的消息。
d)?協(xié)調(diào)者收到所有參與者反饋的 ack 消息后，即完成事務(wù)提交。
情況2：只要有一個參與者反饋 no，或者等待超時后協(xié)調(diào)組尚無法收到所有提供者的反饋，即回滾事務(wù)。
a)?如果協(xié)調(diào)者處于工作狀態(tài)，向所有參與者發(fā)出 rollback 請求。
b)?參與者使用階段 1 中的 undo 信息執(zhí)行回滾操作，并釋放整個事務(wù)期間占用的資源。
c)?各參與者向協(xié)調(diào)組反饋 ack 完成的消息。
d)?協(xié)調(diào)組收到所有參與者反饋的 ack 消息后，即完成事務(wù)回滾。
優(yōu)點：相比二階段提交，三階段提交降低了阻塞范圍，在等待超時后協(xié)調(diào)者或參與者會中斷事務(wù)。避免了協(xié)調(diào)者單點問題。階段 3 中協(xié)調(diào)者出現(xiàn)問題時，參與者會繼續(xù)提交事務(wù)。
缺點：數(shù)據(jù)不一致問題依然存在，當(dāng)在參與者收到 precommit 請求后等待 do commite 指令時，此時如果協(xié)調(diào)者請求中斷事務(wù)，而協(xié)調(diào)者無法與參與者正常通信，會導(dǎo)致參與者繼續(xù)提交事務(wù)，造成數(shù)據(jù)不一致。
03
補償事務(wù)（tcc）
tcc 是服務(wù)化的二階段編程模型，采用的補償機制：
條件：
需要實現(xiàn)確認(rèn)和補償邏輯
需要支持冪等
處理流程：
a) try 階段主要是對業(yè)務(wù)系統(tǒng)做檢測及資源預(yù)留。
這個階段主要完成：
完成所有業(yè)務(wù)檢查( 一致性 ) 。
預(yù)留必須業(yè)務(wù)資源( 準(zhǔn)隔離性 ) 。
try 嘗試執(zhí)行業(yè)務(wù)。
b) confirm 階段主要是對業(yè)務(wù)系統(tǒng)做確認(rèn)提交。
try階段執(zhí)行成功并開始執(zhí)行 confirm階段時，默認(rèn) confirm階段是不會出錯的。即：只要try成功，confirm一定成功。
c) cancel 階段主要是在業(yè)務(wù)執(zhí)行錯誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務(wù)取消，預(yù)留資源釋放。
優(yōu)點：
性能提升：具體業(yè)務(wù)來實現(xiàn)控制資源鎖的粒度變小，不會鎖定整個資源。
數(shù)據(jù)最終一致性：基于 confirm 和 cancel 的冪等性，保證事務(wù)最終完成確認(rèn)或者取消，保證數(shù)據(jù)的一致性。
可靠性：解決了 xa 協(xié)議的協(xié)調(diào)者單點故障問題，由主業(yè)務(wù)方發(fā)起并控制整個業(yè)務(wù)活動，業(yè)務(wù)活動管理器也變成多點，引入集群。
缺點：tcc 的 try、confirm 和 cancel 操作功能要按具體業(yè)務(wù)來實現(xiàn)，業(yè)務(wù)耦合度較高，提高了開發(fā)成本。
04
本地消息表（消息隊列）
其核心思想是將分布式事務(wù)拆分成本地事務(wù)進行處理。
方案通過在消費者額外新建事務(wù)消息表，消費者處理業(yè)務(wù)和記錄事務(wù)消息在本地事務(wù)中完成，輪詢事務(wù)消息表的數(shù)據(jù)發(fā)送事務(wù)消息，提供者基于消息中間件消費事務(wù)消息表中的事務(wù)。
條件：?
服務(wù)消費者需要創(chuàng)建一張消息表，用來記錄消息狀態(tài)。
服務(wù)消費者和提供者需要支持冪等。
需要補償邏輯。
每個節(jié)點上起定時線程，檢查未處理完成或發(fā)出失敗的消息，重新發(fā)出消息，即重試機制和冪等性機制。
處理流程：
1. 服務(wù)消費者把業(yè)務(wù)數(shù)據(jù)和消息一同提交，發(fā)起事務(wù)。
2. 消息經(jīng)過mq發(fā)送到服務(wù)提供方，服務(wù)消費者等待處理結(jié)果。
3. 服務(wù)提供方接收消息，完成業(yè)務(wù)邏輯并通知消費者已處理的消息。
容錯處理情況如下：
當(dāng)步驟1處理出錯，事務(wù)回滾，相當(dāng)于什么都沒有發(fā)生。
當(dāng)步驟2、3處理出錯，由于消息保存在消費者表中，可以重新發(fā)送到mq進行重試。
如果步驟3處理出錯，且是業(yè)務(wù)上的失敗，服務(wù)提供者發(fā)送消息通知消費者事務(wù)失敗，且此時變?yōu)橄M者發(fā)起回滾事務(wù)進行回滾邏輯。
優(yōu)點：從應(yīng)用設(shè)計開發(fā)的角度實現(xiàn)了消息數(shù)據(jù)的可