事物

事物必須服從ISO/IEC所制定的ACID原則。ACID是原子性（atomicity）、一致性（consistency）、隔離性（isolation）、持久性（durability）的縮寫：

• atomicity：事物的原子性表示，事物執(zhí)行過程中的任何失敗都將導(dǎo)致事物所做的任何修改失效。

• consistency：一致性表示當(dāng)事物執(zhí)行失敗時，所有被該事物影響的數(shù)據(jù)都應(yīng)該恢復(fù)到事物執(zhí)行前的狀態(tài)。

• isolation：隔離性表示在事物的執(zhí)行過程中對數(shù)據(jù)的修改，在事物提交之前對其他事物不可見。

• durability：持久性表示提交的數(shù)據(jù)在事物失敗時，數(shù)據(jù)的狀態(tài)都應(yīng)該正確。

通俗的講，事物是一組原子操作，從數(shù)據(jù)庫的角度講，就是一組SQL指令，要么全部執(zhí)行成功，如果因某一條指令執(zhí)行錯誤，則撤銷先前執(zhí)行過的所有指令(即全部回顧)。

隔離級別

標(biāo)準(zhǔn)的事物隔離級別有4種，分別是讀取未提交內(nèi)容（Read Uncommitted）、讀取提交內(nèi)容（Read Committed）、可重讀（Repeatable Read）、可串行化（Serializable）。

• Read Uncommitted

該隔離級別表示所有事物都可以看到其他事物未提交的執(zhí)行結(jié)果。由于該級別會造成臟讀（Dirty Read）的情況，且性能上也不具備顯著優(yōu)勢，所以很少用于實際應(yīng)用中。

• Read committed

該隔離級別表示一個事物只能看到已提交事物所做的修改，這也是大多數(shù)據(jù)庫系統(tǒng)的默認(rèn)隔離級別（但不是MySQL默認(rèn)的）。

這種隔離級別也支持所謂的不可重復(fù)讀（Nonrepeatable Read），因為同一個事物的其他實例在該實例處理期間可能會有新的commit，所以同一個select可能返回不同結(jié)果。

• Repeatable Read

這是MySQL的默認(rèn)事物隔離級別，它確保同一事物的多個實例在并發(fā)讀取數(shù)據(jù)時，會看到同樣的數(shù)據(jù)行。不過理論上，這會導(dǎo)致另外一個束手的問題：幻讀（Phantom Read）。

簡單的說，幻讀指當(dāng)用戶讀取某一范圍的數(shù)據(jù)行時，另一個事物又在該范圍內(nèi)插入了新行，當(dāng)用戶再讀取該范圍的數(shù)據(jù)時，會發(fā)現(xiàn)新的“幻影”行。InnoDB和Falcon存儲引擎是通過多版本并發(fā)控制機制解決該問題的。

• Serializable

這是最高的事物級別，它通常強制事物排序，使之不可能相互沖突，從而解決幻讀問題。簡言之，就是該隔離級別會在每個讀取的數(shù)據(jù)行上加共享鎖。這個級別的性能會很差，可能導(dǎo)致大量的超時現(xiàn)象和鎖競爭。

在MySQL的中，實現(xiàn)這四種隔離級別分別有可能產(chǎn)生以下問題：

• 臟讀（Dirty Read）：某個事物A已經(jīng)更新一份數(shù)據(jù)，事物B在此時讀取了這份數(shù)據(jù)，由于事物A執(zhí)行異常，最終RollBack了所有操作，則事物B讀取的數(shù)據(jù)就是錯誤的了，該種情況被稱為臟讀。

• 不可重復(fù)讀（NonRepeatable Read）：在一個事物的兩次查詢之中數(shù)據(jù)不一致，這可能是兩次查詢過程中插入了一個事物更新的原有數(shù)據(jù)。即select → update → select，兩次select結(jié)果不一致的情況被稱為不可重復(fù)讀。

• 幻讀（Phantom Read）：在一次事物兩次查詢中，筆數(shù)不一致。例如一個事物A查詢了幾列(Row)數(shù)據(jù)，而另一個事物卻在此時插入了新的幾列數(shù)據(jù)，先前的事物在接下來的查詢中，就有幾列數(shù)據(jù)是未查詢出來的。如果此時事物里有插入操作，那么和另一個事物的插入就會沖突，會報錯。

分布式事物

分布式事務(wù)是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上。例如在大型電商系統(tǒng)中，下單接口通常會扣減庫存、減去優(yōu)惠、生成訂單 id, 而訂單服務(wù)與庫存、優(yōu)惠、訂單 id 都是不同的服務(wù)，下單接口的成功與否，不僅取決于本地的 db 操作，而且依賴第三方系統(tǒng)的結(jié)果，這時候分布式事務(wù)就保證這些操作要么全部成功，要么全部失敗。本質(zhì)上來說，分布式事務(wù)就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。

強一致性事務(wù)

任何一次讀都能讀到某個數(shù)據(jù)的最近一次寫的數(shù)據(jù)。系統(tǒng)中的所有進程，看到的操作順序，都和全局時鐘下的順序一致。簡言之，在任意時刻，所有節(jié)點中的數(shù)據(jù)是一樣的。

