數(shù)據(jù)庫事務(wù)

事務(wù)的四個特性 (ACID) ，分別是原子性（ Atomicity), 一致性（ Consistency), 隔離性（ Isolation), 持久性（ Durability)。一致性是事務(wù)的目的，原子性，隔離性，持久性是一致性的必要條件。

隔離性：多個并發(fā)事務(wù)之間要相互隔離，對于兩個并發(fā)的事務(wù)T1和T2，T1和T2的開始有先后順序，這樣每個事務(wù)都感覺不到有其他事務(wù)在并發(fā)地執(zhí)行。

隔離級別有四種：

1、串行Serializable ：最嚴(yán)格的級別，事務(wù)串行執(zhí)行，資源消耗最大。

2、可重復(fù)讀REPEATABLE READ ：保證了事務(wù)T1不會修改事務(wù)T2未提交的數(shù)據(jù)。避免了“臟讀取”和“不可重復(fù)讀取”的情況，但是帶來了更多的性能損失。

3、讀取已提交READ COMMITTED ：保證了事務(wù)T1不會讀到事務(wù)T2未提交的數(shù)據(jù)，避免了“臟讀取”。

4、讀取未提交Read Uncommitted ：讀取過程中會讀取到非法數(shù)據(jù)。

臟讀、幻讀、不可重復(fù)讀的區(qū)別：

臟讀是T1讀取了T2未提交的數(shù)據(jù)。

不可重復(fù)讀則是讀取了前一事務(wù)提交的數(shù)據(jù)，在某些情況下，不可重復(fù)讀并不是問題，以最終查詢的結(jié)果為準(zhǔn)。

不可重復(fù)讀查詢的都是同一個數(shù)據(jù)項，而幻讀針對的是一批數(shù)據(jù)整體（比如數(shù)據(jù)的個數(shù)）。

四種隔離級別與讀取事務(wù)和寫事務(wù)：

讀取未提交，讀不會阻塞任何事務(wù)，寫只阻塞寫，會導(dǎo)致讀出現(xiàn)臟讀、不可重復(fù)讀、幻影讀。

讀取已提交，讀不會阻塞任何事務(wù)，寫阻塞讀、寫，因為寫阻塞讀，排除“臟讀” 問題，但是讀還是不阻塞寫，不可重復(fù)讀、幻影讀會出現(xiàn)。

可重復(fù)讀，讀只阻塞寫，寫阻塞讀、寫，讀阻塞寫避免了“不可重復(fù)讀”的問題，但是讀事務(wù)并沒有阻塞對數(shù)據(jù)庫的插入操作，所以此 時“幻影讀”問題照樣存在。

Serializable 數(shù)據(jù)庫系統(tǒng)會保證執(zhí)行此種隔離級別事務(wù)的效果和順序執(zhí)行的效果一致。

默認(rèn)的隔離級別：

MySQL：可重復(fù)讀。

Oracle：只支持串行化和讀已提交這兩種級別，默認(rèn)：讀已提交。

并發(fā)控制：

在每個讀的數(shù)據(jù)行上加上共享鎖

此時我們一般采用READ COMMITTED的隔離級別，然后再結(jié)合以下幾種并發(fā)控制的鎖定策略：

* 樂觀所 版本號重試

* 悲觀鎖 for update

* 樂觀離線鎖

* 悲觀離線鎖

事務(wù)常用的兩個屬性：readonly和timeout，設(shè)置事務(wù)的超時時間，防止大事務(wù)的發(fā)生。

事務(wù)模型解析

平面事務(wù)模型：本地事務(wù)和JTA 事務(wù)。

事務(wù)管理涉及到的幾個參與者：

1 資源管理器（ Resource Manager) ：資源管理器一般是數(shù)據(jù)庫管理系統(tǒng)。

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

3 事務(wù)管理器 (Transaction manager) ：每一個事務(wù)管理器都與相應(yīng)的資源管理器所關(guān)聯(lián)，它負(fù)責(zé)對分布式事務(wù)進(jìn)行提交或者回滾。

4 應(yīng)用程序（ Application)

以上四者的關(guān)系可以用以下的圖形來形象的表述：

在日常的系統(tǒng)開發(fā)中，我們一般都會使用數(shù)據(jù)資源（比如數(shù)據(jù)庫）來對系統(tǒng)的狀態(tài)進(jìn)行保存，那么我們根據(jù)系統(tǒng)涉及的數(shù)據(jù)資源的多少，將事務(wù)分為RESOURCE-LOCAL事務(wù)或者JTA全局分布式事務(wù)。

1 RESOURCE-LOCAL事務(wù)

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

 此時事務(wù)協(xié)調(diào)著和事務(wù)管理器的作用就有底層的資源管理器來實現(xiàn)了。比如目前我們在采用Spring來管理事務(wù)的時候，其實spring并沒有事務(wù)功能，它僅僅是封裝了底層數(shù)據(jù)庫的事務(wù)操作而已。

2 全局事務(wù)或者JTA事務(wù)

國際上提出了一種分布式事務(wù)解決方案的標(biāo)準(zhǔn)OTS（Object Transaction Service），JavaEE 對OTS 做了實現(xiàn)，即JTS（Java Transaction Service ），java 又提供了操作JTS 的上層接口 JTA （Java Transaction API ）

全局事務(wù)是涉及多個資源管理器，此時需要引入事務(wù)協(xié)調(diào)者(可以理解為全局事務(wù)管理器，可基于可靠消息實現(xiàn))來進(jìn)行調(diào)節(jié)

通信協(xié)議：

1、應(yīng)用服務(wù)器與事務(wù)管理器通過TX協(xié)議通信。

2、事務(wù)管理器與資源管理器通過XA協(xié)議通信。

3、事務(wù)管理器之間通過XA+（XA協(xié)議超集）協(xié)議通信。

提交過程：

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

第一階段：事務(wù)協(xié)調(diào)者發(fā)送“準(zhǔn)備提交”消息給事務(wù)所涉及的所有的事務(wù)管理器，然后事務(wù)管理器又分送此消息給相應(yīng)的資源管理器，然后事務(wù)管理器又將資源管理的響應(yīng)情況告訴分布式事務(wù)協(xié)調(diào)著（DTC). 只有此階段順利完成后（既所有的資源管理器都同意提交事務(wù)），才會進(jìn)入第二階段。

第二階段：當(dāng)?shù)谝粋€階段順利完成后，事務(wù)協(xié)調(diào)者告訴事務(wù)管理器去提交事務(wù)

分布式最終一致性理論：

CAP理論：

C（一致性）在分布式環(huán)境下多個節(jié)點數(shù)據(jù)是否一致；

A（可用性）服務(wù)一直保持可用的狀態(tài)；

P（分區(qū)容忍性）在分布式應(yīng)用中，可能因為一些分布式的原因?qū)е孪到y(tǒng)無法運轉(zhuǎn)，好的分區(qū)容忍性，使應(yīng)用雖然是一個分布式系統(tǒng)，但是好像一個可以正常運轉(zhuǎn)的整體

BASE理論：

BA: Basic Availability 基本業(yè)務(wù)可用性；

S: Soft state 柔性狀態(tài)；

E: Eventual consistency 最終一致性；