*作者：朱晉君*

大家好，我是君哥。

今天來聊一聊阿里巴巴 Seata 新版本（1.5.1）是怎麼解決 TCC 模式下的冪等、懸掛和空回滾問題的。

## TCC 回顧

TCC 模式是最經典的分散式事務解決方案，它將分散式事務分為兩個階段來執行，try 階段對每個分支事務進行預留資源，如果所有分支事務都預留資源成功，則進入 commit 階段提交全域性事務，如果有一個節點預留資源失敗則進入 cancel 階段回滾全域性事務。

以傳統的訂單、庫存、賬戶服務為例，在 try 階段嘗試預留資源，插入訂單、扣減庫存、扣減金額，這三個服務都是要提交本地事務的，這裡可以把資源轉入中間表。在 commit 階段，再把 try 階段預留的資源轉入最終表。而在 cancel 階段，把 try 階段預留的資源進行釋放，比如把賬戶金額返回給客戶的賬戶。

注意：try 階段必須是要提交本地事務的，比如扣減訂單金額，必須把錢從客戶賬戶扣掉，如果不扣掉，在 commit 階段客戶賬戶錢不夠了，就會出問題。

### try-commit

try 階段首先進行預留資源，然後在 commit 階段扣除資源。如下圖：

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b1dc1b880cd941e5b5033e2857fee14c~tplv-k3u1fbpfcp-zoom-1.image "1.png")

### try-cancel

try 階段首先進行預留資源，預留資源時扣減庫存失敗導致全域性事務回滾，在 cancel 階段釋放資源。如下圖：

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4be30b0c1121423d9af2a314cdefc5f0~tplv-k3u1fbpfcp-zoom-1.image "2.png")

## TCC 優勢

TCC 模式最大的優勢是效率高。TCC 模式在 try 階段的鎖定資源並不是真正意義上的鎖定，而是真實提交了本地事務，將資源預留到中間態，並不需要阻塞等待，因此效率比其他模式要高。

同時 TCC 模式還可以進行如下最佳化：

### 非同步提交

try 階段成功後，不立即進入 confirm/cancel 階段，而是認為全域性事務已經結束了，啟動定時任務來非同步執行 confirm/cancel，扣減或釋放資源，這樣會有很大的效能提升。

### 同庫模式

TCC 模式中有三個角色：

-   TM：管理全域性事務，包括開啟全域性事務，提交/回滾全域性事務；
-   RM：管理分支事務；
-   TC: 管理全域性事務和分支事務的狀態。

下圖來自 Seata 官網：

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/64469ca36ede4f14a5041ae872676d32~tplv-k3u1fbpfcp-zoom-1.image "3.png")

TM 開啟全域性事務時，RM 需要向 TC 傳送註冊訊息，TC 儲存分支事務的狀態。TM 請求提交或回滾時，TC 需要向 RM 傳送提交或回滾訊息。這樣包含兩個個分支事務的分散式事務中，TC 和 RM 之間有四次 RPC。

最佳化後的流程如下圖：

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/56f53b393fb34e8d81f29d883e4202a1~tplv-k3u1fbpfcp-zoom-1.image "4.png")

TC 儲存全域性事務的狀態。TM 開啟全域性事務時，RM 不再需要向 TC 傳送註冊訊息，而是把分支事務狀態儲存在了本地。TM 向 TC 傳送提交或回滾訊息後，RM 非同步執行緒首先查出本地儲存的未提交分支事務，然後向 TC 傳送訊息獲取（本地分支事務所在的）全域性事務狀態，以決定是提交還是回滾本地事務。

這樣最佳化後，RPC 次數減少了 50%，效能大幅提升。

## RM 程式碼示例

以庫存服務為例，RM 庫存服務介面程式碼如下：

```
@LocalTCC
public interface StorageService {

/**
     * 扣減庫存
     * @param xid 全域性xid
     * @param productId 產品id
     * @param count 數量
     * @return
     */
    @TwoPhaseBusinessAction(name = "storageApi", commitMethod = "commit", rollbackMethod = "rollback", useTCCFence = true)
    boolean decrease(String xid, Long productId, Integer count);

/**
     * 提交事務
     * @param actionContext
     * @return
     */
    boolean commit(BusinessActionContext actionContext);

/**
     * 回滾事務
     * @param actionContext
     * @return
     */
    boolean rollback(BusinessActionContext actionContext);
}
```

