Java中的事務——全局事務與本地事務
在上一篇文章中說到過，Java事務的類型有三種：JDBC事務、JTA(Java Transaction API)事務、容器事務。這是從事務的實現(xiàn)角度區(qū)分的，本文從另外一個角度來再次區(qū)分一下Java中的事務。
站在事務管理的角度，可以把Java中用到的事務分為本地事務和全局事務。
本地事務
不用事務的編程框架來管理事務，直接使用資源管理器來控制事務。典型的就是java.sql.Connection 中的 setAutoCommit、commit、rollback方法。
本地事務的優(yōu)點
- 支持嚴格的ACID屬性
- 可靠
- 高效
- 狀態(tài)可以只在資源管理器中維護
- 應用編程模型簡單
本地事務的局限
- 不具備分布式事務處理能力
- 隔離的最小單位由資源管理器決定，如數(shù)據(jù)庫中的一條記錄
本地事務比較簡單，對事務不太了解的同學可以閱讀我的博客中其他關(guān)于事務的內(nèi)容。
全局事務
前面我們介紹了本地事務，本地事務是我們在編程中比較常接觸的事務，比如典型的jdbc操作，在保證ACID方面做的非常出色。但是本地事務無法解決分布式場景中的事務問題。
我前面的文章中專門介紹過分布式場景中為什么需要事務。這里我再稍微回顧一下。
典型的分布式事務場景
- 轉(zhuǎn)賬
對于銀行賬戶間轉(zhuǎn)賬的問題。賬戶A向賬戶B轉(zhuǎn)賬，從實現(xiàn)上來看，一般可以拆分為“從賬戶A中扣錢”、“向賬戶B中加錢”兩個操作步驟，兩個賬戶大多數(shù)情況下會被切分到不同的數(shù)據(jù)庫上，更多的是，兩個操作會是兩次服務調(diào)用。這兩個操作要求做到要么同時成功、要么同時失敗。因此引入了分布式事務問題。
- 下單
在電商網(wǎng)站上，在消費者點擊購買按鈕后，交易后臺會進行庫存檢查、下單、減庫存、更新訂單狀態(tài)等一連串的服務調(diào)用，每一個操作對應一個獨立的服務，服務一般會有獨立的數(shù)據(jù)庫，因此會產(chǎn)生分布式事務問題。
由于用一次操作，數(shù)據(jù)要寫入的數(shù)據(jù)庫不一致，或者調(diào)用的服務都是RPC服務，那么就會無法保證操作在同一個事務中被處理掉。所以就會存在分布式的事務問題。
全局事務的定義
在上面的場景中會出現(xiàn)分布式事務問題，那么全局事務就是一個標準的分布式事務。下面我們嘗試著給全局事務下一個定義：
全局事務是由資源管理器管理和協(xié)調(diào)的事務。
全局事務是一個DTP模型的事務，所謂DTP模型指的是X/Open DTP(X/Open Distributed Transaction Processing Reference Model)，是X/Open 這個組織定義的一套分布式事務的標準，也就是了定義了規(guī)范和API接口，由這個廠商進行具體的實現(xiàn)。
X/Open DTP 定義了三個組件：AP，TM，RM 和兩個協(xié)議：XA、TX
AP(Application Program)：也就是應用程序，可以理解為使用DTP的程序
RM(Resource Manager)：資源管理器，這里可以理解為一個DBMS系統(tǒng)，或者消息服務器管理系統(tǒng)，應用程序通過資源管理器對資源進行控制。
TM(Transaction Manager)：事務管理器，負責協(xié)調(diào)和管理事務，提供給AP應用程序編程接口以及管理資源管理器。
XA協(xié)議：應用或應用服務器與事務管理之前通信的接口
TX協(xié)議：全局事務管理器與資源管理器之間通信的接口
事務管理器控制著全局事務，管理事務生命周期，并協(xié)調(diào)資源。資源管理器負責控制和管理實際資源。
這里還要提到一個點，就是2PC(兩階段提交)，在全局事務中，為了保證所有的操作可以一次性要么全提交，要么全失敗。事務管理器和資源管理器之間的事務操作的控制是采用2PC來進行的，關(guān)于2PC，我博客中有文章專門介紹，這里不再贅述。
J2EE中全局事務的實現(xiàn)
Java自身提供了一些API可以用來實現(xiàn)全局事務。Java中的事務——JDBC事務和JTA事務中介紹的JTA事務就可以用來實現(xiàn)J2EE中的全局事務。
JTA(Java Transaction API):面向應用、應用服務器與資 源管理器的高層事務接口。
JTS(Java Transaction Service):JTA事務管理器的實現(xiàn)標 準,向上支持JTA,向下通過CORBA OTS實現(xiàn)跨事務域的互 操作性。
EJB:基于組件的應用編程模型,通過聲明式事務管理進一步 簡化事務應用的編程。
全局事務的優(yōu)缺點
全局事務，作為一種標準的分布式事務解決方案，他解決了本地事務無法滿足分布式場景中數(shù)據(jù)的ACID的要求。
在關(guān)于分布式事務、兩階段提交協(xié)議、三階提交協(xié)議中我曾經(jīng)介紹過，2PC本身是存在同步阻塞問題，這就會導致效率變低，所以，采用2PC進行事務控制的全局事務也必然存在效率低的問題。這也是全局事務最致命的缺點，在提倡微服務的今天，這是不能容忍的。
總結(jié)
本文主要介紹了本地事務和全局事務，本地事務很簡單，在Java中可以使用JDBC來實現(xiàn)本地事務，全局事務是一種基本的分布式事務解決方案，是符合DTP模型的事務管理機制。
目前，越來越多的web開發(fā)要涉及到分布式事務，尤其是微服務架構(gòu)最近越來越火，在微服務架構(gòu)中，分布式事務是必然存在的。對于分布式事務的處理，本文主要介紹了一個典型的方案——全局事務。但是實際上，低效率的全局事務并不是很適合用來解決大型網(wǎng)站的分布式事務問題。
在業(yè)內(nèi)，主要用來解決分布式事務的方案是使用柔性事務。柔性事務包括幾種類型：兩階段型、補償型、異步確保型和***努力通知型。后面我會有文章繼續(xù)介紹柔性事務。請繼續(xù)關(guān)注。
【本文是51CTO專欄作者Hollis的原創(chuàng)文章，作者微信公眾號Hollis(ID：hollischuang)】
