本文已經收錄到Github倉庫，該倉庫包含計算機基礎、Java基礎、多執行緒、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~
Github地址：https://github.com/Tyson0314/Java-learning
簡介
事務
事務是應用程式中一系列嚴密的操作，所有操作必須成功完成，否則在每個操作中所作的所有更改都會被撤消，也就是事務具有原子性，一個事務中的一系列的操作要么全部成功，要么一個都不做，事務應該具有 4 個屬性：原子性、一致性、隔離性、持久性，這四個屬性通常稱為 ACID 特性，
分布式事務
分布式事務是指事務的參與者，支持事務的服務器，資源服務器以及事務管理器分別位于分布式系統的不同節點之上，通常一個分布式事務中會涉及對多個資料源或業務系統的操作，分布式事務也可以被定義為一種嵌套型的事務，同時也就具有了ACID事務的特性，
強一致性、弱一致性、最終一致性
強一致性
任何一次讀都能讀到某個資料的最近一次寫的資料，系統中的所有行程，看到的操作順序，都和全域時鐘下的順序一致，簡言之，在任意時刻，所有節點中的資料是一樣的，
弱一致性
資料更新后，如果能容忍后續的訪問只能訪問到部分或者全部訪問不到，則是弱一致性，
最終一致性
不保證在任意時刻任意節點上的同一份資料都是相同的，但是隨著時間的遷移，不同節點上的同一份資料總是在向趨同的方向變化，簡單說，就是在一段時間后，節點間的資料會最終達到一致狀態，
由于分布式事務方案，無法做到完全的ACID的保證，沒有一種完美的方案，能夠解決掉所有業務問題，因此在實際應用中，會根據業務的不同特性，選擇最適合的分布式事務方案，
分布式事務的基礎
CAP理論
Consistency（一致性）：資料一致更新，所有資料變動都是同步的（強一致性），
Availability（可用性）：好的回應性能，
Partition tolerance（磁區容錯性） ：可靠性，
定理：任何分布式系統只可同時滿足二點，沒法三者兼顧，
CA系統（放棄P）：指將所有資料（或者僅僅是那些與事務相關的資料）都放在一個分布式節點上，就不會存在網路磁區，所以強一致性以及可用性得到滿足，
CP系統（放棄A）：如果要求資料在各個服務器上是強一致的，然而網路磁區會導致同步時間無限延長，那么如此一來可用性就得不到保障了，堅持事務ACID（原子性、一致性、隔離性和持久性）的傳統資料庫以及對結果一致性非常敏感的應用通常會做出這樣的選擇，
AP系統（放棄C）：這里所說的放棄一致性，并不是完全放棄資料一致性，而是放棄資料的強一致性，而保留資料的最終一致性，如果即要求系統高可用又要求磁區容錯，那么就要放棄一致性了，因為一旦發生網路磁區，節點之間將無法通信，為了滿足高可用，每個節點只能用本地資料提供服務，這樣就會導致資料不一致，一些遵守BASE原則資料庫，（如：Cassandra、CouchDB等）往往會放寬對一致性的要求（滿足最終一致性即可），一次來獲取基本的可用性，
BASE理論
BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫，是對CAP中AP的一個擴展，
- 基本可用:分布式系統在出現故障時，允許損失部分可用功能，保證核心功能可用，
- 軟狀態:允許系統中存在中間狀態，這個狀態不影響系統可用性，這里指的是CAP中的不一致，
- 最終一致:最終一致是指經過一段時間后，所有節點資料都將會達到一致，
BASE解決了CAP中理論沒有網路延遲，在BASE中用軟狀態和最終一致，保證了延遲后的一致性，BASE和 ACID 是相反的，它完全不同于ACID的強一致性模型，而是通過犧牲強一致性來獲得可用性，并允許資料在一段時間內是不一致的，但最終達到一致狀態，
分布式事務解決方案
分布式事務的實作主要有以下 6 種方案：
- 2PC 方案
- TCC 方案
- 本地訊息表
- MQ事務
- Saga事務
- 最大努力通知方案
2PC方案
2PC方案分為兩階段:
第一階段：事務管理器要求每個涉及到事務的資料庫預提交(precommit)此操作，并反映是否可以提交.
第二階段：事務協調器要求每個資料庫提交資料，或者回滾資料，
優點： 盡量保證了資料的強一致，實作成本較低，在各大主流資料庫都有自己實作，對于MySQL是從5.5開始支持，
缺點:
- 單點問題:事務管理器在整個流程中扮演的角色很關鍵，如果其宕機，比如在第一階段已經完成，在第二階段正準備提交的時候事務管理器宕機，資源管理器就會一直阻塞，導致資料庫無法使用，
- 同步阻塞:在準備就緒之后，資源管理器中的資源一直處于阻塞，直到提交完成，釋放資源，
- 資料不一致:兩階段提交協議雖然為分布式資料強一致性所設計，但仍然存在資料不一致性的可能，比如在第二階段中，假設協調者發出了事務commit的通知，但是因為網路問題該通知僅被一部分參與者所收到并執行了commit操作，其余的參與者則因為沒有收到通知一直處于阻塞狀態，這時候就產生了資料的不一致性，
總的來說，2PC方案比較簡單，成本較低，但是其單點問題，以及不能支持高并發（由于同步阻塞）依然是其最大的弱點，
TCC
TCC 的全稱是：Try、Confirm、Cancel，
- Try 階段：這個階段說的是對各個服務的資源做檢測以及對資源進行 鎖定或者預留，
- Confirm 階段：這個階段說的是在各個服務中執行實際的操作，
- Cancel 階段：如果任何一個服務的業務方法執行出錯，那么這里就需要 進行補償，就是執行已經執行成功的業務邏輯的回滾操作，（把那些執行成功的回滾）
舉個簡單的例子如果你用100元買了一瓶水， Try階段:你需要向你的錢包檢查是否夠100元并鎖住這100元，水也是一樣的，
如果有一個失敗，則進行cancel(釋放這100元和這一瓶水)，如果cancel失敗不論什么失敗都進行重試cancel，所以需要保持冪等，
如果都成功，則進行confirm,確認這100元扣，和這一瓶水被賣，如果confirm失敗無論什么失敗則重試(會依靠活動日志進行重試)，
這種方案說實話幾乎很少人使用，但是也有使用的場景，因為這個事務回滾實際上是嚴重依賴于你自己寫代碼來回滾和補償了，會造成補償代碼巨大，
本地訊息表
本地訊息表的核心是將需要分布式處理的任務通過訊息日志的方式來異步執行，訊息日志可以存盤到本地文本、資料庫或訊息佇列，再通過業務規則自動或人工發起重試，人工重試更多的是應用于支付場景，通過對賬系統對事后問題的處理，
對于本地訊息佇列來說核心是把大事務轉變為小事務，還是舉上面用100元去買一瓶水的例子，
1.當你扣錢的時候，你需要在你扣錢的服務器上新增加一個本地訊息表，你需要把你扣錢和寫入減去水的庫存到本地訊息表放入同一個事務(依靠資料庫本地事務保證一致性，
2.這個時候有個定時任務去輪詢這個本地事務表，把沒有發送的訊息，扔給商品庫存服務器，叫他減去水的庫存，到達商品服務器之后這個時候得先寫入這個服務器的事務表，然后進行扣減，扣減成功后，更新事務表中的狀態，
3.商品服務器通過定時任務掃描訊息表或者直接通知扣錢服務器，扣錢服務器本地訊息表進行狀態更新，
4.針對一些例外情況，定時掃描未成功處理的訊息，進行重新發送，在商品服務器接到訊息之后，首先判斷是否是重復的，如果已經接收，在判斷是否執行，如果執行在馬上又進行通知事務，如果未執行，需要重新執行需要由業務保證冪等，也就是不會多扣一瓶水，
本地訊息佇列是BASE理論，是最終一致模型，適用于對一致性要求不高的，實作這個模型時需要注意重試的冪等，
MQ事務
基于 MQ 的分布式事務方案其實是對本地訊息表的封裝，將本地訊息表基于 MQ 內部，其他方面的協議基本與本地訊息表一致，
MQ事務方案整體流程和本地訊息表的流程很相似，如下圖：
從上圖可以看出和本地訊息表方案唯一不同就是將本地訊息表存在了MQ內部，而不是業務資料庫中，
那么MQ內部的處理尤為重要，下面主要基于 RocketMQ 4.3 之后的版本介紹 MQ 的分布式事務方案，
在本地訊息表方案中，保證事務主動方發寫業務表資料和寫訊息表資料的一致性是基于資料庫事務，RocketMQ 的事務訊息相對于普通 MQ提供了 2PC 的提交介面，方案如下：
正常情況：事務主動方發訊息
這種情況下，事務主動方服務正常，沒有發生故障，發訊息流程如下：
- 發送方向 MQ 服務端(MQ Server)發送 half 訊息，
- MQ Server 將訊息持久化成功之后，向發送方 ack 確認訊息已經發送成功，
- 發送方開始執行本地事務邏輯，
- 發送方根據本地事務執行結果向 MQ Server 提交二次確認（commit 或是 rollback），
- MQ Server 收到 commit 狀態則將半訊息標記為可投遞，訂閱方最終將收到該訊息；MQ Server 收到 rollback 狀態則洗掉半訊息，訂閱方將不會接受該訊息，
例外情況：事務主動方訊息恢復
在斷網或者應用重啟等例外情況下，圖中 4 提交的二次確認超時未到達 MQ Server，此時處理邏輯如下：
- MQ Server 對該訊息發起訊息回查，
- 發送方收到訊息回查后，需要檢查對應訊息的本地事務執行的最終結果，
- 發送方根據檢查得到的本地事務的最終狀態再次提交二次確認，
- MQ Server基于 commit/rollback 對訊息進行投遞或者洗掉，
優點
相比本地訊息表方案，MQ 事務方案優點是：
- 訊息資料獨立存盤 ，降低業務系統與訊息系統之間的耦合，
- 吞吐量大于使用本地訊息表方案，
缺點
- 一次訊息發送需要兩次網路請求(half 訊息 + commit/rollback 訊息) ，
- 業務處理服務需要實作訊息狀態回查介面，
Saga事務
Saga是由一系列的本地事務構成，每一個本地事務在更新完資料庫之后，會發布一條訊息或者一個事件來觸發Saga中的下一個本地事務的執行，如果一個本地事務因為某些業務規則無法滿足而失敗，Saga會執行在這個失敗的事務之前成功提交的所有事務的補償操作，
Saga的實作有很多種方式，其中最流行的兩種方式是：
- 基于事件的方式，這種方式沒有協調中心，整個模式的作業方式就像舞蹈一樣，各個舞蹈演員按照預先編排的動作和走位各自表演，最終形成一只舞蹈，處于當前Saga下的各個服務，會產生某類事件，或者監聽其它服務產生的事件并決定是否需要針對監聽到的事件做出回應，
- 基于命令的方式，這種方式的作業形式就像一只樂隊，由一個指揮家（協調中心）來協調大家的作業，協調中心來告訴Saga的參與方應該執行哪一個本地事務，
最大努力通知方案
最大努力通知也稱為定期校對，是對MQ事務方案的進一步優化，它在事務主動方增加了訊息校對的介面，如果事務被動方沒有接收到訊息，此時可以呼叫事務主動方提供的訊息校對的介面主動獲取，
最大努力通知的整體流程如下圖：
在可靠訊息事務中，事務主動方需要將訊息發送出去，并且訊息接收方成功接收，這種可靠性發送是由事務主動方保證的；
但是最大努力通知，事務主動方盡最大努力（重試，輪詢....）將事務發送給事務接收方，但是仍然存在訊息接收不到，此時需要事務被動方主動呼叫事務主動方的訊息校對介面查詢業務訊息并消費，這種通知的可靠性是由事務被動方保證的，
最大努力通知適用于業務通知型別，例如微信交易的結果，就是通過最大努力通知方式通知各個商戶，既有回呼通知，也有交易查詢介面，
最后給大家分享一個Github倉庫，上面有大彬整理的300多本經典的計算機書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、作業系統、計算機網路、資料結構和演算法、機器學習、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續更新中~
Github地址：https://github.com/Tyson0314/java-books
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/546909.html
標籤：Java
上一篇：Java集合