2PC

2PC（Two-phase commit protocol），中文叫二階段提交。 二階段提交是一種強一致性設(shè)計，2PC 引入一個事務(wù)協(xié)調(diào)者的角色來協(xié)調(diào)管理各參與者（也可稱之為各本地資源）的提交和回滾，二階段分別指的是準(zhǔn)備（投票）和提交兩個階段。

• 第一階段（prepare）：事務(wù)管理器向所有本地資源管理器發(fā)起請求，詢問是否是 ready 狀態(tài)，所有參與者都將本事務(wù)能否成功的信息反饋發(fā)給協(xié)調(diào)者；

• 第二階段 (commit/rollback)：事務(wù)管理器根據(jù)所有本地資源管理器的反饋，通知所有本地資源管理器，步調(diào)一致地在所有分支上提交或者回滾。

成功：失敗：

2PC 是一種盡量保證強一致性的分布式事務(wù)，因此它是同步阻塞的，而同步阻塞就導(dǎo)致長久的資源鎖定問題，總體而言效率低，并且存在單點故障問題，在極端條件下存在數(shù)據(jù)不一致的風(fēng)險。

3PC

3PC 的出現(xiàn)是為了解決 2PC 的一些問題，相比于 2PC 它在參與者中也引入了超時機制，并且新增了一個階段使得參與者可以利用這一個階段統(tǒng)一各自的狀態(tài)。

• 第一階段：只是詢問所有參與者是否可可以執(zhí)行事務(wù)操作，并不在本階段執(zhí)行事務(wù)操作。

• 第二階段：當(dāng)協(xié)調(diào)者收到所有的參與者都返回YES時，在第二階段才執(zhí)行事務(wù)操作

• 第三階段：然后在第三階段在執(zhí)行commit或者rollback。

3PC 的引入是為了解決提交階段 2PC 協(xié)調(diào)者和某參與者都掛了之后新選舉的協(xié)調(diào)者不知道當(dāng)前應(yīng)該提交還是回滾的問題。3PC也不是完美的，同樣存在問題：

在doCommit階段，如果參與者無法及時接收到來自協(xié)調(diào)者的doCommit或者rebort請求時，會在等待超時之后，會繼續(xù)進行事務(wù)的提交。所以，由于網(wǎng)絡(luò)原因，協(xié)調(diào)者發(fā)送的abort響應(yīng)沒有及時被參與者接收到，那么參與者在等待超時之后執(zhí)行了commit操作。這樣就和其他接到abort命令并執(zhí)行回滾的參與者之間存在數(shù)據(jù)不一致的情況。

最終一致性事務(wù)

不保證在任意時刻任意節(jié)點上的同一份數(shù)據(jù)都是相同的，但是隨著時間的遷移，不同節(jié)點上的同一份數(shù)據(jù)總是在向趨同的方向變化。簡單說，就是在一段時間后，節(jié)點間的數(shù)據(jù)會最終達到一致狀態(tài)。

傳統(tǒng)的分布式事務(wù)已經(jīng)無法滿足微服務(wù)架構(gòu)下的事務(wù)管理需求。那么，既然無法滿足傳統(tǒng)的ACID事務(wù)，在微服務(wù)下的事務(wù)管理必然要遵循新的法則－－BASE理論。

BASE理論由eBay的架構(gòu)師Dan Pritchett提出，BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性，應(yīng)用應(yīng)該可以采用合適的方式達到最終一致性。BASE是指基本可用（Basically Available）、軟狀態(tài)（ Soft State）、最終一致性（ Eventual Consistency）。

• 基本可用：指分布式系統(tǒng)在出現(xiàn)故障的時候，允許損失部分可用性，即保證核心可用。

• 軟狀態(tài)：允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會影響系統(tǒng)整體可用性。分布式存儲中一般一份數(shù)據(jù)至少會有三個副本，允許不同節(jié)點間副本同步的延時就是軟狀態(tài)的體現(xiàn)。

• 最終一致性：最終一致性是指系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一定時間后，最終能夠達到一致的狀態(tài)。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況。

BASE中的最終一致性是對于微服務(wù)下的事務(wù)管理的根本要求，即雖然基于微服務(wù)的事務(wù)管理無法達到強一致性，但必須保證最終一致性，這就是所說的柔性事務(wù)。實現(xiàn)事務(wù)最終一致性的方案主要有事件通知模式、事務(wù)補償模式兩種。

事件通知模式

本地消息表

