您好,登錄后才能下訂單哦!
這篇文章主要講解了“LCN分布式事務框架是什么”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“LCN分布式事務框架是什么”吧!
今天無意中發現了一款分布式事務框架,LCN,看了下網上介紹感覺挺強大的。這里做一下筆記。
LCN框架基礎需要一臺服務器作為事務管理器TxManager,此外還需要Redis和Eureka做配合,eureka負責為TxManager注冊,redis主要是用于TxManager存放事務組和補償的信息。
事務發起方服務
TxManager事務管理器
事務下游服務(可能有多個)
TxManager是基于本地事務的,這里有一個事務組的概念,事務組是所有涉及的微服務的本地事務的集合。
它主要原理是對通過重寫dataSource的close方法,本身的close方法是需要關閉本地事務的,但是重寫后并沒有關閉事務,而是把事務信息記錄在txmanager的redis中,等待事務發起方服務業務執行完成或異常的時候再發通知給各個服務通知本地事務提交或回滾的。在代理連接池中,并不是都不真實提交事務,它可以自動識別連接的讀或寫操作,如果全是讀操作,那么將返回本地連接對象。如果該方法被重復執行,連接也可以被重用,同時也有超時限制,參與模塊等待通知超時會自動提交或者回滾(這里具體不清楚到底是提交還是回滾,暫時存疑,不過看后面的補償機制說明,好像是自動提交?)
TxManager類似于二階段提交,只不過二階段提交的事務發起方和事務管理器在同一臺機器,而TxManager是作為獨立的中間件。
事務補償指的是當事務發起方服務異常或正常執行的時候發送事務組關閉的請求到TxManager,讓TxManager通知下游服務回滾或提交事務,二階段模型中這一步沒有解決結束事務操作能否正確提交到資源管理端的問題,在LCN中提供了一種自動補償機制。
首先看一看TxManager后臺頁面:
這里,有兩項值得注意,第一項是補償回調地址,這正是在TxManager發送通知下游服務回滾或提交事務失敗的時候回調事務信息給事務發起方服務的回調地址 第二項是是否開啟自動補償。 不開啟補償的話,TxManager還是會回調。 自動補償是怎么實現的勒?首先TxManager回調事務發起方服務(攜帶了事務信息,切面攔截信息),那么事務發起方在回調方法中就寫一個重復業務的操作,這個操作中還是會模擬上次的請求。但是針對已經上次通知成功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代碼下來看,看了使用方法,環境搭好以后只需要在事務發起方法里使用@TxTransaction(isStart = true)注解,然后在下游服務方法中使用@TxTransaction就行了,使用方法很簡單,代碼侵入很低,值得推薦。
另外,提一點,對于消息隊列異步調用的形式,這款框架并不能滿足事務一致性,需要結合其他方案。
在最新版本的Lcn中發現也支持TCC和TXC模式~~~~~~~~
感謝各位的閱讀,以上就是“LCN分布式事務框架是什么”的內容了,經過本文的學習后,相信大家對LCN分布式事務框架是什么這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。