Seata分布式事務(wù)出現(xiàn)ABA問題解決

更新時間：2022年11月09日 16:26:13 作者：夢想實現(xiàn)家_Z

這篇文章主要為大家介紹了Seata分布式事務(wù)出現(xiàn)ABA問題解決方法示例，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

前言

兄弟們，最近處理了一個seata的issue，關(guān)于seata分布式事務(wù)長期回滾失敗后，突然回滾成功了：

這個問題的出現(xiàn)需要以下兩個契機：

在執(zhí)行分布式事務(wù)期間，有本地事務(wù)與分布式事務(wù)操作同一張表中的數(shù)據(jù)導(dǎo)致臟寫產(chǎn)生；
在回滾時，seata對比afterImage與當(dāng)前數(shù)據(jù)不一致，導(dǎo)致回滾失敗，此時會一直重試；
當(dāng)手工校準(zhǔn)數(shù)據(jù)后，某一時刻afterImage與當(dāng)前數(shù)據(jù)一致，此時回滾重試成功，ABA問題產(chǎn)生；

從源碼中定位原因

為了避免ABA問題的產(chǎn)生，通過與seata社區(qū)的大佬討論，最終決定在回滾時，如果對比afterImage與當(dāng)前數(shù)據(jù)不一致的情況下，不再嘗試回滾重試。這樣的話，即使后續(xù)通過人工校準(zhǔn)后，也不會回滾了。但是這樣有另一個問題，就是人工校準(zhǔn)后，這個分布式事務(wù)就一直遺留在數(shù)據(jù)庫中無法刪除了。針對這個問題，seata應(yīng)該要提供一個restful api讓開發(fā)人員在數(shù)據(jù)校準(zhǔn)后能夠刪除掉對應(yīng)的分布式事務(wù)數(shù)據(jù)。

在seata源碼中，如果校驗afterImage與當(dāng)前數(shù)據(jù)不一致后，會拋出SQLException，最終會被上層代碼捕獲包裝成BranchTransactionException異常，但是里面的code屬性是BranchRollbackFailed_Retriable，這也是導(dǎo)致seata一直重試回滾的根本原因：

Result<Boolean> afterEqualsCurrentResult = DataCompareUtils.isRecordsEquals(afterRecords, currentRecords);
        if (!afterEqualsCurrentResult.getResult()) {
            // 先比較afterImage與當(dāng)前數(shù)據(jù)，如果不一致，那么再比較當(dāng)前數(shù)據(jù)和beforeImage是否一致
            Result<Boolean> beforeEqualsCurrentResult = DataCompareUtils.isRecordsEquals(beforeRecords, currentRecords);
            // 如果當(dāng)前數(shù)據(jù)和beforeImage一致，那么不需要回滾了，因為相當(dāng)于已經(jīng)回滾了
            if (beforeEqualsCurrentResult.getResult()) {
                if (LOGGER.isInfoEnabled()) {
                    LOGGER.info("Stop rollback because there is no data change " +
                            "between the before data snapshot and the current data snapshot.");
                }
                // no need continue undo.
                return false;
            } else {
                // 否則，直接拋出SQLException，并告知undo log臟寫了
                if (LOGGER.isInfoEnabled()) {
                    if (StringUtils.isNotBlank(afterEqualsCurrentResult.getErrMsg())) {
                        LOGGER.info(afterEqualsCurrentResult.getErrMsg(), afterEqualsCurrentResult.getErrMsgParams());
                    }
                }
                if (LOGGER.isDebugEnabled()) {
                    LOGGER.debug("check dirty data failed, old and new data are not equal, " +
                            "tableName:[" + sqlUndoLog.getTableName() + "]," +
                            "oldRows:[" + JSON.toJSONString(afterRecords.getRows()) + "]," +
                            "newRows:[" + JSON.toJSONString(currentRecords.getRows()) + "].");
                }
                throw new SQLException("Has dirty records when undo.");
            }
        }

在上層調(diào)用代碼中，我們可以找到這樣一段：

catch (Throwable e) {
    if (conn != null) {
        try {
            conn.rollback();
        } catch (SQLException rollbackEx) {
            LOGGER.warn("Failed to close JDBC resource while undo ... ", rollbackEx);
        }
    }
    // 包裝異常
    throw new BranchTransactionException(BranchRollbackFailed_Retriable, String
                    .format("Branch session rollback failed and try again later xid = %s branchId = %s %s", xid,
                        branchId, e.getMessage()), e);
}

根據(jù)源碼分析，我們發(fā)現(xiàn)在數(shù)據(jù)校驗后拋出的SQLException會被包裝成code屬性為BranchRollbackFailed_Retriable的BranchTransactionException異常，這樣會導(dǎo)致seata不斷重試回滾操作。

如何處理

我們需要將這個SQLException調(diào)整為一個更加具體的異常，比如SQLUndoDirtyException這種能夠明確地表示undo log被臟寫的異常，另外我們在上層代碼中同樣需要針對SQLUndoDirtyException做特殊處理，比如包裝成new BranchTransactionException(BranchRollbackFailed_Unretriable)不可重試的狀態(tài)。

