建站
咨詢
售后
建站咨詢
新聞中心
事務的四個特性 (ACID) ，分別是原子性（ Atomicity), 一致性（ Consistency), 隔離性（ Isolation), 持久性（ Durability)。一致性是事務的目的，原子性，隔離性，持久性是一致性的必要條件。
十多年的碧江網(wǎng)站建設經驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。營銷型網(wǎng)站建設的優(yōu)勢是能夠根據(jù)用戶設備顯示端的尺寸不同，自動調整碧江建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)建站從事“碧江網(wǎng)站設計”,“碧江網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。
隔離性：多個并發(fā)事務之間要相互隔離，對于兩個并發(fā)的事務T1和T2，T1和T2的開始有先后順序，這樣每個事務都感覺不到有其他事務在并發(fā)地執(zhí)行。
隔離級別有四種：
1、串行Serializable ：最嚴格的級別，事務串行執(zhí)行，資源消耗最大。
2、可重復讀REPEATABLE READ ：保證了事務T1不會修改事務T2未提交的數(shù)據(jù)。避免了“臟讀取”和“不可重復讀取”的情況，但是帶來了更多的性能損失。
3、讀取已提交READ COMMITTED ：保證了事務T1不會讀到事務T2未提交的數(shù)據(jù)，避免了“臟讀取”。
4、讀取未提交Read Uncommitted ：讀取過程中會讀取到非法數(shù)據(jù)。
臟讀、幻讀、不可重復讀的區(qū)別：
臟讀是T1讀取了T2未提交的數(shù)據(jù)。
不可重復讀則是讀取了前一事務提交的數(shù)據(jù)，在某些情況下，不可重復讀并不是問題，以最終查詢的結果為準。
不可重復讀查詢的都是同一個數(shù)據(jù)項，而幻讀針對的是一批數(shù)據(jù)整體（比如數(shù)據(jù)的個數(shù)）。
四種隔離級別與讀取事務和寫事務：
讀取未提交，讀不會阻塞任何事務，寫只阻塞寫，會導致讀出現(xiàn)臟讀、不可重復讀、幻影讀。
讀取已提交，讀不會阻塞任何事務，寫阻塞讀、寫，因為寫阻塞讀，排除“臟讀” 問題，但是讀還是不阻塞寫，不可重復讀、幻影讀會出現(xiàn)。
可重復讀，讀只阻塞寫，寫阻塞讀、寫，讀阻塞寫避免了“不可重復讀”的問題，但是讀事務并沒有阻塞對數(shù)據(jù)庫的插入操作，所以此 時“幻影讀”問題照樣存在。
Serializable 數(shù)據(jù)庫系統(tǒng)會保證執(zhí)行此種隔離級別事務的效果和順序執(zhí)行的效果一致。
默認的隔離級別：
MySQL：可重復讀。
Oracle：只支持串行化和讀已提交這兩種級別，默認：讀已提交。
并發(fā)控制：
在每個讀的數(shù)據(jù)行上加上共享鎖
此時我們一般采用READ COMMITTED的隔離級別，然后再結合以下幾種并發(fā)控制的鎖定策略：
* 樂觀所 版本號重試
* 悲觀鎖 for update
* 樂觀離線鎖
* 悲觀離線鎖
事務常用的兩個屬性：readonly和timeout，設置事務的超時時間，防止大事務的發(fā)生。
事務模型解析
平面事務模型：本地事務和JTA 事務。
事務管理涉及到的幾個參與者：
1 資源管理器（ Resource Manager) ：資源管理器一般是數(shù)據(jù)庫管理系統(tǒng)。
2 分布式事務協(xié)調者（ Distributed Transaction Coordinator,DTC)：此功能一般是由我們所用的 JavaEE 應用服務器實現(xiàn)，比如 jboss,websphere,weblogic 等。這個角色只有在 JTA 事務中才會存在。
3 事務管理器 (Transaction manager) ：每一個事務管理器都與相應的資源管理器所關聯(lián)，它負責對分布式事務進行提交或者回滾。
4 應用程序（ Application)
以上四者的關系可以用以下的圖形來形象的表述：
在日常的系統(tǒng)開發(fā)中，我們一般都會使用數(shù)據(jù)資源（比如數(shù)據(jù)庫）來對系統(tǒng)的狀態(tài)進行保存，那么我們根據(jù)系統(tǒng)涉及的數(shù)據(jù)資源的多少，將事務分為RESOURCE-LOCAL事務或者JTA全局分布式事務。
1 RESOURCE-LOCAL事務
RESOURCE-LOCAL事務是指只有一個資源管理（RM) 的事務，事務操作都是對同一個數(shù)據(jù)庫進行操作。
此時事務協(xié)調著和事務管理器的作用就有底層的資源管理器來實現(xiàn)了。比如目前我們在采用Spring來管理事務的時候，其實spring并沒有事務功能，它僅僅是封裝了底層數(shù)據(jù)庫的事務操作而已。
2 全局事務或者JTA事務
國際上提出了一種分布式事務解決方案的標準OTS（Object Transaction Service），JavaEE 對OTS 做了實現(xiàn)，即JTS（Java Transaction Service ），java 又提供了操作JTS 的上層接口 JTA （Java Transaction API ）
全局事務是涉及多個資源管理器，此時需要引入事務協(xié)調者(可以理解為全局事務管理器，可基于可靠消息實現(xiàn))來進行調節(jié)
通信協(xié)議：
1、應用服務器與事務管理器通過TX協(xié)議通信。
2、事務管理器與資源管理器通過XA協(xié)議通信。
3、事務管理器之間通過XA+（XA協(xié)議超集）協(xié)議通信。
提交過程：
兩階段提交協(xié)議2PC（two phase commit)
第一階段：事務協(xié)調者發(fā)送“準備提交”消息給事務所涉及的所有的事務管理器，然后事務管理器又分送此消息給相應的資源管理器，然后事務管理器又將資源管理的響應情況告訴分布式事務協(xié)調著（DTC). 只有此階段順利完成后（既所有的資源管理器都同意提交事務），才會進入第二階段。
第二階段：當?shù)谝粋€階段順利完成后，事務協(xié)調者告訴事務管理器去提交事務
分布式最終一致性理論：
CAP理論：
C（一致性）在分布式環(huán)境下多個節(jié)點數(shù)據(jù)是否一致；
A（可用性）服務一直保持可用的狀態(tài)；
P（分區(qū)容忍性）在分布式應用中，可能因為一些分布式的原因導致系統(tǒng)無法運轉，好的分區(qū)容忍性，使應用雖然是一個分布式系統(tǒng)，但是好像一個可以正常運轉的整體
BASE理論：
BA: Basic Availability 基本業(yè)務可用性；
S: Soft state 柔性狀態(tài)；
E: Eventual consistency 最終一致性；
標題名稱：數(shù)據(jù)庫事務
網(wǎng)頁網(wǎng)址：http://www.dlmjj.cn/article/pshcid.html
