苍穹最终一致性使用-CSDN博客

本文链接：https://blog.csdn.net/tanrt/article/details/130076183

适用场景

最终一致模式可以保证跨数据库或跨节点更新时的数据一致。它会以1个更新操作为基准，注册多个其它更新操作，最终保证所有更新都成功，实现分布式事务的弱一致性。可以适用一个更新适用多个场景(跨云、跨库、跨系统)

工作原理

1、在第一次调用register注册最终一致服务的时候，会开启一个新的分布式事务，创建全局唯一xid
2、所有通过register注册的信息暂时不会执行，而是先记录到本地数据库的表中
t_dtx_local_tx_log
3、如果一切顺利，本地事务成功提交，会自动触发提交分布式事务到事务协调器
4、事务协调器收到提交后，会根据register的调用顺序逐个执行最终一致服务，直到全部完成
如果本地事务回滚了，会怎么处理？

回滚原理

当本地事务事务被回滚时，由于register的信息没有真正执行，所以相当于什么都没做，数据是一
致。同时，如果已经开启是分布式事务，则会通知协调器回滚。
如果在执行过程中，任何一个环节出现问题，包括宕机、程序ug、网络异常、数据库访问超时等
情况，KDTX是怎么保证数据最终还是一致的？可以阅读事务补偿部分。
使用最终一致模式之前，需要在业务数据库中创建本地事务表

使用方法(代码部分)

1、创建最终一致服务

要使用最终一致模式，首先是创建最终一致服务(EC Service)。根据需要，可以创建1个或多个
服务，具体做法是：新建一个类继承kd.bos.kdtx.sdk.api.EventualConsistencyService,覆盖
execute方法，并把业务逻辑写在里面。

public class AlphaECService extends EventualConsistencyService {
 /**
 * @param param 业务参数
 * @param lastReturn 上一个服务返回结果
 */
 @Override
 public DtxResponse execute(Object param, Object lastReturn) throws Exception {
 CommonParam commonParam = (CommonParam) param;
 String foobar = commonParam.getString("foobar");
 // 业务逻辑代码部分
 
 return null;
 }
}

2、注册ServiceFactory

public class ServiceFactory {
 static {
 serviceMap.put("XXXXX", "kd.fi.ai.mservice.dtxservice.XXXXX
 }
}

事务操作部分

// 插件本身已经开启了本地事务，传播属性是required
public class FoobarOperationPlugin extends AbstractOperationServicePlugIn {
    @Override
    public void beginOperationTransaction(BeginOperationTransactionArgs e) {

        ECGlobalSession.begin(SCENES_CODE);
        // 注册分布式事务1
       ECGlobalSession.register(CLOUD_ID, APP_ID, ALPHA_EC_SERVICE);
    }
    @Override
    public void endOperationTransaction(EndOperationTransactionArgs e) {
        // 注册分布式事务2
        ECGlobalSession.register(CLOUD_ID, APP_ID, BRAVO_EC_SERVICE);
    }
}

业务场景配置