**分布式事務控制在銀行應用的實現
原創 2017-05-28
劉文濤csdn
csdn
作者 | 劉文濤
責編 | 仲培藝
對於分布式資料庫而言，分布式事務控制是重點和難點，一直以來沒有成熟的方案可以突破cap理論，幾乎每個分布式資料庫研發團隊都在分布式事務控制方案上結合了各自應用特點，進行了針對性的取捨，可以說是八仙過海各顯神通。以下是我對分布式事務控制的理解：
分布式事務控制的最終目標是實現一致性，方案大體分為實時一致性和最終一致性兩種。兩階段提交是比較典型的實時一致性方案，提供補償事務和基於訊息佇列的非同步處理方案是最終一致性方案。兩階段提交由於同步阻塞、存在髒讀可能性等問題，在某些銀行的應用場景下無法使用，如果將隔離級別修改為序列化則可以解決髒讀問題，但對效能影響較大。基於訊息佇列的非同步處理方案將事務拆分成多個本地子事務，子事務之間通過訊息佇列銜接，實現序列執行，單個子事務占用資源的時間很短，併發度高。但這種最終一致性方案如果應用到銀行的應用中勢必影響使用者體驗，而且對應用侵略性較大，實施成本高。
在分析了以上事務處理方案的優缺點之後，根據銀行業務對實時一致性的要求，考慮到使用者體驗和實施成本的影響，我們提出了基於全域性事務id（global transaction id，以下簡稱gtid）的分布式事務解決方案。
基本原理
在基於gtid的分布式事務方案（以下簡稱本方案）中，我們把協調參與者和記錄全域性事務狀態這兩個功能分開，用計算節點協調各事務參與者進行事務操作，全域性事務管理器僅管理全域性事務的狀態。為了確保事務狀態正常，全域性事務管理採用了實時持久化和實時同步到備機等多重保障機制。本方案事務管理架構如圖1所示。
圖1 基於gtid的分布式事務管理方案
兩（三）階段提交的核心思想是通過前期的多次準備和協調工作，盡可能讓最後的提交操作能夠成功。而本方案認為大部分事務都可以一次提交成功，因此採用一階段提交+補償事務的方式，如果事務在提交階段有部分節點提交失敗，本方案將回滾已成功提交的事務，而不是讓失敗的節點不斷重試。與兩（三）階段提交相比，本方案在大部分情況下減少了與資料節點的互動次數，降低了鎖衝突概率，提公升了事務處理效率。
建表時增加乙個隱藏字段，用於記錄gtid。
每個事務開始時為其申請乙個gtid，該gtid是全域性唯一且單調遞增的，gtid申請成功後，我們稱該gtid為活躍（active）狀態，對應該gtid的事務狀態為未提交狀態，若涉及到資料更新，則將gtid更新到本事務將要更新的資料中，事務成功提交後，將gtid釋放，此時我們稱gtid為非活躍（unactive）狀態，對應的事務狀態為已提交狀態。
當事務提交失敗時，提交失敗節點會自動回滾，對於已成功提交的節點，需要將其回滾，資料恢復到更新前的狀態，全部節點回滾完成後，同樣需要將gtid釋放。
事務的原子性
保證事務的原子性是分布式事物的最大難點，在分布式環境下，保證事務原子性主要有兩種方案，一種是在提交命令發出後不回滾，盡可能保證提交成功；另一種是在提交命令發出後，根據響應結果判斷是提交成功還是該進行回滾。
我們採用的是第二種方式，由於我們的方案採用的是普通事務的提交方式，目前的主流資料庫在本地事務提交後都不能回滾，我們必須自己實現已提交事務的回滾。已提交事務回滾架構如圖2所示。
圖2 已提交事務回滾示意圖
在每個資料節點上部署乙個回滾模組用於已提交事務回滾，當部分資料節點提交失敗時，計算節點向已經提交成功的資料庫節點的回滾模組傳送已提交事務回滾命令，命令中包含事務對應的gtid，回滾模組根據gtid進行回滾，步驟如下：
由於該回滾操作不是資料庫原生回滾機制，在實際使用中需要經過大量優化才能保證回滾的效能達到可用級別。
事務的一致性
在單機資料庫事務中，事務的一致性是指事務的任何操作都不會使得資料違反資料庫定義的約束、觸發器等規則。在分布式資料庫中，由於資料分布在不同節點，有些約束難以保證，比如主鍵和唯一性約束，中信銀行當前實現的版本未從資料庫本身保證該約束的完整性，只能從使用規範角度進行約束，由應用保證主鍵和唯一索引的全域性唯一性。
事務的隔離性
事務隔離性的本質就是如何正確處理讀寫衝突和寫寫衝突，這在分布式事務中又是乙個難點，因為在我們的分布式事務控制方案中，可能會出現提交不同步的現象，這個時候就有可能出現「部分已經提交」的事務。一旦併發應用訪問「已經提交」節點中的資料，就需要根據gtid的狀態來判斷是「部分提交」還是「全部提交」，否則就出現了分布式資料庫中特有的一種「髒讀」。因此gtid方案可以確保分布式事務的隔離性。
事務的永續性
和單機一樣，分布式事務也需要保證事務的永續性，通過單節點資料的持久化和全域性事務狀態的持久化來完成，資料的持久化由單節點資料庫保證，全域性事務狀態的持久化由全域性事務管理器負責，全域性事務管理器採用定時全量和實時增量方式實現事務狀態的持久化：將gtid申請和釋放的動作實時寫到磁碟，同時每隔一定時間將全域性事務管理中的活躍gtid列表以非同步方式寫到磁碟，通過定時的全量活躍gtid列表和實時的增量記錄，可以獲得任意時刻的活躍gtid列表。
異常處理
分布式環境下，事務處理涉及的元件、伺服器和網路比單機複雜太多，各個環節都可能出現故障，因此異常處理也成為分布式事務的重點。根據故障環節的不同可分為資料節點異常、計算節點異常和全域性事務管理器異常。
資料節點異常
資料節點異常時，全域性事務將無法提交，已經提交的本地事務將會被回滾。具體考慮如下幾個場景（假設分布式事務涉及三個資料節點：db1、db2、db3，其中db2發生了異常）：
1. 分布式事務還未發起提交：向db1、db3發起回滾操作，db2的回滾由資料節點自身保證；
2. 分布式事務已經發起提交：db2上也已提交，但結果未知。此時需要向所有資料節點發起已提交事務回滾。
計算節點異常
分布式事務正常執行時，計算節點（假設為計算節點a）發生異常，與資料節點集群及客戶端的所有連線都已中斷，資料節點上未提交的事務由資料節點自動回滾。客戶端通過其他計算節點（假設為計算節點b）重新建立連線進行資料庫集群訪問，不會影響業務新發起的事務，但由於計算節點a異常時，處於部分已提交狀態的事務將無法結束，計算節點b上的事務一旦訪問到這些事務涉及的資料就會被阻塞，直到這些事務回滾。
具體考慮以下兩種場景：
1. 每台計算節點上部署監控程式，當計算節點異常時，監控程式將重啟計算節點，重啟完成後由計算節點自己與全域性事務管理器互動並完成異常事務的回滾；
2. 如果計算節點伺服器已經宕機且無法啟動或者監控程式無法重啟計算節點服務，則由計算節點管理器協調對等的計算節點（該集群的其他計算節點），完成異常事務的回滾。
全域性事務管理器異常
全域性事務管理器採用主備部署，申請或釋放gtid時通過實時同步到備機記憶體、實時增量持久化到本地磁碟、定時全量持久化三重保護機制確保全域性事務資訊不丟失。在單機異常時會進行主備切換，在雙機都異常時，需通過持久化的全域性事務資訊進行恢復。
組合異常
1. 組合異常，考慮如下兩種場景：
資料節點和計算節點同時異常。資料節點和計算節點走各自的異常處理流程即可解決問題，影響的是計算節點上的當前活躍事務以及涉及異常資料節點上的活躍事務的合集。
資料節點、計算節點和全域性事務管理器全部異常。此時全域性事務管理器上所有的gtid都需要回滾，可能需要先配置額外的計算節點，並通過計算節點管理器觸發所有活躍事務的2. 回滾。具體流程分析如下：
2-1. 所有未發起提交操作的分布式事務，資料節點恢復後將自動回滾；
2-2. 恢復計算節點，若計算節點不能恢復則需要配置額外的計算節點；
2-3. 由恢復後的計算節點或者計算節點管理器協調新的計算節點處理活躍事務的回滾，其中未發起提交操作的事務不會發生實際回滾動作（由第一步中的資料節點回滾），已經發起提交操作的事務將由資料節點上的回滾模組完成已提交事務的回滾。
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...
分布式事務 分布式事務的實現
如果在多個服務中需要對不同的資料庫進行操作。因為不同服務操作的資料庫都不同，所以保證在同乙個事務中完成操作顯然是不科學的。那實現分布式事務的思想 1 方法入口，建立一條日誌記錄，狀態定義為初始狀態，即儲存本條日誌記錄 可以儲存在資料庫中，也可以寫出到本地磁碟檔案 2 可以在非同步執行緒或在定時任務中...
分布式之分布式事務
被人問到分布式事務，之前學rabbitmq 的時候學到過rabbitmq 高階的事務，因為沒有用過，所有沒有回答好。這裡總結一下。1.單機版事務。事務的四大特性 acid a.原子性 b.一致性 c.隔離性 d.永續性 單機事務可以通過設定事務的隔離級別 參見spring 的事務隔離級別 2.分布式...