這篇文章主要講解了“LCN分布式事務框架是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“LCN分布式事務框架是什么”吧！

今天無意中發(fā)現了一款分布式事務框架，LCN,看了下網上介紹感覺挺強大的。這里做一下筆記。

一、環(huán)境基礎

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

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

• 事務發(fā)起方服務

• TxManager事務管理器

• 事務下游服務（可能有多個）

三、原理

TxManager是基于本地事務的，這里有一個事務組的概念，事務組是所有涉及的微服務的本地事務的集合。

它主要原理是對通過重寫dataSource的close方法，本身的close方法是需要關閉本地事務的，但是重寫后并沒有關閉事務，而是把事務信息記錄在txmanager的redis中，等待事務發(fā)起方服務業(yè)務執(zhí)行完成或異常的時候再發(fā)通知給各個服務通知本地事務提交或回滾的。在代理連接池中，并不是都不真實提交事務，它可以自動識別連接的讀或寫操作，如果全是讀操作，那么將返回本地連接對象。如果該方法被重復執(zhí)行，連接也可以被重用，同時也有超時限制，參與模塊等待通知超時會自動提交或者回滾（這里具體不清楚到底是提交還是回滾，暫時存疑，不過看后面的補償機制說明，好像是自動提交？）

TxManager類似于二階段提交，只不過二階段提交的事務發(fā)起方和事務管理器在同一臺機器，而TxManager是作為獨立的中間件。

四、事務補償

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

首先看一看TxManager后臺頁面：

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

五、小結

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代碼下來看，看了使用方法，環(huán)境搭好以后只需要在事務發(fā)起方法里使用@TxTransaction(isStart = true)注解，然后在下游服務方法中使用@TxTransaction就行了，使用方法很簡單，代碼侵入很低，值得推薦。

另外，提一點，對于消息隊列異步調用的形式，這款框架并不能滿足事務一致性，需要結合其他方案。

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

總結

以上是生活随笔為你收集整理的LCN分布式事务框架是什么的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。