CAP原理和BASE思想： http://www.jdon.com/37625
分佈式事務如何處理?
解決方案有很多種！
比如事務補償機制：即在事務鏈中的任何一個正向事務操作，都必須存在一個完全符合回滾規則的可逆事務。
或者兩階段提交、三階段提交：分佈式事務服務(DTS) 支付寶的DTS實現！最近也看見一個tcc方案GitHub - changmingxie/tcc-transaction: tcc-transaction是TCC型事務java實現 可以簡單看一下;
或者利用消息系統實現最終一致性；
------------------------------------
概念澄清
- 事務補償機制: 在事務鏈中的任何一個正向事務操作, 都必須存在一個完全符合回滾規則的可逆事務.
- CAP理論: CAP(Consistency, Availability, Partition Tolerance), 闡述了一個分佈式系統的三個主要方面, 只能同時擇其二進行實現. 常見的有CP系統, AP系統.
- 冪等性: 簡單的說, 業務操作支持重試, 不會產生不利影響. 常見的實現方式: 爲消息額外增加唯一ID.
- BASE(Basically avaliable, soft state, eventually consistent): 是分佈式事務實現的一種理論標準.
- 分佈式緩存 ：redis集羣就算一種實現
CAP理論
Consistency(一致性), 數據一致更新，所有數據變動都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區容忍性) 可靠性
定理：任何分佈式系統只可同時滿足二點，沒法三者兼顧。
忠告：架構師不要將精力浪費在如何設計能滿足三者的完美分佈式系統，而是應該進行取捨。
ACID模型
Atomicity原子性：一個事務中所有操作都必須全部完成，要麼全部不完成。
Consistency一致性. 在事務開始或結束時，數據庫應該在一致狀態。
Isolation隔離層. 事務將假定只有它自己在操作數據庫，彼此不知曉。
Durability持久性. 一旦事務完成，就不能返回。
關係數據庫的ACID模型擁有 高一致性 + 可用性；
跨數據庫事務：
2PC (two-phase commit)，
2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，JavaEE中的JTA事務可以支持2PC。因爲2PC是反模式，儘量不要使用2PC，使用BASE來回避。
TCC (Try-Confirm-Cancle)
是基於補償型事務的AP系統的一種實現, 具有最終一致性：
BASE思想
Base：一種 Acid 的替代方案
此方案是 eBay 的架構師 Dan Pritchett 在 2008 年發表給 ACM 的文章，是一篇解釋 BASE 原則，或者說最終一致性的經典文章。文中討論了 BASE 與 ACID 原則在保證數據一致性的基本差異。
如果 ACID 爲分區的數據庫提供一致性的選擇，那麼如何實現可用性呢？答案是
BASE (basically available, soft state, eventually consistent)
BASE 的可用性是通過支持局部故障而不是系統全局故障來實現的。下面是一個簡單的例子：如果將用戶分區在 5 個數據庫服務器上，BASE 設計鼓勵類似的處理方式，一個用戶數據庫的故障隻影響這臺特定主機那 20% 的用戶。這裏不涉及任何魔法，不過它確實可以帶來更高的可感知的系統可用性。
文章中描述了一個最常見的場景，如果產生了一筆交易，需要在交易表增加記錄，同時還要修改用戶表的金額。這兩個表屬於不同的遠程服務，所以就涉及到分佈式事務一致性的問題。
文中提出了一個經典的解決方法，將主要修改操作以及更新用戶表的消息放在一個本地事務來完成。同時爲了避免重複消費用戶表消息帶來的問題，達到多次重試的冪等性，增加一個更新記錄表 updates_applied 來記錄已經處理過的消息。
系統的執行僞代碼如下
基於以上方法，在第一階段，通過本地的數據庫的事務保障，增加了 transaction 表及消息隊列 。
在第二階段，分別讀出消息隊列（但不刪除），通過判斷更新記錄表 updates_applied 來檢測相關記錄是否被執行，未被執行的記錄會修改 user 表，然後增加一條操作記錄到 updates_applied，事務執行成功之後再刪除隊列。
通過以上方法，達到了分佈式系統的最終一致性。
------------------------------
參考：https://blog.csdn.net/liuquanyi/article/details/2065475
X/Open組織 與 X/Open DTP模型 與 XA 關係
X/Open組織（即現在的Open Group）定義了分佈式事務處理模型。
X/Open DTP模型（1994）包括應用程序（AP）、事務管理器（TM）、資源管理器（RM）、通信資源管理器（CRM）四部分。
XA就是X/Open DTP定義的交易中間件與數據庫之間的接口規範（即接口函數），交易中間件用它來通知數據庫事務的開始、結束以及提交、回滾等。XA接口函數由數據庫廠商提供。
通常情況下，交易中間件與數據庫通過XA 接口規範，使用兩階段提交來完成一個全局事務，XA規範的基礎是兩階段提交協議。
JTA(Java Transaction API)是符合X/Open DTP模型的，事務管理器和資源管理器之間也使用了XA協議。 本質上也是藉助兩階段提交協議來實現分佈式事務的
------------------------------
ACID、BASE和CAP原理
參考地址：https://blog.csdn.net/sinat_27186785/article/details/52032510
------------------------------
分佈式事務框架--代碼：https://github.com/QNJR-GROUP/EasyTransaction
分佈式事務場景：
- 無需分佈式事務
- 最常用
- 最優先使用
- 使用消息隊列完成的最終一致性事務
- 適用於業務主邏輯無需外部數據變更協助來完成的最終一致性事務
- 常見
- 若一定要與其他服務寫接口發生交互，則優先使用
- 依據是否保證投遞到訂閱者，分爲可靠消息及最大努力交付消息
- 有時業務要求一些本質是異步的操作同步返回結果，若同步返回失敗則後臺異步補單。這種業務本質也歸屬於無需外部數據變更以協助完成的最終一致性，但介於其同步時要返回結果，其有區別於可靠消息。
- 使用傳統補償完成的最終一致性事務
- 適用於需要獲取遠程執行結果來決定邏輯事務走向 且 可以進行補償的業務
- 次常見
- 若使用消息隊列不能解決的事務問題優先考慮使用基於補償的最終一致性事務
- 使用TCC完成最終一致性事務
- 適用於需要獲取遠程執行結果來決定邏輯事務走向 且 不可以進行補償的業務
- 最不常見
- 最終解決辦法，囊括所有必須使用2PC實現的場景。編碼量最大，性能消耗最大，應儘量避免使用本類型的事務
-------------------------------
參考： https://www.cnblogs.com/luoyunfei99/articles/6803682.html
分佈式事務原理：分段式提交 -- 2PC (two-phase commit)
分佈式事務通常採用2PC協議，全稱Two Phase Commitment Protocol。該協議主要爲了解決在分佈式數據庫場景下，所有節點間數據一致性的問題。分佈式事務通過2PC協議將提交分成兩個階段：
- prepare；
- commit/rollback
階段一爲準備（prepare）階段。即所有的參與者準備執行事務並鎖住需要的資源。參與者ready時，向transaction manager報告已準備就緒。
階段二爲提交階段（commit）。當transaction manager確認所有參與者都ready後，向所有參與者發送commit命令。
缺點
- 兩階段提交中的第二階段, 協調者需要等待所有參與者發出yes請求, 或者一個參與者發出no請求後, 才能執行提交或者中斷操作. 這會造成長時間同時鎖住多個資源, 造成性能瓶頸, 如果參與者有一個耗時長的操作, 性能損耗會更明顯.
- 實現複雜, 不利於系統的擴展, 不推薦.
-------------------------------
參考： https://blog.csdn.net/congyihao/article/details/70195154
TCC (Try-Confirm-Cancle)
是基於補償型事務的AP系統的一種實現, 具有最終一致性：
優點
- TCC能夠對分佈式事務中的各個資源進行分別鎖定, 分別提交與釋放, 例如, 假設有AB兩個操作, 假設A操作耗時短, 那麼A就能較快的完成自身的try-confirm-cancel流程, 釋放資源. 無需等待B操作. 如果事後出現問題, 追加執行補償性事務即可.
- TCC是綁定在各個子業務上的(除了cancle中的全局回滾操作), 也就是各服務之間可以在一定程度上”異步並行”執行.
注意事項
- 事務管理器(協調器)這個節點必須以帶同步複製語義的高可用集羣(HAC)方式部署.
- 事務管理器(協調器)還需要使用多數派算法來避免集羣發生腦裂問題.
適用場景
- 嚴格一致性
- 執行時間短
- 實時性要求高
舉例: 紅包, 收付款業務.
------------------------------
參考： https://blog.csdn.net/congyihao/article/details/70195154
異步確保型
通過將一系列同步的事務操作變爲基於消息執行的異步操作, 避免了分佈式事務中的同步阻塞操作的影響.
這個方案真正實現了兩個服務的解耦, 解耦的關鍵就是異步消息和補償性事務.
這裏以一個例子作爲講解:
需要額外說明的一點, 就是事務消息投遞到MQ訂閱方後, 並不一定能夠成功執行. 需要MQ訂閱方主動給予消費反饋(ack)
- 如果MQ訂閱方執行遠程事務成功, 則給予消費成功的ack, 那麼MQ Server可以安全將事務消息移除;
- 如果執行失敗, MQ Server需要對消息重新投遞, 直至消費成功.
注意事項
- 消息中間件在系統中扮演一個重要的角色, 所有的事務消息都需要通過它來傳達, 所以消息中間件也需要支持 HAC 來確保事務消息不丟失.
- 根據業務邏輯的具體實現不同，還可能需要對消息中間件增加消息不重複, 不亂序等其它要求.
適用場景
- 執行週期較長
- 實時性要求不高
例如:
- 跨行轉賬/匯款業務(兩個服務分別在不同的銀行中)
- 退貨/退款業務
- 財務, 賬單統計業務(先發送到消息中間件, 然後進行批量記賬)
------------------------------
JDBC事務和JTA事務的區別 ： https://www.cnblogs.com/drizzlewithwind/p/5711653.html
Java中的事務——JDBC事務和JTA事務： https://www.cnblogs.com/chengpeng15/p/5802930.html
一、事務概述
事務表示一個由一系列的數據庫操作組成的不可分割的邏輯單位，其中的操作要麼全做要麼全都不做。
與事務相關的操作主要有：
BEGIN TRANSACTION； 開始一個事務，方法是：begin()
COMMIT； 提交一個事務，方法是：commit()
ROLLBACK； 回滾一個事務，方法是：rollback()
PREPARE； 準備提交一個事務，方法是：prepare()
二、事務的特性（ACID）
1、原子性：同一個事務的操作要麼全部成功執行，要麼全部撤消
2、隔離性：事務的所有操作不會被其它事務干擾
3、一致性：在操作過程中不會破壞數據的完整性
4、時效性 ：事務的結果必須持久保存於介質上
三、JDBC和JTA事務區別
簡單的說 jta是多庫的事務 jdbc是單庫的事務；
JDBC事務由Connnection對象控制管理，也就是說，事務管理實際上是在JDBC Connection中實現。事務週期限於Connection的生命週期。
JTA(Java Transaction API)提供了跨數據庫連接（或其他JTA資源）的事務管理能力。JTA事務管理則由JTA容器實現，J2ee框架中事務管理器與應用程序，資源管理器，以及應用服務器之間的事務通訊。
Java事務API（Java Transaction API，簡稱JTA ） 是一個Java企業版 的應用程序接口，在Java環境中，允許完成跨越多個XA資源的分佈式事務。
四、JTA的優缺點
介紹：
JTA的優點很明顯，就是提供了分佈式事務的解決方案，嚴格的ACID。但是，標準的JTA方式的事務管理在日常開發中並不常用，因爲他有很多缺點:
缺點:
實現複雜
通常情況下，JTA UserTransaction需要從JNDI獲取。這意味着，如果我們使用JTA，就需要同時使用JTA和JNDI。
JTA本身就是個笨重的API
通常JTA只能在應用服務器環境下使用，因此使用JTA會限制代碼的複用性。
五、事物處理方式總結
Java事務的類型有三種：JDBC事務、JTA(Java Transaction API)事務、容器事務，其中JDBC的事務操作用法比較簡單，適合於處理同一個數據源的操作。JTA事務相對複雜，可以用於處理跨多個數據庫的事務，是分佈式事務的一種解決方案。這裏還要簡單說一下，雖然JTA事務是Java提供的可用於分佈式事務的一套API，但是不同的J2EE平臺的實現都不一樣，並且都不是很方便使用，所以，一般在項目中不太使用這種較爲負責的API。現在業內比較常用的分佈式事務解決方案主要有異步消息確保型、TCC、最大努力通知等。關於這幾種分佈式事務解決方案，我會在後面的文章中介紹。歡迎關注與交流。