1.分布式事務產生的原因
來源於微服務、分布式系統之間跨數據庫產生的問題，數據庫做垂直分割(按照業務需求划分數據庫、分庫)，分為多個不同的數據源(JDBC連接)，會產生分布式事務的問題。
在微服務環境下，因為會根據不同的業務會拆分成不同的服務，比如會員服務、訂單服務、商品服務等，讓專業的人做專業的事情，每個服務都有自己獨立的數據庫，並且是獨立運行，互不影響。
服務與服務之間通訊采用RPC遠程調用技術，但是每個服務中都有自己獨立的數據源，即自己獨立的本地事務。兩個服務相互通訊的時候，兩個本地事務互不影響，從而出現分布式事務產生的原因。
2.分布式事務產生的場景
訂單服務、庫存服務。服務之間的調用接口的時候會產生分布式事務的問題，服務之間的調用走的是http協議進行通訊的。
流程圖：
3.Spring事務和分布式事務的區別？
Spring事務是本地事務。
分布式事務是需要跨服務進行通訊的。
4.如何區分分布式事務
不同的JDBC連接,下圖是一個分布式事務場景。雖然二個服務連接的是同一個數據庫，但是它們有各自的JDBC連接，所以屬於分布式事務。
5.分布式事務解決方案
5.1 使用Jta+Automatic 只適合傳統項目。
5.2 消息中間件MQ，底層通過Base理論 柔性事務解決
5.3 2PC(二段提交協議)、3PC
5.4 TCC補償、GTS 屬於阿里產品
5.5 TX-LCN框架
5.6 支付回調方式(重試機制+補償機制)
核心原理：LCN並不生產事務，LCN只是本地事務的協調工。
LCN官網：http://www.txlcn.org/zh-cn/
6.基本的事務概念
原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability)，ACID原則，這種特性也成 剛性事務。
博客：https://www.cnblogs.com/ming-blogs/p/10513874.html
7.base理論
BASE理論是指，Basically Available（基本可用）、Soft-state（ 軟狀態/柔性事務）、Eventual Consistency（最終一致性）。是基於CAP定理演化而來，是對CAP中一致性和可用性權衡的結果。核心思想：即使無法做到強一致性，但每個業務根據自身的特點，采用適當的方式來使系統達到最終一致性。
1、基本可用：指分布式系統在出現故障的時候，允許損失部分可用性，保證核心可用。但不等價於不可用。比如：搜索引擎0.5秒返回查詢結果，但由於故障，2秒響應查詢結果；網頁訪問過大時，部分用戶提供降級服務，等。
2、軟狀態：軟狀態是指允許系統存在中間狀態，並且該中間狀態不會影響系統整體可用性。即允許系統在不同節點間副本同步的時候存在延時。
3、最終一致性：
系統中的所有數據副本經過一定時間后，最終能夠達到一致的狀態，不需要實時保證系統數據的強一致性。最終一致性是弱一致性的一種特殊情況。BASE理論面向的是大型高可用可擴展的分布式系統，通過犧牲強一致性來獲得可用性。ACID是傳統數據庫常用的概念設計，追求強一致性模型。
ACID，指數據庫事務正確執行的四個基本要素的縮寫。包含：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。
軟狀態、最終一致性，對接支付寶項目。
支付寶流程回調：同步回調地址、異步回調地址。
8.CPA理論
CAP由Eric Brewer在2000年PODC會議上提出[1][2]，是Eric Brewer在Inktomi[3]期間研發搜索引擎、分布式web緩存時得出的關於數據一致性(consistency)、服務可用性(availability)、分區容錯性(partition-tolerance)的猜想：
• 數據一致性(consistency)：如果系統對一個寫操作返回成功，那么之后的讀請求都必須讀到這個新數據；如果返回失敗，那么所有讀操作都不能讀到這個數據，對調用者而言數據具有強一致性(strong consistency) (又叫原子性 atomic、線性一致性 linearizable consistency)[5]
• 服務可用性(availability)：所有讀寫請求在一定時間內得到響應，可終止、不會一直等待
• 分區容錯性(partition-tolerance)：在網絡分區的情況下，被分隔的節點仍能正常對外服務
9.柔性事務與剛性事務
柔性事務滿足Base理論(基本可用、最終一致性)、CAP理論。
剛性事務滿足ACID理論。
柔性事務分為：
9.1.二階段型
9.2補償型
9.3異步確保型
9.4最大努力通知型
10.LCN分布式事務原理
LCN並不生產事務，LCN只是本地事務的協調工。
事務協調者、本地服務(訂單服務(發起方)、庫存服務(參與方))。
發起方：調用其他服務接口。
參與方：被別人調用的接口。
執行流程：
1.LCN客戶端（發起方和參與方都必須要注冊到事務協調者中） 建立一個長連接。解答：長連接 好處減少寬帶傳輸 弊端比較占內存。
2.訂單服務（發起方）調用庫存服務接口（參與方）之前會向TxManager事務協調者創建一個事務的分組id。
3.訂單服務（發起方）調用庫存服務接口（參與方）的時候，會在請求頭中存放該事務的分組id，給庫存服務。
4.如果庫存服務獲取到請求頭中有對應的事務分組id，庫存服務業務邏輯代碼執行完畢的，會采用假關閉，不會提交該事務。
5.參與方在什么時候提交事務？
答案：肯定在發起方 執行成功情況下。
訂單服務（發起方）調用庫存服務接口（參與方）之后，如果訂單服務（發起方）執行沒有問題的情況下。
訂單服務（發起方）使用對應的事務分組id，通知給TxManager事務協調者，讓后TxManager事務協調者在根據該事務分組id，通知給所有的參與方提交事務。
集成LCN分布式事務注意事項
版本集成問題: 目前LCN版本已經升級為4.0了，但是官方沒有SpringCloud2.0的demo案例。因為LCN本身是開源的，網上有大牛對LCN框架源碼做修改，可以支持SpringCloud2.0版本。 使用LCN官方提供的@TxTransaction注解解決分布式事務難題，isStart參數是否LCN事務發起方 true 是:是發起方 false 否:是參與方。
LCN 官網：http://www.txlcn.org/zh-cn/
github地址：https://github.com/codingapi/tx-lcn
博客內容來源：http://www.mayikt.com/