事務模型解析

平面事務模型：本地事務和JTA 事務。

事務管理涉及到的幾個參與者：

1 資源管理器（ Resource Manager) ：資源管理器一般是數據庫管理系統。

2 分布式事務協調者（ Distributed Transaction Coordinator,DTC)：此功能一般是由我們所用的 JavaEE 應用服務器實現，比如 jboss,websphere,weblogic 等。這個角色只有在 JTA 事務中才會存在。

3 事務管理器 (Transaction manager) ：每一個事務管理器都與相應的資源管理器所關聯，它負責對分布式事務進行提交或者回滾。

4 應用程序（ Application)

以上四者的關系可以用以下的圖形來形象的表述：

在日常的系統開發中，我們一般都會使用數據資源（比如數據庫）來對系統的狀態進行保存，那麽我們根據系統涉及的數據資源的多少，將事務分為RESOURCE-LOCAL事務或者JTA全局分布式事務。

1 RESOURCE-LOCAL事務

RESOURCE-LOCAL事務是指只有一個資源管理（RM) 的事務，事務操作都是對同一個數據庫進行操作。

此時事務協調著和事務管理器的作用就有底層的資源管理器來實現了。比如目前我們在采用Spring來管理事務的時候，其實spring並沒有事務功能，它僅僅是封裝了底層數據庫的事務操作而已。

2 全局事務或者JTA事務

國際上提出了一種分布式事務解決方案的標準OTS （Object Transaction Service）,JavaEE 對OTS 做了實現，即JTS （Java Transaction Service ），

全局事務是涉及多個資源管理器，此時需要引入事務協調者(可以理解為全局事務管理器，可基於可靠消息實現)來進行調節

通信協議：

1、應用服務器與事務管理器通過TX協議通信。

2、事務管理器與資源管理器通過XA協議通信。

3、事務管理器之間通過XA+（XA協議超集）協議通信。

提交過程：

兩階段提交協議2PC（two phase commit)

第一階段：事務協調者發送“準備提交”消息給事務所涉及的所有的事務管理器，然後事務管理器又分送此消息給相應的資源管理器，然後事務管理器又將資源管理的響應情況告訴分布式事務協調著（DTC). 只有此階段順利完成後（既所有的資源管理器都同意提交事務），才會進入第二階段。

第二階段：當第一個階段順利完成後，事務協調者告訴事務管理器去提交事務

分布式最終一致性理論：

CAP

C（一致性）在分布式環境下多個節點數據是否一致；

A（可用性）服務一直保持可用的狀態；

P（分區容忍性）在分布式應用中，可能因為一些分布式的原因導致系統無法運轉，好的分區容忍性，使應用雖然是一個分布式系統，但是好像一個可以正常運轉的整體

BASE

BA: Basic Availability 基本業務可用性；

S: Soft state 柔性狀態；

E: Eventual consistency 最終一致性；

本文出自 “淺談技術” 博客，請務必保留此出處http://netpeak.blog.51cto.com/1135737/1939106

數據庫事務模型分析