透過 @LocalTCC 這個註解，RM 初始化的時候會向 TC 註冊一個分支事務。在 try 階段的方法（decrease方法）上有一個 @TwoPhaseBusinessAction 註解，這裡定義了分支事務的 resourceId，commit 方法和 cancel 方法，useTCCFence 這個屬性下一節再講。

## TCC 存在問題

TCC 模式中存在的三大問題是冪等、懸掛和空回滾。在 Seata1.5.1 版本中，增加了一張事務控制表，表名是 tcc_fence_log 來解決這個問題。而在上一節 @TwoPhaseBusinessAction 註解中提到的屬性 useTCCFence 就是來指定是否開啟這個機制，這個屬性值預設是 false。

tcc_fence_log 建表語句如下（MySQL 語法）：

```
CREATE TABLE IF NOT EXISTS `tcc_fence_log`
(
    `xid`           VARCHAR(128)  NOT NULL COMMENT 'global id',
    `branch_id`     BIGINT        NOT NULL COMMENT 'branch id',
    `action_name`   VARCHAR(64)   NOT NULL COMMENT 'action name',
    `status`        TINYINT       NOT NULL COMMENT 'status(tried:1;committed:2;rollbacked:3;suspended:4)',
    `gmt_create`    DATETIME(3)   NOT NULL COMMENT 'create time',
    `gmt_modified`  DATETIME(3)   NOT NULL COMMENT 'update time',
    PRIMARY KEY (`xid`, `branch_id`),
    KEY `idx_gmt_modified` (`gmt_modified`),
    KEY `idx_status` (`status`)
) ENGINE = InnoDB
DEFAULT CHARSET = utf8mb4;
```

### 冪等

在 commit/cancel 階段，因為 TC 沒有收到分支事務的響應，需要進行重試，這就要分支事務支援冪等。

我們看一下新版本是怎麼解決的。下面的程式碼在 TCCResourceManager 類：

```
@Override
public BranchStatus branchCommit(BranchType branchType, String xid, long branchId, String resourceId,
         String applicationData) throws TransactionException {
 TCCResource tccResource = (TCCResource)tccResourceCache.get(resourceId);
 //省略判斷
 Object targetTCCBean = tccResource.getTargetBean();
 Method commitMethod = tccResource.getCommitMethod();
 //省略判斷
 try {
  //BusinessActionContext
  BusinessActionContext businessActionContext = getBusinessActionContext(xid, branchId, resourceId,
   applicationData);
  Object[] args = this.getTwoPhaseCommitArgs(tccResource, businessActionContext);
  Object ret;
  boolean result;
  //註解 useTCCFence 屬性是否設定為 true
  if (Boolean.TRUE.equals(businessActionContext.getActionContext(Constants.USE_TCC_FENCE))) {
   try {
    result = TCCFenceHandler.commitFence(commitMethod, targetTCCBean, xid, branchId, args);
   } catch (SkipCallbackWrapperException | UndeclaredThrowableException e) {
    throw e.getCause();
   }
  } else {
   //省略邏輯
  }
  LOGGER.info("TCC resource commit result : {}, xid: {}, branchId: {}, resourceId: {}", result, xid, branchId, resourceId);
  return result ? BranchStatus.PhaseTwo_Committed : BranchStatus.PhaseTwo_CommitFailed_Retryable;
 } catch (Throwable t) {
  //省略
  return BranchStatus.PhaseTwo_CommitFailed_Retryable;
 }
}
```

上面的程式碼可以看到，執行分支事務提交方法時，首先判斷 useTCCFence 屬性是否為 true，如果為 true，則走 TCCFenceHandler 類中的 commitFence 邏輯，否則走普通提交邏輯。

TCCFenceHandler 類中的 commitFence 方法呼叫了 TCCFenceHandler 類的 commitFence 方法，程式碼如下：

