初識LCN分佈式事務框架

今天無心中發現了一款分佈式事務框架，LCN,看了下網上介紹感受挺強大的。這裏作一下筆記。

1、環境基礎

LCN框架基礎須要一臺服務器做爲事務管理器TxManager，此外還須要Redis和Eureka作配合，eureka負責爲TxManager註冊，redis主要是用於TxManager存放事務組和補償的信息。

2、一個事務所涉及的角色

• 事務發起方服務
• TxManager事務管理器
• 事務下游服務（可能有多個）

3、原理

TxManager是基於本地事務的，這裏有一個事務組的概念，事務組是全部涉及的微服務的本地事務的集合。

它主要原理是對經過重寫dataSource的close方法，自己的close方法是須要關閉本地事務的，可是重寫後並無關閉事務，而是把事務信息記錄在txmanager的redis中，等待事務發起方服務業務執行完成或異常的時候再發通知給各個服務通知本地事務提交或回滾的。在代理鏈接池中，並非都不真實提交事務，它能夠自動識別鏈接的讀或寫操做，若是全是讀操做，那麼將返回本地鏈接對象。若是該方法被重複執行，鏈接也能夠被重用，同時也有超時限制，參與模塊等待通知超時會自動提交或者回滾（這裏具體不清楚究竟是提交仍是回滾，暫時存疑，不過看後面的補償機制說明，好像是自動提交？）

TxManager相似於二階段提交，只不過二階段提交的事務發起方和事務管理器在同一臺機器，而TxManager是做爲獨立的中間件。

4、事務補償

事務補償指的是當事務發起方服務異常或正常執行的時候發送事務組關閉的請求到TxManager，讓TxManager通知下游服務回滾或提交事務，二階段模型中這一步沒有解決結束事務操做可否正確提交到資源管理端的問題，在LUA中提供了一種自動補償機制。

首先看一看TxManager後臺頁面：

這裏，有兩項值得注意，第一項是補償回調地址，這正是在TxManager發送通知下游服務回滾或提交事務失敗的時候回調事務信息給事務發起方服務的回調地址 第二項是是否開啓自動補償。 不開啓補償的話，TxManager仍是會回調。 自動補償是怎麼實現的勒？首先TxManager回調事務發起方服務（攜帶了事務信息，切面攔截信息），那麼事務發起方在回調方法中就寫一個重複業務的操做，這個操做中仍是會模擬上次的請求。可是針對已經上次通知成功commit的服務，此次就須要回滾了，只有通知失敗的服務須要commit。

5、小結

git地址：https://github.com/syzpig/tx-lcn

demo地址：https://github.com/codingapi/springcloud-lcn-demo

官方文檔地址：https://txlcn.org/zh-cn/docs/preface.html

Lcn支持springcloud和dubbo。拉了springcloud的demo代碼下來看，看了使用方法，環境搭好之後只須要在事務發起方法裏使用@TxTransaction(isStart = true)註解，而後在下游服務方法中使用@TxTransaction就好了，使用方法很簡單，代碼侵入很低，值得推薦。

另外，提一點，對於消息隊列異步調用的形式，這款框架並不能知足事務一致性，須要結合其餘方案。

在最新版本的Lcn中發現也支持TCC和TXC模式~~~~~~~~