本地消息表其實就是利用了 各系統(tǒng)本地的事務(wù)來實現(xiàn)分布式事務(wù)。本地消息表顧名思義就是會有一張存放本地消息的表，一般都是放在數(shù)據(jù)庫中，然后在執(zhí)行業(yè)務(wù)的時候 將業(yè)務(wù)的執(zhí)行和將消息放入消息表中的操作放在同一個事務(wù)中，這樣就能保證消息放入本地表中業(yè)務(wù)肯定是執(zhí)行成功的。然后再去調(diào)用下一個操作，如果下一個操作調(diào)用成功了好說，消息表的消息狀態(tài)可以直接改成已成功。如果調(diào)用失敗也沒事，會有后臺任務(wù)定時去讀取本地消息表，篩選出還未成功的消息再調(diào)用對應(yīng)的服務(wù)，服務(wù)更新成功了再變更消息的狀態(tài)。這時候有可能消息對應(yīng)的操作不成功，因此也需要重試，重試就得保證對應(yīng)服務(wù)的方法是冪等的，而且一般重試會有最大次數(shù)，超過最大次數(shù)可以記錄下報警讓人工處理。可以看到本地消息表其實實現(xiàn)的是最終一致性，容忍了數(shù)據(jù)暫時不一致的情況。

可靠消息MQ事務(wù)

RocketMQ 就很好的支持了消息事務(wù)，下圖中的半消息不是說一半消息，而是這個消息對消費者來說不可見，然后發(fā)送成功后發(fā)送方再執(zhí)行本地事務(wù)。

1. 事務(wù)發(fā)起方首先發(fā)送 prepare 消息到 MQ。

2. 在發(fā)送 prepare 消息成功后執(zhí)行本地事務(wù)。

3. 執(zhí)行本地事務(wù)

4. 根據(jù)本地事務(wù)執(zhí)行結(jié)果返回 commit 或者是 rollback。

5. 如果消息是 rollback，MQ 將刪除該 prepare 消息不進行下發(fā)，如果是 commit 消息，MQ 將會把這個消息發(fā)送給 consumer 端。

6. 如果執(zhí)行本地事務(wù)過程中，執(zhí)行端掛掉，或者超時，MQ 將會不停的詢問其同組的其他 producer 來獲取狀態(tài)。

7. Consumer 端的消費成功機制有 MQ 保證

最大努力通知

最大努力通知是最簡單的一種柔性事務(wù)，適用于一些最終一致性時間敏感度低的業(yè)務(wù)，且被動方處理結(jié)果 不影響主動方的處理結(jié)果。這個方案的大致意思就是：

1. 系統(tǒng) A 本地事務(wù)執(zhí)行完之后，發(fā)送個消息到 MQ；

2. 這里會有個專門消費 MQ 的服務(wù)，這個服務(wù)會消費 MQ 并調(diào)用系統(tǒng) B 的接口；

3. 要是系統(tǒng) B 執(zhí)行成功就 ok 了；要是系統(tǒng) B 執(zhí)行失敗了，那么最大努力通知服務(wù)就定時嘗試重新調(diào)用系統(tǒng) B, 反復(fù) N 次，最后還是不行就放棄。

事件補償模式

補償模式比起事件通知模式最大的不同是，補償模式的上游服務(wù)依賴于下游服務(wù)的運行結(jié)果，而事件通知模式上游服務(wù)不依賴于下游服務(wù)的運行結(jié)果。

TCC

TCC指的是Try - Confirm - Cancel。

• Try 指的是預(yù)留，即資源的預(yù)留和鎖定，注意是預(yù)留。

• Confirm 指的是確認(rèn)操作，這一步其實就是真正的執(zhí)行了。

• Cancel 指的是撤銷操作，可以理解為把預(yù)留階段的動作撤銷了。

其實從思想上看和 2PC 差不多，都是先試探性的執(zhí)行，如果都可以那就真正的執(zhí)行，如果不行就回滾。比如說一個事務(wù)要執(zhí)行A、B、C三個操作，那么先對三個操作執(zhí)行預(yù)留動作。如果都預(yù)留成功了那么就執(zhí)行確認(rèn)操作，如果有一個預(yù)留失敗那就都執(zhí)行撤銷動作。我們來看下流程，TCC模型還有個事務(wù)管理者的角色，用來記錄TCC全局事務(wù)狀態(tài)并提交或者回滾事務(wù)。

TCC 對業(yè)務(wù)的侵入較大和業(yè)務(wù)緊耦合，需要根據(jù)特定的場景和業(yè)務(wù)邏輯來設(shè)計相應(yīng)的操作。

Saga模式

Saga是一種純業(yè)務(wù)補償模式，其設(shè)計理念為，業(yè)務(wù)在調(diào)用的時候正常提交，當(dāng)一個服務(wù)失敗的時候，所有其依賴的上游服務(wù)都進行業(yè)務(wù)補償操作。業(yè)務(wù)補償模式要求每個服務(wù)都提供補償接口，且這種補償一般來說是不完全補償，既即使進行了補償操作，那條取消的火車票記錄還是一直存在數(shù)據(jù)庫中可以被追蹤（一般是有相信的狀態(tài)字段“已取消”作為標(biāo)記），畢竟已經(jīng)提交的線上數(shù)據(jù)一般是不能進行物理刪除的。業(yè)務(wù)補償模式最大的缺點是軟狀態(tài)的時間比較長，既數(shù)據(jù)一致性的時效性很低，多個服務(wù)常常可能處于數(shù)據(jù)不一致的情況。

總結(jié)