适用场景
最终一致模式可以保证跨数据库或跨节点更新时的数据一致。它会以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); } }
业务场景配置
场景编码：要求唯一，和代码中的scenesCode保持一致，否则会抛异常
场景名：具有中文含义的描述
所属应用：所属应用的appld
业务类型：业务归宿的种类，可以和场景编码相同
具体文档链接：https://mp.csdn.net/mp_download/manage/download/UpDetailed
