微服務架構下分佈式事務解決方案-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 月加入團隊，目前主要負責資金端項目的開發。

                                  

                      更多精彩內容，請掃碼關注 「銅板街科技」 微信公衆號。