LCN分散式事務框架原理詳解4.0
目錄
一、首先介紹3.0與4.0之前的差異
1.、地址：
2、4.0添加升級如下功能：
（1）3.0雖然有事務補償機制，但4.0在此基礎上不僅新增事務補償機制的策性，還添加了管理的後臺可以看到補償的資料；同時也添加了一個回撥地址，可以在補償之前可以最先知道這次補償的資料，也可以為我們的框架使用者提供一個決策權。
（2）同4.0時新增的外掛擴充套件機制，也就是說他更加開放了，他可以可以容納更多的rpc框架，也可以更多的支援db框架，比如mongodb、redis，還有將來一些框架，如ES等等。
二、LCN4.0原理
1、架構介紹
有圖可得，lcn是通過nginx作為負載均衡的轉發，也就是作為Txmanager的負載均衡的一個轉發伺服器；然後再是我們的TxManager,也就是事務管理器，然後事務管理器依賴兩個服務，一個是redis服務，一個是Eureka服務叢集；Eureka叢集是用於我們TxManager之間的相互服務發現。redis是用於存放我們事務組的資訊以及補償的資訊。然後模組A與模組B他們都需要去配置上我們TxClient的包架構（程式碼的包架構）；來支援我們的LCN框架,以及他們的資料庫。
2、核心步驟（LCN核心的三步驟）
首先講解下什麼是事務組：事務組是指的我們在整個事務過程中把各個節點（微服務）單元的事務資訊儲存在一個固定單元裡。但這個資訊並不是代表是事務資訊，而是隻是作為一個模組的標示資訊。
其次介紹事務發起者與參與者
如圖，在一次事務中發起的就叫做啟動者或者是發起方。然後其他的微服務框架都叫做事務的參與者。
- 建立事務組
是指在事務發起方程式碼開始執行業務之前先呼叫TxManager建立事務組物件，然後拿到事務標示GroupId的過程。（這裡的groupId表示的是一次事務的唯一標示，就是指我們一次事務中，會有一個groupId存在。其次這裡講述在開始執行業務之前，是因為框架是基於切面的思想，那麼切面就切面到了這個方法的業務執行過程中，然後又一個around切面。再然後在開始之前，在業務沒有呼叫業務之前會先呼叫TxManager去建立事務組，然後建立完事務組以後Txmanager會返回事務組資訊，事務組資訊中就包含GroupId這個引數，這也就是作為的建立事務組。建立完事務組之後就相當於已經產生一個事務組標示。作為一個串聯過程，識別為同一次事務的一個過程） - 新增事務組
新增事務組是指參與方在執行完業務方法以後，將該模組的事務資訊新增通知給TxManager的操作。 - 關閉事務組
是指在發起方執行完業務程式碼以後（執行到這個地方就表明沒有錯誤和異常，也就是執行結束了，否則並不會執行到這個地方），將發起方執行結果狀態通知給TxManager的動作。當執行完關閉事務組的方法以後，TxManager將根據事務組資訊來通知相應的參與模組提交或回滾事務。
3、事務協調機制
如圖：假設服務已經執行到關閉事務組的過程，那麼接下來作為一個模組執行通知給TxManager，然後告訴他本次事務已經完成。那麼如圖中Txmanager下一個動作就是通過事務組的id，然後獲取到本次事務組的事務資訊；然後檢視一下對應有那幾個模組參與，然後如果是有A/B/C三個模組；那麼對應的對三個模組做通知、提交、回滾。
那麼提交的時候是提交給誰呢？
是提交給了我們的TxClient模組。然後TxCliient模組下有一個連線池，就是框架自定義的一個連線池（如圖DB連線池）；這個連線池其實就是在沒有通知事務之前一直佔有著這次事務的連線資源，就是沒有釋放。但是他在切面裡面執行了close方法。在執行close的時候。如果需要（TxManager）分散式事務框架的連線。他被叫做“假關閉”,也就是沒有關閉，只是在執行了一次關閉方法。實際的資源是沒有釋放的。這個資源是掌握在LCN的連線池裡的。
然後當TxManager通知提交或事務回滾的時候呢？
TxManager會通知我們的TxClient端。然後TxClient會去執行相應的提交或回滾。提交或回滾之後再去關閉連線，然後在返回給DB連線池。這就只事務的協調機制。說白了就是代理DataSource的機制；相當於是攔截了一下連線池，控制了連線池的事務提交。
LCN事務控制原理是由事務模組TxClient下的代理連線池與TxManager的協調配合完成的事務協調控制。
TxClient的代理連線池實現了javax.sql.DataSource介面，並重寫了close方法，事務模組在提交關閉以後TxClient連線池將執行"假關閉"操作，等待TxManager協調完成事務以後在關閉連線。
對於代理連線池的優化
-
自動超時機制
任何通訊都有最大超時限制，參與模組在等待通知的狀態下也有最大超時限制，當超過時間限制以後事務模組將先確認事務狀態，然後再決定執行提交或者回滾操作，主要為了給最大資源佔用時間加上限制。 -
智慧識別建立不同的連線 對於只讀操作、非事務操作LCN將不開啟代理功能，返回本地連線物件，對於補償事務的啟動方將開啟回滾連線物件，執行完業務以後馬上回滾事務。
-
LCN連線重用機制 當模組在同一次事務下被重複執行時，連線資源會被重用，提高連線的使用率。
4、補償機制
為什麼需要事務補償？
事務補償是指在執行某個業務方法時，本應該執行成功的操作卻因為伺服器掛機或者網路抖動等問題導致事務沒有正常提交，此種場景就需要通過補償來完成事務，從而達到事務的一致性。
補償機制的觸發條件？
當執行關閉事務組步驟時，若發起方接受到失敗的狀態後將會把該次事務識別為待補償事務，然後發起方將該次事務資料非同步通知給TxManager。TxManager接受到補償事務以後先通知補償回調地址，然後再根據是否開啟自動補償事務狀態來補償或儲存該次切面事務資料。
補償事務機制？
LCN的補償事務原理是模擬上次失敗事務的請求，然後傳遞給TxClient模組然後再次執行該次請求事務。
簡單的說：lcn事務補償是在在服務掛機和網路抖動情況下；服務掛機是指在完成三個核心步驟的時候
尤其也只有最後一步關閉事務組時，讓我去執行關閉事務組的時候，比如本次事務是要提交的。txManager接收到提交的請求再去通知的時候發現通知不到了。
（通知不到也就兩種原因服務掛了和網路出問題）在這種情況下TxManager會做一個標示;然後返回給發起方。告訴他本次事務有存在沒有通知到的情況。
那麼如果是接收到這個資訊之後呢，發起方就會做一個標示，標示本次事務是需要補償事務的。這就是事務補償機制。
LCN是怎麼去實現事務補償呢？
首先他或根據發起方拿到的TxManager的標示之後，判斷是否需要做事務補償，不過需要，他會首先在本地去記錄一下日誌 ，然後再把本次切面的資訊，也就是發起方本次事務切面的資訊
以及事務組的id資訊提交給TxManager;然後TxManager接收到這次資料之後，他會查詢到本次事務組的整個資訊，獲取到本次事務組資訊之後呢，他會把這些資訊一塊儲存到redis下，也就是做為補償資料一塊存下來。
在存下來的時候，他會先執行一次叫做回撥介面的請求；這個回撥介面其實是指的是回撥給第三方服務的一個地址，也就是我們自己的服務地址。這裡是作為一次通知用的，我們來看下4.0的介面
當補償發生之後，TxManager記錄完資料以後會通知這個回撥介面地址如圖：
告訴你有補償資訊存在。這個地方我們就可以做一些通知，例如郵件、簡訊提醒功能，通知給相應的人員。讓他們知道現在我們的服務裡存在了補償，要及時處理。
當然你也可以開啟自動補償功能（如上圖），當開啟自動補償之後的話，當補償上傳上來他也會通知的上面補償回調介面，通知完之後，他會把本次事務去補償一下。他是如何執行的呢？上面說到的他會把切面的資訊上傳上來，他會把切面的資訊
上傳給發起方，傳遞給發起方以後讓發起方重複執行本次事務。但是有一個差異性的地方是在於，他在去做模組提交的時候呢，會根據歷史的提交資料（補償資料）做一個逆向的操作，也就是說，必須如下圖來說：
比如我們這三個模組demo1、demo2、demo3.那麼現在如果通知demo2通知成功，是在指沒有補償之前（也就是正常執行的事務狀態下）。在通知demo3失敗了。然後這一次作為補償通知給了發起方demo1，發起方呼叫TxManager，告訴他這一次需要補償
那麼TxManager下發資訊給demo1，demo1執行補償的時候呢，首先啟動方事務是要回滾的（異常的狀態下不會執行補償）；那麼demo2、demo3是否回滾取決於上次的事務請求。上面說demo2提交成功了，也就是說他要回滾，demo3失敗，他是要補償的，是要提交的。那麼怎
麼去實現這一點呢？還是跟以前一樣，就是說其實這次是與之前的執行事務流程是相同的；唯一不同的是在於執行關閉，就是在這次補償的事務過程中的關閉事務的時候。
TxManager會判斷歷史資料，然後在下發資料的時候，會根據歷史資料（補償資料）做差異性的通知，是判斷誰要需要提交，誰需要回滾。這就是補償機制的原理。然後早demo1發起方呼叫本次補償的時候（也就是重新發起這次呼叫的話）肯定是基於反向代理的方式實現的。
5、外掛機制
如圖：
想要接入其他rpc和資料庫框架可以參考如圖中模組，如果專案lcn事務想引入redis資料庫，直接引入上面tx-plugins-redis外掛程式碼即可或者仿照其他外掛。
擬場景演示模
若存在事務發起方、參與方A、參與方B。呼叫關係圖如下
那麼他們正常執行業務的時序圖為：
若參與方B出現異常，那麼他們的業務時序圖為：
若他們的呼叫關係是這樣的情況
此時發生參與方B出現異常時他們的時序圖為：
