前面我們講了分布式事務的2PC、3PC , TCC 的原理，這些事務其實都在盡力的模擬資料庫的事務，我們可以簡單的認為他們是一個同步行的事務，特別是 2PC,3PC 他們完全利用資料庫的事務能力，在一階段開始事務后不進提交會嚴重影回應用程式的并發性能，TCC 一階段雖然不會阻塞資料庫，但是它同樣是在盡力追求同時成功同時失敗的一致性要求，但是在很多時候，我們的應用程式的核心業務為了追求更高的性能、更高的可用性，可以允許在一段時間內的資料不一致性，只需要在最終時刻資料是一致就可以了，基于以上場景我們可以采用基于可靠訊息服務的最終一致性分布式事務處理方案，
總體架構
可靠訊息最終一致性的架構上分3個部分：
- 主動方：主動發起事務的一方，一般是指分布式事務中最先開始執行的那個服務，也是核心業務服務
- 可靠訊息服務：可靠訊息服務由關系型資料庫、訊息佇列MQ等組件組成，利用關系型資料庫的強一致性特性來持久化訊息的狀態，利用MQ來保證訊息的可靠投遞及消費
- 被動方：被動方訂閱MQ的訊息，當收到MQ的訊息后執行對應的業務
以上是比較粗狂的結構圖，下面我們來詳細分析一下這個事務的執行程序，
流程
該方案總體流程上可分為以下步驟：
- 主動方在真正的業務開始前先向可靠訊息服務發送一個“待確認”的訊息
- 可靠訊息服務收到待確認訊息后持久化訊息到資料庫
- 如果以上操作成功則主動方開始真正的業務，如果失敗則直接放棄執行業務
- 如果業務執行成功則發送“確認”訊息給可靠訊息服務，如果執行失敗則發送“取消”給可靠訊息服務，
- 如果可靠訊息服務收到“確認”訊息則更新資料庫里的訊息記錄的狀態為“待發送”，如果收到的訊息為“取消”則更新訊息狀態為“已取消”
- 如果上一步更新的資料庫為“待發送”，那么會開始往MQ投遞訊息，并且更改資料庫里的訊息記錄的狀態為“已發送”
- 上一步往MQ投遞訊息成功后，MQ會給被動方推送訊息，
- 被動方收到訊息后開始處理業務
- 如果業務處理成功，則被動方對MQ進行ACK回復，則這條訊息會從MQ內移除掉
- 如果業務處理成功，則發送“已完成”訊息給可靠訊息服務
- 可靠訊息服務收到“已完成”訊息后更新資料庫訊息記錄未“已完成”
例外處理
以上我們描述的是一套在理想情況下執行的邏輯，但是分布式系統由于網路的存在，網路的不可靠性會導致我們訊息的傳遞沒辦法100%成功，我們的可靠訊息服務跟主動方、被動方之間的互動也是分布式的，這就需要我們在流程上有很多補償的機制，以下我們來討論一些例外情況：
- 如果步驟1發送“待確認”訊息失敗，主動方業務不會執行，直接放棄事務，不會有影響
- 如果步驟1發送“待確認”訊息成功，并且可靠訊息已經更新“待確認”成功，但是由于網路問題，比如超時，主動方得到的結果是失敗，主動方會放棄執行事務，標記為“已取消”，這個時候就會出現可靠訊息服務跟主動方的狀態出現不一致的情況，
為解決這個問題，我需要主動方提供一個事務狀態查詢介面，可靠訊息服務這邊則啟動一個定時任務，定時去查這些長時間處于待確認的事務，然后通過主動方的介面確認這些事務是已執行，還是已取消， - 如果步驟4，主動方發送“確認”訊息失敗，可靠訊息服務會通過定時任務通過主動方的查詢介面去確認狀態，
- 步驟6，投遞訊息給MQ跟更新狀態為“已發送”，是這個流程中至關重要的一步，理想的流程是整個2個操作同時成功同時失敗，保持強一致性，網上很多文章都會說“為了保證發送MQ訊息跟更新訊息狀態同時成功同時失敗，需要把這個2個步驟寫同一個本地事務中”，這是完全不靠譜的，資料庫跟MQ本就是2個獨立的服務，如果通過一個本地的事務就能保證一致性，那么我們現在討論的分布式事務毫無意義，直接寫在一個本地事務里不就完了么，
寫在本地事務內只能盡可能的保證資料庫更新跟MQ投遞訊息同時成功，但是并不能保證100%一致，
以下我們來分2種情況分析失敗的情況：
事務開始
1. send to mq
2. database update
事務結束
先發送 MQ 訊息，可能 MQ 訊息發送成功，但是database由于某些原因更新失敗了，資料庫可以回滾，但是通常的MQ沒有回滾能力，
事務開始
1. database update
2. send to mq
事務結束
先更新資料庫，再發送 MQ 訊息，同樣會有問題，就算1,2都執行成功了，但是事務是需要提交的，資料庫有可能在提交階段失敗，資料庫是可以回滾，但是 MQ 的訊息已經發出去了，它并沒有回滾的能力，
為了解決這個問題，我們同樣需要補償機制，在可靠訊息服務一側開啟定時任務，定時去查詢那些長期處于“待發送\已發送”的事務，再次對 MQ 進行投遞訊息，這個機制有可能造成被動方重復收到 MQ 的訊息，這就需要被動方處理業務的時候要進行冪等處理，
總結
通過以上我們詳細介紹了可靠訊息最終一致性事務解決方案的總體結構跟執行的流程，以及對例外情況的一些補償方法，總體流程上還是比較清晰簡單的，但是可靠訊息最終一致性方案在使用上也是具有比較強的局限性，因為它的異步特性跟有可能出現的高延時性不適合處理一些敏感業務，比如它適合處理消費新增積分場景，但是不合適處理積分兌換禮品的場景，因為如果積分扣減延遲了，那么用戶就可能兌換超出本身積分多的多的禮品，所以我們選擇分布式事務的時候還需根據場景來進行選擇，
好了講了這么多分布式事務的原理，下一期我們使用 .NET 真正的實作一個分布式事務，敬請期待，
.Net Core with 微服務 - 什么是微服務
.Net Core with 微服務 - 架構圖
.Net Core with 微服務 - Ocelot 網關
.Net Core with 微服務 - Consul 注冊中心
.Net Core with 微服務 - Seq 日志聚合
.Net Core with 微服務 - Elastic APM
.Net Core with 微服務 - Consul 配置中心
.Net Core with 微服務 - Polly 熔斷降級
.Net Core with 微服務 - 分布式事務 - 2PC、3PC
.Net Core with 微服務 - 分布式事務 - TCC
關注我的公眾號一起玩轉技術
QQ群：1022985150 一起探討學習.NET技術
作者：Agile.Zhou(kklldog)
出處：http://www.cnblogs.com/kklldog/
本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/302096.html
標籤：.NET技术