微服務架構下分散式事務解決方案-hoop（一）

前言

資料庫事務（ 簡稱：事務，Transaction ）是指資料庫執行過程中的一個邏輯單位，由一個有限的資料庫操作序列構成。

事務擁有以下四個特性，習慣上被稱為 ACID 特性：

• 原子性（Atomicity）：事務作為一個整體被執行，包含在其中的對資料庫的操作要麼全部被執行，要麼都不執行。

• 一致性（Consistency）：事務應確保資料庫的狀態從一個一致狀態轉變為另一個一致狀態。一致狀態是指資料庫中的資料應滿足完整性約束。除此之外，一致性還有另外一層語義，就是事務的中間狀態不能被觀察到（這層語義也有說應該屬於原子性）。

• 隔離性（Isolation）：多個事務併發執行時，一個事務的執行不應影響其他事務的執行，如同只有這一個操作在被資料庫所執行一樣。

• 永續性（Durability）：已被提交的事務對資料庫的修改應該永久儲存在資料庫中。在事務結束時，此操作將不可逆轉。

什麼是分散式事務 ？

分散式事務就是指事務的參與者、支援事務的伺服器、資源伺服器以及事務管理器分別位於不同的分散式系統的不同節點之上。簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分佈在不同的伺服器上，且屬於不同的應用，分散式事務需要保證這些小操作要麼全部成功，要麼全部失敗。本質上來說，分散式事務就是為了保證不同資料庫的資料一致性。

先來了解一下廣為人知的 CAP 和 BASE 理論

分散式事務

常見解決方案

二階段協議，三階段協議，MQ 事務訊息，補償，Saga，TCC等。本篇我們重點分享下TCC 的實現。

什麼是 TCC ?

1. Try：完成所有業務檢查，預留必須的業務資源，保證冪等性。

2. Confirm：真正執行的業務邏輯，不作任何業務檢查，只使用 Try 階段預留的業務資源。因此，只要 Try 操作成功，Confirm 必須能成功。另外，Confirm 操作需滿足冪等性。

3. Cancel：釋放 Try 階段預留的業務資源。同樣的，Cancel 操作也需要滿足冪等性。

TCC 分散式事務模型包括三部分：

1. 主業務服務（全域性事務）：主業務服務為整個業務活動的發起方，服務的編排者，負責發起並完成整個業務活動。

2. 從業務服務（分支事務）：從業務服務是整個業務活動的參與方，負責提供 TCC 業務操作，實現初步操作（Try）、確認操作（Confirm）、取消操作（Cancel）三個介面，供主業務服務呼叫。

3. 業務活動管理器（事務管理器）：業務活動管理器管理控制整個業務活動，包括記錄維護 TCC 全域性事務的事務狀態和每個從業務服務的子事務狀態，並在業務活動提交時呼叫所有從業務服務的 Confirm 操作，在業務活動取消時呼叫所有從業務服務的 Cancel 操作。

在設計一個分散式事務元件中，應該考慮哪些問題 ？

• 任何機器斷電，crash怎麼辦？

• 網路節點問題如何處理？

• 什麼時候提交|回滾全域性事務？

走進 Hoop

瞭解 Hoop 之前，我簡單先給大家介紹一些名詞解釋，預設約束 

名詞解釋：

• GlobalTransaction：全域性事務（跟隨主業務服務）

• BranchTransaction：分支事務（跟隨從業務服務）

• GlobalTransactionStateConfirm：全域性事務狀態確認器【恢復事務需要】

約定俗成

• 全域性事務執行過程中沒有任何異常，commit 全域性事務

• 全域性事務方法中丟擲異常(非指定異常)，直接回滾掉丟擲異常前所有執行的分支事務，全域性事務回滾。

• hoop 推薦將網路超時的異常配置到 [delayHandleStep2Exceptions] 碰到這類異常，hoop 需要事務狀態翻查器來決定事務提交|回滾。

• hoop 推薦一定要為每一個全域性事務配置一個 [GlobalTransactionStateConfirm] 以免異常情況下，錯誤的回滾掉了本該提交的事務。

Hoop 核心角色

• TransactionInterceptor（全域性事務攔截器）：管理全域性事務，推進事務生命週期

• CoordinatorInterceptor（分支事務協調者攔截器）：協調分支事務和全域性事務

• HoopRecoverBootStrap（恢復啟動器）：管理，恢復異常事務

• AbstractHoopStorageBootStrap（事務記錄儲存引擎）：儲存全域性事務和分支事務記錄。

為什麼 Hoop 高效能高吞吐量 ？

1. 有很多 tcc 的文章中會常常提到 TransactionSynchronizationAdapter，用資料庫的事務來推動二階段執行。Hoop 完全摒棄了這一點，原因在於如果使用資料庫的事務來推動分散式事務的二階段，在T階段分支事務較多的場景下，長事務會給 db 帶來很大的資源消耗，會成為效能瓶頸。Hoop 所有執行節點都不會鎖定 db 資源，沒有長事務。而且 hoop目前提供了mysql 的儲存引擎，支援使用者重寫事務記錄的儲存引擎，redis，mongodb的引擎正在實現中。

2. Hoop 的恢復支援應用的所有機器並行，單臺機器併發恢復，而且很好的控制了機器的資源。

3. Hoop 支援二階段的非同步提交。

下面是 Hoop 寫一串虛擬碼，盧雲（招行卡）給小強（建行卡）轉賬100元

• example1：A.doTry 成功，B.doTry 成功，hoop 自動提交 A.confirm B.confirm

• example2：A.doTry 成功，B.doTry 失敗，hoop 自動回滾 A.cancel B.cancel

• example3：A.doTry 失敗，hoop 自動執行 A.cancel

Hoop 異常情況分析

Hoop 的異常事務恢復

• 單個應用，所有部署的例項都可以並行恢復異常全域性事務，提高系統吞吐量，節約機器資源。

• 事務恢復器主要是通過事務翻查器來推進全域性事務的狀態。

總結

TCC 分散式事務模型的業務實現特性決定了其可以跨 DB、跨服務實現資源管理，將對不同的 DB 訪問、不同的業務操作通過 TCC 模型協調為一個原子操作，解決了分散式應用架構場景下的事務問題。TCC 模型也可以根據業務需要，做一些定製化的功能，比如交易非同步化實現削峰填谷等。但是，業務接入 TCC 模型需要拆分業務邏輯成兩個階段，並實現 Try、Confirm、Cancel 三個介面，定製化程度高，開發成本高。

使用場景：由於從業務服務是同步呼叫，其結果會影響到主業務服務的決策，因此通用型 TCC 分散式事務解決方案適用於執行時間確定且較短的業務，比如網際網路金融企業最核心的三個服務：交易、支付、賬務。

後續給大家分享 hoop 的整體架構以及使用。

作者簡介

雨人，銅板街交易團隊研發工程師，2016 年 5 月加入團隊，目前主要負責資金端專案的開發。