Java中的事務——全域事務與本地事務

標籤：職業生涯   基於   基本原理   檢查   back   定義   text   獨立   閱讀   

在上一篇文章中說到過，Java事務的類型有三種：JDBC事務、JTA(Java Transaction API)事務、容器事務。

這是從事務的實現角度區分的，本文從另外一個角度來再次區分一下Java中的事務。站在交易管理的角度，可以把Java中用到的事務分為本地事務和全域事務。

本地事務

不用事務的編程架構來管理事務，直接使用資源管理員來控制事務。典型的就是java.sql.Connection 中的 setAutoCommit、commit、rollback方法。之前我們介紹的JDBC事務就是一個非常典型的本地事務。本地事務也是我們日常開發中最經常使用的事務。

本地事務的優點

支援嚴格的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系統，或者Message Service器管理系統，應用程式通過資源管理員對資源進行控制。

TM(Transaction Manager)：交易管理員，負責協調和管理事務，提供給APAPI以及管理資源管理員。

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開發要涉及到分散式交易，尤其是微服務架構最近越來越火，在微服務架構中，分散式交易是必然存在的。對於分散式交易的處理，本文主要介紹了一個典型的方案——全域事務。但是實際上，低效率的全域事務並不是很適合用來解決大型網站的分散式交易問題。

在業內，主要用來解決分散式交易的方案是使用柔性事務。柔性事務包括幾種類型：兩階段型、補償型、非同步確保型和最大努力通知型。後面我會有文章繼續介紹柔性事務

歡迎工作一到五年的Java程式員朋友們加入Java架構開發：744677563

本群提供免費的學習指導 架構資料 以及免費的解答

不懂得問題都可以在本群提出來 之後還會有職業生涯規劃以及面試指導

Java中的事務——全域事務與本地事務