1，分佈式事務產生的背景；
分情況而定。
1，在單體項目中，多個不同的業務邏輯都是在同一個數據源中心實現事務管理，是不存在分佈式事務的問題。因爲在同一個數據源的情況下都是採用事務管理器，相當於每個事務管理器對應一個數據源。
2，在單體項目中，有多個不同的數據源，每個數據源中都有自己獨立的事務管理器，互不影響，那麼這時候也會存在多數據源事務管理：解決方案jta+Atomikos
3，在分佈式/微服務架構中。每個服務都有自己的本地的事務。每個服務本地事務互不影響，那麼這時候也會存在分佈式事務的問題。
分佈式事務產生的背景：訂單服務調用派單服務接口成功之後，可能會引發錯誤。
2pc3pc思想，實際上都是解決我們在分佈式系統中，每個節點保證數據一致性問題。
事務的定義。
對我們業務邏輯可以實現提交或者是回滾，保證數據一致性的情況。所以，要麼提交，要麼回滾。
原子性a 要麼提交 要麼回滾。
一致性 c
持久性d 事務一旦提交或者回滾後，不會再對該結果有任何的影響。
Base 與 cap理論。
1，cap定律
這個定理的內容是指的是在一個分佈式系統中,Consistency（一致性），Availability（可用性），Partition tolerance(分區容錯性)，二者不可兼容。
1，一致性（C）
在分佈式系統中的所有數據備份，是在同一時刻是否同樣的值，（等同於所有節點訪問同一份最新的數據副本）
2，可用性 A
在集羣中一部分節點故障後，集羣整體是否還能響應客戶端的讀寫請求（對數據更新具有高可用性）
3，分區容錯性（p） 形成腦裂問題：
以實際效果而言，分區相當於對通信的時限要求，系統如果不能再時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
4，總結下
以上可以知道分區容錯性（P）主要代表網絡波動產生的錯誤，這是不可以避免的，且這三個模式不可以兼得，所以目前就2種模式: cp和Ap模式。
其中cp表示遵循一致性的原則，但不能保證高可用性，其中zookeeper作爲註冊中心就是採用cp模式，因爲zookeeper有過半節點不可以的話整個zookeeper將不可用。
AP表示遵循於可用性原則，例如Eureka作爲註冊中心用的是AP模式，因爲其爲去中心化，採用你中有我我中有你的相互註冊方式，只要集羣中有一個節點可以使用，整個eureka服務就是可用的，但可能會出現短暫的數據不一致問題。
Ap保證可用性：但是不能保證每個副本數據數據一致性，
cp保證數據一致性；如果有過半的zk節點宕機的情況下，不能保證可用性，但是必須保證每個副本節點之間數據一致性，比如zk。
Base理論：
Base是 Basically Available(基本可用)，Softstate(軟狀態)和Eventually consistent(最終一致性)三個短語的縮寫。Base理論是對CAP定理逐步演化而來的，base理論核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式達到最終一致性。
1基本可用性；
基本可用是指分佈式系統在出現不可預知故障的時候，允許損失部分可用性，注意：這絕不等於系統不可用。
比如： 響應時間的損失，正常情況下，在一個電子商務網站上進行購物的時候，消費者幾乎能順利完成每一筆訂單，但是在一些介入大促銷購物高峯的時候，由於消費者的購物行爲激增，爲了保護購物系統的穩定性，部分消費者可能被引導在一個降級頁面。
2，軟狀態。
軟狀態指允許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的整體可用性，既允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。
3，最終一致性
最終一致性強調的是所有的數據副本，在經過一段時間的同步之後，最終都能夠達到一個一致的狀態，因此，最終一致性的本質需要系統保證數據能夠達成一致，而不需要時時保證系統數據的強一致性。
2pc 與3pC
通過2pc和3pc 思想可以實現保證每個節點的數據一致性問題。
目前主流分佈式解決框架
1，單體項目多數據源，可以jta+Atomilos；
2，基於Rabbitmq的形式解決 最終一致性思想；
3，基於Rocketmq解決分佈式事務 ，採用事務消息。
4，lcn採用lcn模式，假關閉連接
5，Alibaba的seata 背景強大，已經成爲了主流。
以上適合於微服務架構中，不適合於和外部接口保證分佈式事務問題。
6，跨語言的方式實現解決分佈式事務問題。類似於支付寶回調方式。
2階段提交協議基本概念。
2階段提交協議基本概念：
倆階段提交協議可以理解爲2pc，也就是分爲參與者和協調者，協調者會通過2次階段實現數據最終一致性的
2pc和3pc 的區別就是解決參與者超時問題和多加了一層詢問。保證了數據傳輸的可靠性。
簡單的回顧下lcn解決分佈式事務。
http://www.txlcn.org/zh-cn/ LCN並不生產事務，LCN只是本地事務的協調工
現在官網已經不維護呢，可以參考：GitEE
https://gitee.com/wangliang1991/tx-lcn?_from=gitee_search
默認密碼爲：codingapi
lcn基本實現的原理：
1，發起方與參與方都與我們的lcn保持長連接；
2，發起方調用接口前，先向lcn管理器中申請一個全局的事務分組id;
3,發起方調用接口的時候在請求頭裏傳遞事務分組id.
4,參與方獲取到請求頭中有事務分組的id的，則當前業務邏輯執行完實現假關閉，不會提交或者回滾當前事務，
5，發起方調用完接口後，如果出現異常的情況下，在通知事務協調者回滾事務，這時候事務協調則告訴給參與者回滾當前的事務。
lcn 解決分佈式事務的原理：
角色劃分
1，全局事務協調者（組長）；
2，發起方---調用接口者；
3，參與方---被別人調用接口
訂單（發起方）調用派單（參與方）
1.發起方和參與方都會與我們的全局事務協調者保持長連接；
- 訂單（發起方）連接到我們全局事務協調者，先生成一個事務全局的分組id
- 當我們發起方調用接口的時候，會再請求頭中設置該事務全局分組id；
- 參與方從請求頭中獲取到該全局分組id，這是我們的數據源就不會提交。
- 發起方調用參與方接口完畢之後，如果報錯或者沒有問題的情況下，都會發送
一個通知給事務協調者，通知給其他的參與方到底是回滾還是提交。
LCN實現分佈式事務方案：有可能會引發行鎖問題。
整合和源碼解讀