先創(chuàng)建自定義的異常：SQLUndoDirtyException

import java.io.Serializable;
import java.sql.SQLException;
/**
 * @author zouwei
 */
class SQLUndoDirtyException extends SQLException implements Serializable {
    private static final long serialVersionUID = -5168905669539637570L;
    SQLUndoDirtyException(String reason) {
        super(reason);
    }
}

調(diào)整SQLException為SQLUndoDirtyException:

Result<Boolean> afterEqualsCurrentResult = DataCompareUtils.isRecordsEquals(afterRecords, currentRecords);
        if (!afterEqualsCurrentResult.getResult()) {
            // 先比較afterImage與當(dāng)前數(shù)據(jù)，如果不一致，那么再比較當(dāng)前數(shù)據(jù)和beforeImage是否一致
            Result<Boolean> beforeEqualsCurrentResult = DataCompareUtils.isRecordsEquals(beforeRecords, currentRecords);
            // 如果當(dāng)前數(shù)據(jù)和beforeImage一致，那么不需要回滾了，因為相當(dāng)于已經(jīng)回滾了
            if (beforeEqualsCurrentResult.getResult()) {
                if (LOGGER.isInfoEnabled()) {
                    LOGGER.info("Stop rollback because there is no data change " +
                            "between the before data snapshot and the current data snapshot.");
                }
                // no need continue undo.
                return false;
            } else {
                // 否則，直接拋出SQLException，并告知undo log臟寫了
                if (LOGGER.isInfoEnabled()) {
                    if (StringUtils.isNotBlank(afterEqualsCurrentResult.getErrMsg())) {
                        LOGGER.info(afterEqualsCurrentResult.getErrMsg(), afterEqualsCurrentResult.getErrMsgParams());
                    }
                }
                if (LOGGER.isDebugEnabled()) {
                    LOGGER.debug("check dirty data failed, old and new data are not equal, " +
                            "tableName:[" + sqlUndoLog.getTableName() + "]," +
                            "oldRows:[" + JSON.toJSONString(afterRecords.getRows()) + "]," +
                            "newRows:[" + JSON.toJSONString(currentRecords.getRows()) + "].");
                }
                // 替換為具體的SQLUndoDirtyException異常
                throw new SQLUndoDirtyException("Has dirty records when undo.");
            }
        }

這樣的話，我們在上層代碼中，就可以針對性地處理了：

catch (Throwable e) {
    if (conn != null) {
        try {
            conn.rollback();
        } catch (SQLException rollbackEx) {
            LOGGER.warn("Failed to close JDBC resource while undo ... ", rollbackEx);
        }
     }
     // 如果捕捉的異常為SQLUndoDirtyException，那么包裝為BranchRollbackFailed_Unretriable
     if (e instanceof SQLUndoDirtyException) {
         throw new BranchTransactionException(BranchRollbackFailed_Unretriable, String.format(
                        "Branch session rollback failed because of dirty undo log, please delete the relevant undolog after manually calibrating the data. xid = %s branchId = %s",
                        xid, branchId), e);
      }
      throw new BranchTransactionException(BranchRollbackFailed_Retriable,
                    String.format("Branch session rollback failed and try again later xid = %s branchId = %s %s", xid,
                        branchId, e.getMessage()),
                    e);
}

我們在上層調(diào)用代碼中捕捉指定的SQLUndoDirtyException，直接包裝為BranchRollbackFailed_Unretriable狀態(tài)的BranchTransactionException，這樣我們的分布式事務(wù)就不會一直重試回滾操作了。

下一步就需要開發(fā)人員人工介入校準(zhǔn)數(shù)據(jù)后刪除對應(yīng)的undo log，在一系列操作處理完畢后，另外還需要seata tc端提供對應(yīng)的restful api開放對應(yīng)的手工觸發(fā)回滾的操作，以便保證校準(zhǔn)后的分布式事務(wù)正常結(jié)束。

小結(jié)

我們根據(jù)seata使用人員反饋的問題，通過源碼分析找到了造成問題的原因：

開發(fā)人員在使用seata的時候，對于同一張表的操作沒有使用@GlobalTransactional注解覆蓋到，導(dǎo)致了undo log被臟寫；
當(dāng)產(chǎn)生回滾時，在進(jìn)行數(shù)據(jù)校驗時，發(fā)現(xiàn)afterImage與當(dāng)前數(shù)據(jù)不一致進(jìn)而無法正?；貪L，拋出SQLException，最終包裝成BranchRollbackFailed_Retriable異常，導(dǎo)致seata一直重試回滾；
在數(shù)據(jù)校準(zhǔn)后，某一刻的數(shù)據(jù)與afterImage一致，此時seata就回滾成功，形成ABA問題；

該pr將在1.6版本后解決seata分布式事務(wù)一直嘗試回滾的問題，可以避免ABA問題的產(chǎn)生，后續(xù)還需要提供一些其他功能輔助開發(fā)人員回滾數(shù)據(jù)。

以上就是Seata分布式事務(wù)出現(xiàn)ABA問題解決的詳細(xì)內(nèi)容，更多關(guān)于Seata分布式事務(wù)ABA的資料請關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: