關於分布式事務的實現梳理

關於分布式事務的實現梳理

場景描述

 　　在實際開發過程中，往往會遇到微服務架構中（數據分區存儲），用戶的一個操作，會設計到多個模塊的數據落地或者更新查找，並且每個模塊數據都是存儲在不同的數據庫，並且業務要求還需要確保操作結果的一致性。比如，用戶在下單時：首選需要落地訂單數據，其次，需要落地：賬單數據、日志數據、或者庫存更新等等操作。首先我們想到的解決方式就是事務來實現，由於在不同庫，所以需要涉及到分布式事務。

解決方案

 　　為了達到上述要求，在實現上根據我的經驗大概有如下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 tranInsetName

begin

----需要執行的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 tranInsetName
end
go

 

　　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服務，方便控制管理

總結

 　　上面對分布式事務做了簡單的介紹，如果有說的不對的地方勿噴，望多多指點學習。

　　通過上面的介紹，我們也知道在實際項目中的使用選擇，我還是建議采用：消息隊列+異步作業 來確保系統的高可用性