eBay技術人員最近展示了一種稱為GRIT的分散式事務協議，用於跨多個具有多個基礎資料庫的微服務進行ACID（原子性，一致性，隔離性，永續性）事務。

本文介紹了GRIT協議的基本思想，該思想在IEEE國際資料工程國際會議（ICDE）2019上宣佈，並提供了使用該協議的一部分為JanusGraph實現事務性儲存後端的示例。該示例著重於只有一個資料庫的系統，但是正如我們所說，GRIT可以支援由多個資料庫組成的系統的ACID事務。

背景

在微服務體系結構中，應用程式可以呼叫多個微服務，通常由不同的團隊以不同的應用語言實現這些微服務，並且可以使用多個基礎資料庫來實現其功能。這種流行的架構為跨多個微服務的一致的分散式事務帶來了新的挑戰。在微服務環境中支援ACID事務是一個真正的要求，但是使用現有技術很難實現，因為為單個資料庫設計的分散式事務機制無法通過微服務輕鬆擴充套件到具有多個資料庫的情況。

在涉及多個獨立資料庫的環境中，傳統的兩階段提交（2PC）協議1本質上是系統進行分散式事務處理的唯一選擇，而無需額外的應用程式工作。但是，由於潛在的許多協調參與者的路徑很長，並且在階段中需要鎖定，因此在橫向擴充套件平臺中無法很好地工作。另一方面，使用由 諸如Saga之類的框架2執行的事務日誌將招致應用程式複雜的補償邏輯，並且由於不可逆的部分成功的事務而可能產生業務影響。 

為了解決這些問題，我們開發了  GRIT，為全球統一的分散式事務的一個新的協議，它巧妙地結合樂觀併發控制（OCC）、2PC和確定性資料庫等想法 來實現的，這是一個高效能，具有多個基礎資料庫的跨微服務的全域性一致事務。

GRIT：一種用於分散式事務的協議

下圖說明了具有兩個資料庫的微服務系統中的GRIT協議。中心顯示了GRIT元件，包括GTM，GTL，DBTM，DBTL和LogPlayer。

1. 應用程式：呼叫微服務以實現其功能。
2. 微服務（實體服務）：構建模組，為應用程式提供面向業務的服務以實現業務邏輯。每個資料庫可能支援多個微服務，並且每個微服務可能彼此獨立。
3. 資料庫服務：提供資料庫讀寫介面，直接訪問資料庫伺服器。當支援事務時，它還在執行階段快取每個事務的讀/寫結果，並將它們傳送到其DBTM以在提交時解決衝突。
4. 資料庫分片伺服器：資料庫的後端儲存伺服器，通常進行復制以實現高可用性。

GRIT的關鍵元件包括：

1. 全域性事務管理器（GTM）：它協調多個資料庫之間的全域性事務。可以有一個或多個GTM。
2. 全域性事務日誌（GTL）：代表GTM的事務請求佇列。GTL中事務請求的順序確定了全域性事務之間的相對可序列化順序。GTL的永續性是可選的。
3. 資料庫事務管理器（DBTM）：每個資料庫領域的事務管理器。它執行衝突檢查和解決，即本地提交決定位於此處。
4. 資料庫事務日誌（DBTL）：每個資料庫領域中的事務日誌，用於記錄與此資料庫相關的邏輯提交的事務（包括單資料庫事務和多資料庫事務）。DBTL中的事務順序確定整個資料庫系統的可序列化順序，包括GTM規定的全域性順序。日誌序列號（LSN）被分配給每個日誌條目。
5. LogPlayer：此元件將日誌條目按順序傳送到後端儲存伺服器，以供它們應用更新。每個資料庫伺服器按順序應用邏輯提交的事務的日誌條目。

為了理解協議的細節，我們使用下圖顯示分散式事務的主要步驟。

在GRIT中，分散式事務經歷三個階段：

1. 樂觀執行（步驟1-4）：當應用程式通過微服務執行業務邏輯時，資料庫服務將捕獲事務的讀集和寫集。在此階段，沒有實際的資料修改發生。
2. 邏輯提交（步驟5-11）：一旦應用程式請求事務提交，每個資料庫服務點的讀集和寫集都將提交到其DBTM。DBTM使用讀集和寫集進行衝突檢查，以實現本地提交決策。GTM將收集DBTM針對事務的所有本地決策後，做出全域性提交決策。一旦將其寫集持久儲存在所涉及資料庫的日誌儲存（DBTL）中，就在邏輯上提交事務。這涉及GTM和DBTM之間的最小協調。
3. 物理應用（步驟12-13）：日誌播放器非同步將DBTL條目傳送到後端儲存伺服器。資料修改在此階段進行。 

