skyesx

恩，大思路都差不多，就看如何具体整合代码到现有框架了

先确定一下我的理解是否正确， 这里 “通过消息来完成RPC调用”，指代的是通过消息队列发送异步消息，业务主流程上不等待对方回应的的调用 基于上述的理解，我觉得这里可以分两块来看： * 同步的RPC调用（一对一，DUBBO/REST/FEIGN等），这个的做法就跟你上面写的一样，判断下是否短路，要短路则跳过日志，直接本地执行 * 异步的RPC调用（一对多，基于消息队列等，不要求拿返回结果的），这个我觉得可以不短路，因为实际上，发布消息出去可能有多个接收者，并且它并非是业务执行的关键路径，短路反而可能降低主流程性能，所以这个倒是可以不做 对于RemoteServiceCaller这个没确切看懂啥意思，是否指代希望 RemoteServiceCaller 不区分 publish和call两个方法的调用形式？但是实际上外部调用者是需要区分这两个的，因为发布消息会有个消息ID等额外的元信息，所以是不能合并的 如果不是的话，能不能直接单独提一个PR，代码应该不多，看代码比较具体，更容易看出意图

目前确实是这样， 在框架自带的 幂等/调用次序控制 实现里，如果try没有提交，cancel对应的业务方法也是不会执行的 如果没有启用框架的幂等/次序控制 功能，业务就需要自行判断try有没有执行 为了提高效率，可以在已知 从事务 返回了异常的情况下，协调器不再调用canel，作为一个效率优化手段。 但对于业务实行实现的 幂等/次序 控制，不能省略该部分代码，因为有可能由于超时等原因，框架没有成功接收 从事务 返回的异常信息，此时从事务处于未知状态，因此框架还是会调用cancel

对于使用框架幂等的情况来说，其会控制该情况的发生，因为TRY和CANCEL会同时竞争一条记录，该记录会保证TRY有先后顺序。若TRY和CANCEL同时进入到事务中，则框架会有乐观锁机制回滚其中一个。 * 若try被回滚了，则没有关系，整个流程就结束了。 * 若cancel被回滚了的话，则CANCEL会重试，然后CANCEL再次尝试时就会成功。 对于不使用框架幂等，业务自行处理时，需要自行考虑上述问题的处理形式，通常来说，业务自行处理的形式应该于框架实现的类似 还有，建议新问题提新ISSUE，容易被大家发现

不太明确指代什么，但你看看修改application.yml里的dubbo配置能否满足你的需求？

能贴一下配置的内容，我这边重现一下？

不能回滚，在设计中，使用消息队列的事务 的成功与否 不影响 主干事务的提交或者回滚。因此主干事务一定是成功才会发消息，因此使用KAFKA的事务分支无需回滚

有更正： 如注释及你所描述： * src_app_id、src_bus_code、src_trx_id是代表调用者信息，发起方 * app_id、bus_code代表调用的业务代码/发送的消息代码 * call_seq表示 同一事务同一方法内调用的次数，因为有可能发起方会多次调用同一个app_id,bus_code对应的业务，因此需要区分 * handler 代表处理者的APPID

关于使用方法在首页中仅作示意，更详尽的使用方法是在：DEMO以及UT中的案例中。但这确实不像文档一样友好，需要客户下载源码才能看的到，我后续将这些DEMO及UT的案例搬出来，做成个文档吧。 原理解读我觉得可以通过首页就能获得了，高层架构设计通过与seata的比对文档也可以获得，但源码解读确实是目前缺少的，我这个后续加上吧 感谢你的建议，如果还有我上面提漏的，可以提醒我，不过最近工作比较繁忙，更新的时间可能会晚一点

简单写了一下，先看 `Seata及EasyTransaction架构的比对思考 https://www.cnblogs.com/skyesx/p/10674700.html ` 再结合着代码看 `https://www.cnblogs.com/skyesx/p/11111726.html`