```
public static boolean commitFence(Method commitMethod, Object targetTCCBean,
          String xid, Long branchId, Object[] args) {
 return transactionTemplate.execute(status -> {
  try {
   Connection conn = DataSourceUtils.getConnection(dataSource);
   TCCFenceDO tccFenceDO = TCC_FENCE_DAO.queryTCCFenceDO(conn, xid, branchId);
   if (tccFenceDO == null) {
    throw new TCCFenceException(String.format("TCC fence record not exists, commit fence method failed. xid= %s, branchId= %s", xid, branchId),
      FrameworkErrorCode.RecordAlreadyExists);
   }
   if (TCCFenceConstant.STATUS_COMMITTED == tccFenceDO.getStatus()) {
    LOGGER.info("Branch transaction has already committed before. idempotency rejected. xid: {}, branchId: {}, status: {}", xid, branchId, tccFenceDO.getStatus());
    return true;
   }
   if (TCCFenceConstant.STATUS_ROLLBACKED == tccFenceDO.getStatus() || TCCFenceConstant.STATUS_SUSPENDED == tccFenceDO.getStatus()) {
    if (LOGGER.isWarnEnabled()) {
     LOGGER.warn("Branch transaction status is unexpected. xid: {}, branchId: {}, status: {}", xid, branchId, tccFenceDO.getStatus());
    }
    return false;
   }
   return updateStatusAndInvokeTargetMethod(conn, commitMethod, targetTCCBean, xid, branchId, TCCFenceConstant.STATUS_COMMITTED, status, args);
  } catch (Throwable t) {
   status.setRollbackOnly();
   throw new SkipCallbackWrapperException(t);
  }
 });
}
```

從程式碼中可以看到，提交事務時首先會判斷 tcc_fence_log 表中是否已經有記錄，如果有記錄，則判斷事務執行狀態並返回。這樣如果判斷到事務的狀態已經是 STATUS_COMMITTED，就不會再次提交，保證了冪等。如果 tcc_fence_log 表中沒有記錄，則插入一條記錄，供後面重試時判斷。

Rollback 的邏輯跟 commit 類似，邏輯在類 TCCFenceHandler 的 rollbackFence 方法。

### 空回滾

如下圖，賬戶服務是兩個節點的叢集，在 try 階段賬戶服務 1 這個節點發生了故障，try 階段在不考慮重試的情況下，全域性事務必須要走向結束狀態，這樣就需要在賬戶服務上執行一次 cancel 操作，這樣就空跑了一次回滾操作。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/99002e34c6b54b8487eed7216bd5c1ba~tplv-k3u1fbpfcp-zoom-1.image "5.png")

Seata 的解決方案是在 try 階段 往 tcc_fence_log  表插入一條記錄，status 欄位值是 STATUS_TRIED，在 Rollback 階段判斷記錄是否存在，如果不存在，則不執行回滾操作。程式碼如下：

```
//TCCFenceHandler 類
public static Object prepareFence(String xid, Long branchId, String actionName, Callback<object> targetCallback) {
 return transactionTemplate.execute(status -> {
  try {
   Connection conn = DataSourceUtils.getConnection(dataSource);
   boolean result = insertTCCFenceLog(conn, xid, branchId, actionName, TCCFenceConstant.STATUS_TRIED);
   LOGGER.info("TCC fence prepare result: {}. xid: {}, branchId: {}", result, xid, branchId);
   if (result) {
    return targetCallback.execute();
   } else {
    throw new TCCFenceException(String.format("Insert tcc fence record error, prepare fence failed. xid= %s, branchId= %s", xid, branchId),
      FrameworkErrorCode.InsertRecordError);
   }
  } catch (TCCFenceException e) {
   //省略
  } catch (Throwable t) {
   //省略
  }
 });
}
```

在 Rollback 階段的處理邏輯如下:

```
//TCCFenceHandler 類
public static boolean rollbackFence(Method rollbackMethod, Object targetTCCBean,
         String xid, Long branchId, Object[] args, String actionName) {
 return transactionTemplate.execute(status -> {
  try {
   Connection conn = DataSourceUtils.getConnection(dataSource);
   TCCFenceDO tccFenceDO = TCC_FENCE_DAO.queryTCCFenceDO(conn, xid, branchId);
   // non_rollback
   if (tccFenceDO == null) {
    //不執行回滾邏輯
    return true;
   } else {
    if (TCCFenceConstant.STATUS_ROLLBACKED == tccFenceDO.getStatus() || TCCFenceConstant.STATUS_SUSPENDED == tccFenceDO.getStatus()) {
     LOGGER.info("Branch transaction had already rollbacked before, idempotency rejected. xid: {}, branchId: {}, status: {}", xid, branchId, tccFenceDO.getStatus());
     return true;
    }
    if (TCCFenceConstant.STATUS_COMMITTED == tccFenceDO.getStatus()) {
     if (LOGGER.isWarnEnabled()) {
      LOGGER.warn("Branch transaction status is unexpected. xid: {}, branchId: {}, status: {}", xid, branchId, tccFenceDO.getStatus());
     }
     return false;
    }
   }
   return updateStatusAndInvokeTargetMethod(conn, rollbackMethod, targetTCCBean, xid, branchId, TCCFenceConstant.STATUS_ROLLBACKED, status, args);
  } catch (Throwable t) {
   status.setRollbackOnly();
   throw new SkipCallbackWrapperException(t);
  }
 });
}
```

