關于分布式事務的實作梳理
場景描述
在實際開發程序中，往往會遇到微服務架構中（資料磁區存盤），用戶的一個操作，會設計到多個模塊的資料落地或者更新查找，并且每個模塊資料都是存盤在不同的資料庫，并且業務要求還需要確保操作結果的一致性，比如，用戶在下單時：首選需要落地訂單資料，其次，需要落地：賬單資料、日志資料、或者庫存更新等等操作，首先我們想到的解決方式就是事務來實作，由于在不同庫，所以需要涉及到分布式事務，
解決方案
為了達到上述要求，在實作上根據我的經驗大概有如下3種實作方式：
其一、分布式事務
分布式事務就是采用微軟提高的分布式事務機制實作，在實作效率上不是很理想，并且也不是符合微服務設計的單一功能原則，所以不是很建議使用，
其二、訊息佇列
訊息佇列是現在使用的比較多的解決方案，通過一些訊息佇列中間件， 實作邏輯解耦，異步實作，回應效率也大大提升，
其三、異步作業
異步作業的實作思路和訊息佇列類似，都是對操作的步驟的解耦，異步實作，但是在處理上有一定的延遲性，因為異步作業是周期性的執行，但是異步作業也是對訊息隊里的一個保障和補充，
在實際使用程序中，一般都是訊息佇列和異步作業配套實作，當訊息佇列出現問題，異步作業能正常的把流程走完，
分布式事務
在介紹分布式事務時，分兩部分來介紹：sql分布式事務、ADO.NET分布式事務，
sql分布式事務
分布式事務的實作，首先總結一下sql分布式事務的實作，主要適用于存盤程序或者方法函式中，
sql分布式事務的關鍵詞為：distributed，分布式事務在使用前，需要做一下幾點的環境準備：
分布式事務需要的前期環境準備：
在控制面板--->管理工具--->服務 中，開啟Distributed Transaction Coordinator 服務，
a、控制面板->管理工具->組件服務->計算機->我的電腦->右鍵->屬性
b、選擇MSDTC頁, 確認"使用本地協調器"
c、點擊下方"安全配置"按鈕
d、勾選: "允許網路DTC訪問","允許遠程客戶端","允許入站","允許出站","不要求進行身份驗證".
e、對于資料庫服務器端, 可選擇"要求對呼叫方驗證"
f、勾選:"啟用事務Internet協議（TIP)事務"，
g、在雙方防火墻中增加MSDTC.exe例外
可用命令列: netsh firewall set allowedprogram %windir%/system32/msdtc.exe MSDTC enable
sql分布式事務的使用實體：
use ecshop;go
set XACT_ABORT ON
--開啟分布式事務begin distributed tran tranInsetNamebegin----需要執行的sql陳述句; insert into ecshop..TEST_name values(8,8) insert into ecshopTest..TEST_name values(9,null) insert into ecshopTest..TEST_name values(8,8)commit tran tranInsetNameendgo
ADO.NET中分布式事務
下面在總結一下ADO.NET中分布式事務的使用：
ADO.NET分布式事務關鍵詞為：TransactionScope
ADO.NET分布式事務需要參考命名空間：using System.Transactions
首先需要了解ADO.NET分布式事務的級別
Chaos：無法改寫隔離級別更高的事務中的掛起的更改，
ReadCommitted：不可以在事務期間讀取可變資料，但是可以修改它，
ReadUncommitted：可以在事務期間讀取和修改可變資料，
RepeatableRead：可以在事務期間讀取可變資料，但是不可以修改，可以在事務期間添加新資料，
Serializable：可以在事務期間讀取可變資料，但是不可以修改，也不可以添加任何新資料---默認級別，
Snapshot：可以讀取可變資料，在事務修改資料之前，它驗證在它最初讀取資料之后另一個事務是否更改過這些資料，如果資料已被更新，則會引發錯誤，這樣使事務可獲取先前提交的資料值，
Unspecified：正在使用與指定隔離級別不同的隔離級別，但是無法確定該級別，如果設定了此值，則會引發例外，
實體代碼：
//// 事務附件訊息 TransactionOptions transactionOption = new TransactionOptions(); //設定事務隔離級別 transactionOption.IsolationLevel = System.Transactions.IsolationLevel.ReadCommitted; // 設定事務超時時間為60秒 transactionOption.Timeout = new TimeSpan(0, 0, 60); //啟動一個分布式事務 using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required, transactionOption)) { ///// 處理一個庫操作 using (SqlConnection conn = new SqlConnection(sqlConn)) { conn.Open(); using (SqlCommand cmd = conn.CreateCommand()) { cmd.CommandText = "insert into TEST_name values(25,25);insert into TEST_name values(26,null);"; cmd.ExecuteNonQuery(); cmd.CommandText = "insert into TEST_name values(26,null);"; cmd.ExecuteNonQuery(); } } ///// 創建一個新的連接，處理另外一個庫操作 using (SqlConnection conn = new SqlConnection(sqlConn)) { conn.Open(); using (SqlCommand cmd = conn.CreateCommand()) { cmd.CommandText = "insert into TEST_name values(25,25);insert into TEST_name values(26,null);"; cmd.ExecuteNonQuery(); cmd.CommandText = "insert into TEST_name values(26,null);"; cmd.ExecuteNonQuery(); } } }
分布式事務在執行效率上低，在實際專案中不怎么使用，尤其是微服務專案，在微服務專案中，主要通過訊息佇列變相的實作事務，確保操作結果的一致性
訊息佇列
訊息佇列在實際作業中使用場景還是很多的，主要目的是實作步驟解耦、消峰、高并發，在這只簡單整理一下訊息佇列在分布式事務中的使用，
訊息佇列在分布式事務中使用邏輯大概是：主流程生成完成后，生成一個訊息，直接回傳結果給用戶，通過訊息中間件，告訴后續流程的消費者，進行各自的后續流程邏輯處理、
比如：以一個實際的電商中用戶訂單支付成功為例，假設訂單支付成功后首先需要更新訂單狀態，其它后續流程包括：落地賬單資料、落地分傭資料，假設賬單資料和分傭資料沒有資料關系，可并行執行
那么實作邏輯是：
訊息生產者：支付成功，更新訂單狀態-->發送一個訊息到訊息佇列中間件（廣播）
訊息消費者：此處有兩個訊息消費訂閱物件，賬單落地、分傭資料落地，兩個訊息消費者都會收到一條訊息，并做各自的資料落地處理
訊息隊里，在系統架構上，或者用戶體驗上都有是一個很不錯的選擇，但是在實際作業中，僅僅使用訊息隊里也不是完成的解決方案，因為訊息佇列也有肯能出現宕機或者資料丟失，導致業務邏輯中斷，所以在實際作業中，一般還會借助一個輔助程式（異步作業），實作對訊息隊里的補充的加固
異步作業
異步作業的實作思路就是，程式定期的執行某一些資料流程操作，比如：賬單資料落地異步作業小程式，查找到訂單支付成功，但是賬單為成功，則落地賬單資料
在實作上，推薦使用：Quartz開源的異步作業框架，使用起來很不錯，
具體Quartz的實作方式，推薦一個博客：https://www.cnblogs.com/ll409546297/p/7793877.html
異步作業的宿主有：控制臺程式、表單程式、IIS、Windows服務
在實際開發程序中，推薦使用windows服務，方便控制管理
總結
上面對分布式事務做了簡單的介紹，如果有說的不對的地方勿噴，望多多指點學習，
通過上面的介紹，我們也知道在實際專案中的使用選擇，我還是建議采用：訊息佇列+異步作業 來確保系統的高可用性
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/8124.html
標籤：ASP.NET
上一篇：CefSharp 修復Demo無法在其它路徑下啟動問題
下一篇：ASP.NET是什么？