事務(wù)
事務(wù)是什么：做為單個(gè)邏輯單元執(zhí)行的一組操作，要么全成功，要么都失敗。
事務(wù)4個(gè)特性：原子性，一致性，隔離性，持久性。
分布式事務(wù)
分布式事務(wù)用于在分布式系統(tǒng)中保證不同節(jié)點(diǎn)之間的數(shù)據(jù)一致性。分布式事務(wù)的實(shí)現(xiàn)由很多種，最具代表性的是由Oracle Tuxedo系統(tǒng)提出的XA分布式事務(wù)協(xié)議。
XA協(xié)議
包含兩種實(shí)現(xiàn)
兩階段提交（2PC）：第一階段提交事務(wù)請(qǐng)求，第二階段執(zhí)行事務(wù)提交（統(tǒng)一提交或者回滾）。
- 優(yōu)點(diǎn)：原理簡(jiǎn)單，實(shí)現(xiàn)方便。
- 缺點(diǎn)：同步阻塞對(duì)資源鎖定時(shí)間長(zhǎng)，單點(diǎn)問(wèn)題協(xié)調(diào)者的可用性在至關(guān)重要，協(xié)調(diào)者發(fā)送完commit之前自身崩潰造成有些節(jié)點(diǎn)commit有些沒(méi)有而數(shù)據(jù)不一致，太過(guò)保守。
三階段提交（3PC）：第一階段CanCommit，第二階段PreCommit（事務(wù)操作在此處執(zhí)行但不提交），第三階段doCommit。 - 優(yōu)點(diǎn)：相對(duì)于二階段提交，最大的優(yōu)勢(shì)降低了參與者的阻塞范圍，并且能夠在出現(xiàn)單點(diǎn)故障后繼續(xù)達(dá)成一致。
- 缺點(diǎn)：參與者收到PreCommit消息之后，再出現(xiàn)網(wǎng)絡(luò)問(wèn)題，參與者超時(shí)收不到協(xié)調(diào)者消息會(huì)繼續(xù)提交事務(wù)造成數(shù)據(jù)不一致。
參考：《從Paxos到ZooKeeper-分布式一致性原理與實(shí)踐》第2章
TCC方案
TCC方案是二階段提交的一種改進(jìn)。將整個(gè)業(yè)務(wù)邏輯的每個(gè)分支顯示的分成了Try、Confirm、Cancel三個(gè)操作。Try完成業(yè)務(wù)的準(zhǔn)備工作，Confirm完成業(yè)務(wù)的提交，Cancel完成事務(wù)的回滾。
TCC方案讓?xiě)?yīng)用自己定義數(shù)據(jù)庫(kù)操作的粒度，使得降低鎖沖突、提高吞吐量成為可能。
缺點(diǎn)集中表現(xiàn)在以下兩個(gè)方面：
- 對(duì)應(yīng)用的侵入性強(qiáng)。業(yè)務(wù)邏輯的每個(gè)分支都需要實(shí)現(xiàn)try、confirm、cancel三個(gè)操作，應(yīng)用侵入性較強(qiáng)，改造成本高。
- 實(shí)現(xiàn)難度較大。需要按照網(wǎng)絡(luò)狀態(tài)、系統(tǒng)故障等不同的失敗原因?qū)崿F(xiàn)不同的回滾策略。為了滿足一致性的要求，confirm和cancel接口必須實(shí)現(xiàn)冪等。
上述原因?qū)е耇CC方案大多被研發(fā)實(shí)力較強(qiáng)、有迫切需求的大公司所采用。微服務(wù)倡導(dǎo)服務(wù)的輕量化、易部署，而TCC方案中很多事務(wù)的處理邏輯需要應(yīng)用自己編碼實(shí)現(xiàn)，復(fù)雜且開(kāi)發(fā)量大。
基于消息的最終一致性方案
消息一致性方案是通過(guò)消息中間件保證上、下游應(yīng)用數(shù)據(jù)操作的一致性。
基本思路：是將本地操作和發(fā)送消息放在一個(gè)事務(wù)中，保證本地操作和消息發(fā)送要么兩者都成功或者都失敗。下游應(yīng)用向消息系統(tǒng)訂閱該消息，收到消息后執(zhí)行相應(yīng)操作。
本質(zhì)上是：將分布式事務(wù)轉(zhuǎn)換成兩個(gè)本地事務(wù)，然后依靠下游業(yè)務(wù)的重試機(jī)制達(dá)到最終一致性。
最終一致性
最終一致性描述的是分布式系統(tǒng)中，當(dāng)系統(tǒng)在數(shù)據(jù)一致的狀態(tài)執(zhí)行更新之后，也應(yīng)該保持一致的狀態(tài)。具體實(shí)現(xiàn)中可以表現(xiàn)為過(guò)程中異步軟一致性，但結(jié)果要強(qiáng)一致性。
相關(guān)理論包括：
ACID事務(wù)特性理論：數(shù)據(jù)庫(kù)事務(wù)的基本要素，原子性，一致性，隔離性，持久性
CAP分布式理論：分布式系統(tǒng)中一致性，可用性，分區(qū)容錯(cuò)性最多可以同時(shí)實(shí)現(xiàn)兩個(gè)，不可能三者兼得
BASE理論：Basic Availability業(yè)務(wù)基本可用，Soft state柔性狀態(tài)，Eventual consistency最終一致性
最終一致性常用的方法
單數(shù)據(jù)庫(kù)
通過(guò)數(shù)據(jù)的事務(wù)的特性可以很好的解決，并且此時(shí)是強(qiáng)一致性。
多數(shù)據(jù)庫(kù)
針對(duì)多數(shù)據(jù)庫(kù)事務(wù)可以根據(jù)二階段提交協(xié)議，可以通過(guò)Spring + Atomikos + JTA進(jìn)行實(shí)現(xiàn)。
Altomikos是一款Java平臺(tái)事務(wù)管理器，它是封裝了XA特性的一個(gè)中間價(jià)。
JTA（Java Transaction API）Java事務(wù)編程接口，為JEE平臺(tái)提供分布式事務(wù)服務(wù)。
基于事務(wù)性消息隊(duì)列的最終一致性
第一步保證本地事務(wù)和提交消息都執(zhí)行成功，第二步消息隊(duì)列來(lái)投遞進(jìn)行處理，并重試機(jī)制保證執(zhí)行成功。僅適用于第一階段成功，第二階段必須成功的場(chǎng)景。
基于消息隊(duì)列和定時(shí)補(bǔ)償機(jī)制的最終一致性
相對(duì)于上一種依賴消息中間件自身的重試邏輯，而是通過(guò)單獨(dú)的補(bǔ)償任務(wù)機(jī)制來(lái)實(shí)現(xiàn)。其中補(bǔ)償任務(wù)機(jī)制又可通過(guò)多種方式實(shí)現(xiàn)包括：
- 定時(shí)任務(wù)補(bǔ)償：通過(guò)定時(shí)任務(wù)跟進(jìn)后續(xù)任務(wù)，根據(jù)不同的狀態(tài)表確定下一步的操作，來(lái)保證業(yè)務(wù)最終執(zhí)行成功。缺點(diǎn)是可能設(shè)計(jì)很多后臺(tái)服務(wù)，維護(hù)起來(lái)比較麻煩。
- 消息補(bǔ)償：通過(guò)消息中間件返回結(jié)果觸發(fā)后續(xù)的任務(wù)。
引入異步回調(diào)機(jī)制
通過(guò)類似回調(diào)通知的邏輯，通知調(diào)用者執(zhí)行結(jié)果。
