1，分佈式事務產生的背景。
分情況而定
1， 在單體的項目中，多個不同的業務邏輯都是在同一個數據源中實現事務管理，是不存在分佈式事務的問題，因爲同一個數據源的情況都是採用事務管理器，相當於每個事務管理器對應一個數據源。
[圖片上傳失敗...(image-810669-1618491127348)]
2，在單體的項目中，有多個不同的數據源，每個數據源都有自己獨立的事務管理器，互不影響，那麼這時候也會存在多數據源事務管理： 解決方案 jta+Atomikos
[圖片上傳失敗...(image-7df061-1618491220423)]
3，在分佈式/微服務架構中，每個服務都有自己的本地事務，每個服務本地事務互不影響，那麼這時候也會存在分佈式事務的問題。
事務的定義：
對我們的業務邏輯可以實現提交或者回滾，保證數據的一致性的情況。
所以要麼提交，要麼回滾
原子性a 要麼提交 要麼回滾
一致性c
隔離性i 多個事務在一起執行的時候，互不影響；
持久性d 事務一旦提交或者回滾後，不會在對該結果有任何影響
2，傳統分佈式事務解決方案
3，2PC/3PC協議使用場景。
4，LCN爲什麼不更新了？那些思想值得學習、
5，分佈式事務解決方案有哪些？
6，強一致性/最終一致性區別。
7，LCn深度源碼解讀。
CAP理論
1 CAP定律和BASE理論
1.1 CAP定律#
這個定理的內容是指的是在一個分佈式系統中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。
（一）一致性（C）
在分佈式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
（二）可用性（A）
在集羣中一部分節點故障後，集羣整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
（三）分區容錯性（P） 形成腦裂問題
以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
https://baike.baidu.com/item/%E5%AE%B9%E9%94%99%E7%8E%87/9967698?fr=aladdin
（四）總結一下
以上可以知道分區容錯性（P）主要代表網絡波動產生的錯誤，這是不可避免的，且這個三個模式不可兼得，所以目前就只有兩種模式：CP和AP模式。
其中CP表示遵循一致性原則，但不能保證高可用性，其中zookeeper作爲註冊中心就是採用CP模式，因爲zookeeper有過半節點不可以的話整個zookeeper將不可用。
AP表示遵循於可用性原則，例如Eureka作爲註冊中心用的是AP模式，因爲其爲去中心化，採用你中有我我中有你的相互註冊方式，只要集羣中有一個節點可以使用，整個eureka服務就是可用的，但可能會出現短暫的數據不一致問題。
AP保證可用性：但是不能保證每個副本數據數據一致性；
CP保證數據一致性：如果有過半的zk節點宕機的情況下，不能保證可用性，但是必須保證每個副本節點之間數據一致性， 比如ZK；
Base理論
BASE是Basically Available（基本可用）、Soft state（軟狀態）和 Eventually consistent（最終一致性）三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的總結， 是基於CAP定理逐步演化而來的。BASE理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。
（一）基本可用
基本可用是指分佈式系統在出現不可預知故障的時候，允許損失部分可用性，注意，這絕不等價於系統不可用。
比如：響應時間上的損失。正常情況下，一個在線搜索引擎需要在0.5秒之內返回給用戶相應的查詢結果，但由於出現故障，查詢結果的響應時間增加了1~2秒。
系統功能上的損失：正常情況下，在一個電子商務網站上進行購物的時候，消費者幾乎能夠順利完成每一筆訂單，但是在一些節日大促購物高峯的時候，由於消費者的購物行爲激增，爲了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。
（二）軟狀態
軟狀態指允許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。
（三）最終一致性
最終一致性強調的是所有的數據副本，在經過一段時間的同步之後，最終都能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
目前主流分佈式解決框架：
1，單體項目多數據源，可以jta+Atomikos
2,基於RabbitMQ的形式解決，最終一致性的思想。
3，基於RocketMQ解決分佈式事務，採用事務消息。
4，LCn採用lcn模式，假關閉連接
5,Alibaba的Seata
6，跨語言的方式實現解決分佈式事務問題，類似於支付寶回調。
倆階段提交協議基本概念：
2階段提交協議可以理解爲2pc，也就是分爲參與者和協調者，協調者會通過2次階段實現數據最終一致性。
2pc和3pc的區別就是解決參與者超時的問題和多加了一層詢問，保證數據的傳輸可靠性。
簡單的回顧一下LCN解決分佈式事務
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實現分佈式事務方案：有可能會引發行鎖問題
整合和源碼解讀。
SpringBoot整合lcn5.0
Maven依賴
<dependency>
<groupId>com.codingapi.txlcn</groupId>
<artifactId>txlcn-tc</artifactId>
<version>5.0.2.RELEASE</version>
</dependency>
<dependency>
<groupId>com.codingapi.txlcn</groupId>
<artifactId>txlcn-txmsg-netty</artifactId>
<version>5.0.2.RELEASE</version>
</dependency>
相關配置
tx-lcn:
client:
manager-address: 127.0.0.1:8070
logger:
enabled: true
參與方獲取全局id
1.SpringTracingApplier
攔截器 獲取feign客戶端請求頭中的參數全局事務分組id，緩存到threadlocal中。
- Aop的重寫的入口TransactionAspect
- 事務不會提交 暫時假關閉。
- DataSourceAspect##LcnConnectionProxy
基於代理數據源的形式 直接重寫了原生的了sql連接 註釋掉 commit方法