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