總的來說，我們的方法避免了在執行和提交過程中的悲觀鎖定，並避免了等待物理提交。我們採用樂觀的方法，並且通過利用邏輯提交日誌並使用確定性資料庫技術將物理資料庫更改從提交決策過程中移出，從而使提交過程非常高效，這類似於複製中的日誌播放。

GRIT能夠以最小的協調性為呼叫微服務的應用程式實現一致的高吞吐量和可序列化的分散式事務。GRIT非常適合很少衝突的事務，併為否則需要複雜機制才能在具有多個基礎資料庫的微服務之間實現一致事務的應用程式提供關鍵功能。

將GRIT應用於單個資料庫

如您所見，GRIT協議包含兩個部分：一個部分用於由DBTM，DBTL和LogPlayer執行的每個資料庫（或每個資料庫領域，可以是資料庫的一組分割槽），另一部分用於跨資料庫協調通過GTM和DBTM。在下圖中，我們使用單個資料庫的GRIT協議部分說明了JanusGraph的事務圖儲存後端（稱為NuGraphStore）的設計。

下圖顯示瞭如何使用兩個可用區（AZ1和AZ2）部署實施NuGraphStore。

JanusGraph的NuGraphStore後端涉及一些元件：

• 儲存外掛：一個自定義的儲存介面外掛，用於在JanusGraph資料庫層與後端儲存引擎和事務協議元件之間建立介面。
• DBTM：執行關鍵衝突檢查以實現樂觀併發控制。這是執行OCC的單個資料庫上GRIT分散式事務協議的一部分  。
• LogStore：複製的日誌儲存，用於事務的突變。每個事務一個條目，由日誌序列號（LSN）索引。在傳統資料庫系統中，它充當WAL（預寫日誌）。LogStore是我們GRIT架構中的DBTL。 
• LogPlayer：非同步將日誌條目應用於後端伺服器。
• 儲存引擎：後端儲存引擎，用於儲存JanusGraph中的KCV（鍵-列-值）資料。它執行讀取和變異，並支援LSN定義的快照。

當應用程式執行事務時，它可以從store中讀取並寫入store。對於讀取操作，儲存外掛直接與儲存伺服器通訊（除了在事務的寫入集中找到的讀取之外）。當應用程式在事務上下文中從儲存中讀取時，儲存外掛還會跟蹤讀取集。每次讀取的有用資訊是<key，lsn>對，其中lsn是反映在讀取鍵值時儲存引擎狀態的日誌序列號。LSN是事務突變條目的日誌索引。它由LogStore分配，用於定義後端資料庫的快照。未找到的鍵key被記錄為讀取集的一部分。與讀取不同，用於寫入的儲存外掛不會直接與儲存伺服器通訊。相反，儲存外掛會在事務的相應寫入集中緩衝寫入操作。

事務提交時，儲存外掛將提交的請求和已為事務捕獲的讀集和寫集提交給DBTM。DBTM對事務的OCC執行標準衝突檢查。如果沒有衝突，它將把寫集保留到複製的LogStore中（即，它將寫集傳送到LogStore副本集，因此所有副本都保持完全相同的日誌）。此時，事務提交將在邏輯上完成，並且DBTM將響應儲存外掛。LogPlayers跟蹤LogStore，並根據資料分佈將日誌條目播放到後端分片伺服器。

值得指出的是，以上描述是一種基本設計，具有許多提高效能和可靠性的機會。我們相信，在對各個元件進行優化或對DBTM使用複製以實現更高的可靠性之前，使基本元件成熟將更有生產力。同樣，我們可以通過不同的方式捕獲讀集和寫集。對於KV Store，衝突檢查所需的最簡單形式是<key，lsn>對。但是，為了支援更復雜的系統，該讀取集可能包含範圍或謂詞，如第6章所述。 在撰寫本文時，NuGraphStore正在經歷開源過程。

點選標題參考原文。