updateStatusAndInvokeTargetMethod 方法執行的 sql 如下：

```
update tcc_fence_log set status = ?, gmt_modified = ?
    where xid = ? and  branch_id = ? and status = ? ;
```

可見就是把 tcc_fence_log 表記錄的  status  欄位值從 STATUS_TRIED 改為 STATUS_ROLLBACKED，如果更新成功，就執行回滾邏輯。

### 懸掛

懸掛是指因為網路問題，RM 開始沒有收到 try 指令，但是執行了 Rollback 後 RM 又收到了 try 指令並且預留資源成功，這時全域性事務已經結束，最終導致預留的資源不能釋放。如下圖：

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d085899eb76c4a41962c40a05a61fabe~tplv-k3u1fbpfcp-zoom-1.image "6.png")

Seata 解決這個問題的方法是執行 Rollback 方法時先判斷 tcc_fence_log 是否存在當前 xid 的記錄，如果沒有則向 tcc_fence_log 表插入一條記錄，狀態是 STATUS_SUSPENDED，並且不再執行回滾操作。程式碼如下：

```
public static boolean rollbackFence(Method rollbackMethod, Object targetTCCBean,
         String xid, Long branchId, Object[] args, String actionName) {
 return transactionTemplate.execute(status -> {
  try {
   Connection conn = DataSourceUtils.getConnection(dataSource);
   TCCFenceDO tccFenceDO = TCC_FENCE_DAO.queryTCCFenceDO(conn, xid, branchId);
   // non_rollback
   if (tccFenceDO == null) {
       //插入防懸掛記錄
    boolean result = insertTCCFenceLog(conn, xid, branchId, actionName, TCCFenceConstant.STATUS_SUSPENDED);
    //省略邏輯
    return true;
   } else {
    //省略邏輯
   }
   return updateStatusAndInvokeTargetMethod(conn, rollbackMethod, targetTCCBean, xid, branchId, TCCFenceConstant.STATUS_ROLLBACKED, status, args);
  } catch (Throwable t) {
   //省略邏輯
  }
 });
}
```

而後面執行 try 階段方法時首先會向 tcc_fence_log 表插入一條當前 xid 的記錄，這樣就造成了主鍵衝突。程式碼如下：

```
//TCCFenceHandler 類
public static Object prepareFence(String xid, Long branchId, String actionName, Callback<object> targetCallback) {
 return transactionTemplate.execute(status -> {
  try {
   Connection conn = DataSourceUtils.getConnection(dataSource);
   boolean result = insertTCCFenceLog(conn, xid, branchId, actionName, TCCFenceConstant.STATUS_TRIED);
   //省略邏輯
  } catch (TCCFenceException e) {
   if (e.getErrcode() == FrameworkErrorCode.DuplicateKeyException) {
    LOGGER.error("Branch transaction has already rollbacked before,prepare fence failed. xid= {},branchId = {}", xid, branchId);
    addToLogCleanQueue(xid, branchId);
   }
   status.setRollbackOnly();
   throw new SkipCallbackWrapperException(e);
  } catch (Throwable t) {
   //省略
  }
 });
}
```

注意：queryTCCFenceDO 方法 sql 中使用了 for update，這樣就不用擔心 Rollback 方法中獲取不到 tcc_fence_log 表記錄而無法判斷 try 階段本地事務的執行結果了。

## 總結

TCC 模式是分散式事務使用最多的模式，但是冪等、懸掛和空回滾一直是 TCC 模式需要考慮的問題，Seata 框架在 1.5.1 版本完美解決了這些問題。

對 tcc_fence_log 表的操作也需要考慮事務的控制，Seata 使用了代理資料來源，使 tcc_fence_log 表操作和 RM 業務操作在同一個本地事務中執行，這樣就能保證本地操作和對 tcc_fence_log 的操作同時成功或失敗。</object></object>

阿里 Seata 新版本終於解決了 TCC 模式的冪等、懸掛和空回滾問題

相關文章