事務acid特性：
事務隔離級別：指的是讀和寫同時出現時出現的資料不一致問題。
事務的一致性問題
存在問題問題描述
髒讀（dirty read）
針對的是單條資料。
即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。
不可重複讀（unrepeatable read）
針對的是單條資料
即當a讀取了某一條資料，之後事務b修改了該資料且已經提交，此時a又讀取了該資料，讀到的資料是b修改後的資料，而不是希望的修改之前的資料，這叫不可重複讀。
幻讀（phantom problem）
針對的是新增或刪除的多條資料。
即a執行了某個查詢操作，查詢到3條資料，此時事務b插入（或刪除了）一條資料，導致事務a再次查詢時，讀到了a插入的新資料（或讀到了2條資料）。
序列化這是資料庫最高的隔離級別，這種級別下，事務「序列化順序執行」，也就是乙個乙個排隊執行。
這種級別下，「髒讀」、「不可重複讀」、「幻讀」都可以被避免，但是執行效率奇差，效能開銷也最大，所以基本沒人會用。
事務隔離級別
隔離級別說明實現機制優點缺點
讀未提交（read uncommitted）
可以讀到未提交的內容
查詢不加鎖
併發速度快
一致性最差。可能會產生「髒讀」、「不可重複讀」、「幻讀」。
如無特殊情況，基本是不會使用這種隔離級別的。
讀已提交（read committed）
只能讀到已經提交了的內容。
這是各種系統中最常用的一種隔離級別，也是sql server和oracle的預設隔離級別。這種隔離級別能夠有效的避免髒讀。
通過「快照（snapshot）」機制，既不加鎖，由能保證一致性，因此也被稱為「快照讀（snapshot read）」
假設沒有「快照讀」，那麼當乙個更新的事務沒有提交時，另乙個對更新資料進行查詢的事務會因為無法查詢而被阻塞，這種情況下，併發能力就相當的差。
而「快照讀」就可以完成高併發的查詢。
另外，可以在查詢中顯示的加鎖，如：
select * from t where id=2 lock in share mode;
select * from t where id=2 for update;
可避免髒讀
並不能避免「不可重複讀」和「幻讀」
可重複讀（repeated red）
專門針對「不可重複讀」這種情況而制定的隔離級別，自然，它就可以有效的避免「不可重複讀」。而它也是mysql的預設隔離級別。
普通的查詢同樣是使用的「快照讀」，但是，和「讀提交」不同的是，當讀事務啟動時，就不允許進行「修改操作（update）」了，而「不可重複讀」恰恰是因為兩次讀取之間進行了資料的修改，因此，「可重複讀」能夠有效的避免「不可重複讀」。
可保證讀事務的兩次讀取同一條資料時，讀取的結果相同，不受修改事務的影響
避免不了「幻讀」，因為幻讀是由於「插入或者刪除操作（insert or delete）」而產生的
序列化（serializable）
這是資料庫最高的隔離級別，這種級別下，事務「序列化順序執行」，也就是乙個乙個排隊執行。
一致性最強
這種級別下，「髒讀」、「不可重複讀」、「幻讀」都可以被避免，
執行效率奇差，效能開銷也最大，所以基本沒人會用。
rm(resource manager)
tm(transaction manager)
兩階段型
補償型非同步確保型
最大努力通知型
柔性事務解決方案：可靠訊息最終一致性（非同步確保型）
柔性事務解決方案：tcc(兩階段型、補償型)
柔性事務解決方案：定期校對（最大努力通知型）
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...
分布式事務解決方案
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...
分布式事務解決方案
由於資料量的巨大，大部分web應用都需要部署很多個資料庫例項。這樣，有些使用者操作就可能需要去修改多個資料庫例項中的資料。傳統的解決方法是使用分布式事務保證資料的全域性一致性，經典的方法是使用兩階段提交協議。長期以來，分布式事務提供的優雅的全域性acid保證麻醉了應用開發者的心靈，很多人都不敢越雷池...