事務概念

事務特性(ACID)

原子性（A）

所謂的原子性就是說，在整個事務中的所有操作，要么全部完成，要么全部不做，沒有中間狀態。對于事務在執行中發生錯誤，所有的操作都會被回滾，整個事務就像從沒被執行過一樣。

一致性（C）

事務的執行必須保證系統的一致性，就拿轉賬為例，A有500元，B有300元，如果在一個事務里A成功轉給B50元，那么不管并發多少，不管發生什么，只要事務執行成功了，那么最后A賬戶一定是450元，B賬戶一定是350元。

隔離性（I）

所謂的隔離性就是說，事務與事務之間不會互相影響，一個事務的中間狀態不會被其他事務感知。

持久性（D）

所謂的持久性，就是說一單事務完成了，那么事務對數據所做的變更就完全保存在了數據庫中，即使發生停電，系統宕機也是如此。

這種特性 簡稱 剛性事物

分布式事務

分布式事務產生原因

分布式事物產生的原因

分布式事務產生的場景

在分布式系統，都會垂直拆分數據庫，分為支付數據庫、訂單數據庫、積分數據庫、優惠全數據庫等，業務組成，分為多個數據源，會產生分布式事物問題。

spring事務和分布式事務的區別是什么?
spring事務，本地事務
分布式事務是跨服務間的通訊（不同的數據庫連接）

分布式理論知識

CPA理論

CAP由Eric Brewer在2000年PODC會議上提出[1][2]，是Eric Brewer在Inktomi[3]期間研發搜索引擎、分布式web緩存時得出的關于數據一致性(consistency)、服務可用性(availability)、分區容錯性(partition-tolerance)的猜想：

? 數據一致性(consistency)：如果系統對一個寫操作返回成功，那么之后的讀請求都必須讀到這個新數據；如果返回失敗，那么所有讀操作都不能讀到這個數據，對調用者而言數據具有強一致性(strong consistency) (又叫原子性 atomic、線性一致性 linearizable consistency)[5]

? 服務可用性(availability)：所有讀寫請求在一定時間內得到響應，可終止、不會一直等待

? 分區容錯性(partition-tolerance)：在網絡分區的情況下，被分隔的節點仍能正常對外服務

Base理論

BASE理論是指，Basically Available（基本可用）、Soft-state（ 軟狀態/柔性事務）、Eventual Consistency（最終一致性）。是基于CAP定理演化而來，是對CAP中一致性和可用性權衡的結果。核心思想：即使無法做到強一致性，但每個業務根據自身的特點，采用適當的方式來使系統達到最終一致性。

1、基本可用：指分布式系統在出現故障的時候，允許損失部分可用性，保證核心可用。但不等價于不可用。比如：搜索引擎0.5秒返回查詢結果，但由于故障，2秒響應查詢結果；網頁訪問過大時，部分用戶提供降級服務，等。

2、軟狀態：軟狀態是指允許系統存在中間狀態，并且該中間狀態不會影響系統整體可用性。即允許系統在不同節點間副本同步的時候存在延時。

3、最終一致性：

系統中的所有數據副本經過一定時間后，最終能夠達到一致的狀態，不需要實時保證系統數據的強一致性。最終一致性是弱一致性的一種特殊情況。BASE理論面向的是大型高可用可擴展的分布式系統，通過犧牲強一致性來獲得可用性。ACID是傳統數據庫常用的概念設計，追求強一致性模型。

ACID，指數據庫事務正確執行的四個基本要素的縮寫。包含：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。

柔性事務和剛性事務

柔性事務滿足BASE理論（基本可用，最終一致）

剛性事務滿足ACID理論

本文主要圍繞分布式事務當中的柔性事務的處理方式進行討論。

柔性事務分為

兩階段型

補償型

異步確保型

最大努力通知型幾種。 由于支付寶整個架構是SOA架構，因此傳統單機環境下數據庫的ACID事務滿足了分布式環境下的業務需要，以上幾種事務類似就是針對分布式環境下業務需要設定的。

什么是XA接口

XA是一個分布式事務協議，由Tuxedo提出。XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由數據庫實現，比如Oracle、DB2這些商業數據庫都實現了XA接口，而事務管理器作為全局的調度者，負責各個本地資源的提交和回滾。XA實現分布式事務的原理如下：

什么是Jta

作為java平臺上事務規范JTA（Java Transaction API）也定義了對XA事務的支持，實際上，JTA是基于XA架構上建模的，在JTA 中，事務管理器抽象為javax.transaction.TransactionManager接口，并通過底層事務服務（即JTS）實現。像很多其他的java規范一樣，JTA僅僅定義了接口，具體的實現則是由供應商(如J2EE廠商)負責提供，目前JTA的實現主要由以下幾種：

1.J2EE容器所提供的JTA實現(JBoss)
2.獨立的JTA實現:如JOTM，Atomikos.這些實現可以應用在那些不使用J2EE應用服務器的環境里用以提供分布事事務保證。如Tomcat,Jetty以及普通的java應用。

基于XA協議的兩階段（2PC）提交

所謂的兩個階段是指：第一階段：準備階段(投票階段)和第二階段：提交階段（執行階段）。

XA一般由兩階段完成，稱為two-phase commit(2PC)。

階段一為準備階段，即所有的參與者準備執行事務并鎖住需要的資源。參與者ready時，向transaction manager匯報自己已經準備好。

階段二為提交階段。當transaction manager確認所有參與者都ready后，向所有參與者發送commit命令。

如下圖所示：

XA的性能問題

XA的性能很低。一個數據庫的事務和多個數據庫間的XA事務性能對比可發現，性能差10倍左右。因此要盡量避免XA事務，例如可以將數據寫入本地，用高性能的消息系統分發數據。或使用數據庫復制等技術。

只有在這些都無法實現，且性能不是瓶頸時才應該使用XA。

分布式事物解決方案

分布式事物問題，在互聯網公司比較常見，例如“”分布式事物解決方案 可以使用全局事物2pc（兩段提交協議）、3pc(三段提交協議)，消息中間件、tcc、gts、提供回滾接口、分布式數據庫

2PC和3PC區別：https://blog.csdn.net/secretx/article/details/53322989
LCN 核心采用3PC+TCC補償機制

使用LCN框架解決分布式事務

什么是LCN框架

LCN分布式事務框架v4.0 https://www.txlcn.org
"LCN并不生產事務，LCN只是本地事務的搬運工"

框架特點

兼容SpringCloud、Dubbo

使用簡單，低依賴，代碼完全開源

基于切面的強一致性事務框架

高可用，模塊可以依賴Dubbo或SpringCloud的集群方式做集群化，TxManager也可以做集群化

支持本地事務和分布式事務共存

事務補償機制，服務故障或掛機再啟動時可恢復事務

LCN框架原理

參考網站 https://github.com/codingapi/tx-lcn/wiki/LCN%E5%8E%9F%E7%90%86

lcn框架原理

?

核心步驟

創建事務組 是指在事務發起方開始執行業務代碼之前先調用TxManager創建事務組對象，然后拿到事務標示GroupId的過程。

添加事務組 添加事務組是指參與方在執行完業務方法以后，將該模塊的事務信息添加通知給TxManager的操作。

關閉事務組 是指在發起方執行完業務代碼以后，將發起方執行結果狀態通知給TxManager的動作。當執行完關閉事務組的方法以后，TxManager將根據事務組信息來通知相應的參與模塊提交或回滾事務。

總結

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

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