事務的四個特性 (ACID) ，分別是原子性（ Atomicity), 一致性（ Consistency), 隔離性（ Isolation), 持久性（ Durability)。一致性是事務的目的，原子性，隔離性，持久性是一致性的必要條件。
隔離性：多個併發事務之間要相互隔離，對於兩個併發的事務T1和T2，T1和T2的開始有先後順序，這樣每個事務都感覺不到有其他事務在併發地執行。
隔離級別有四種：
1、串行Serializable ：最嚴格的級別，事務串行執行，資源消耗最大。
2、可重複讀REPEATABLE READ ：保證了事務T1不會修改事務T2未提交的數據。避免了“髒讀取”和“不可重複讀取”的情況，但是帶來了更多的性能損失。
3、讀取已提交READ COMMITTED ：保證了事務T1不會讀到事務T2未提交的數據，避免了“髒讀取”。
4、讀取未提交Read Uncommitted ：讀取過程中會讀取到非法數據。
髒讀、幻讀、不可重複讀的區別：
髒讀是T1讀取了T2未提交的數據。
不可重複讀則是讀取了前一事務提交的數據，在某些情況下，不可重複讀並不是問題，以最終查詢的結果爲準。
不可重複讀查詢的都是同一個數據項，而幻讀針對的是一批數據整體（比如數據的個數）。
四種隔離級別與讀取事務和寫事務：
讀取未提交，讀不會阻塞任何事務，寫只阻塞寫，會導致讀出現髒讀、不可重複讀、幻影讀。
讀取已提交，讀不會阻塞任何事務，寫阻塞讀、寫，因爲寫阻塞讀，排除“髒讀” 問題，但是讀還是不阻塞寫，不可重複讀、幻影讀會出現。
可重複讀，讀只阻塞寫，寫阻塞讀、寫，讀阻塞寫避免了“不可重複讀”的問題，但是讀事務並沒有阻塞對數據庫的插入操作，所以此 時“幻影讀”問題照樣存在。
Serializable 數據庫系統會保證執行此種隔離級別事務的效果和順序執行的效果一致。
默認的隔離級別：
MySQL：可重複讀。
Oracle：只支持串行化和讀已提交這兩種級別，默認：讀已提交。
併發控制：
在每個讀的數據行上加上共享鎖
此時我們一般採用READ COMMITTED的隔離級別，然後再結合以下幾種併發控制的鎖定策略：
* 樂觀所 版本號重試
* 悲觀鎖 for update
* 樂觀離線鎖
* 悲觀離線鎖
事務常用的兩個屬性：readonly和timeout，設置事務的超時時間，防止大事務的發生。
事務模型解析
平面事務模型：本地事務和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 ），java 又提供了操作JTS 的上層接口 JTA （Java Transaction API ）
全局事務是涉及多個資源管理器，此時需要引入事務協調者(可以理解爲全局事務管理器，可基於可靠消息實現)來進行調節
通信協議：
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 最終一致性；