skyesx

在1.3.1版本及之后通过RemoteServiceCaller.getCurrentLogProcessContext()可以在RPC Consumer execute 或者 Queue Publish 的时候获得当前 ET的上下文 LogProcessContext，以此解决从事务主线程传递信息到异步执行的try,confirm,cancel等方法。但注意，在crash recover 的时候，目前并不会恢复对应设置的额外元信息 通过LogProcessContext的getExtendResourceMap，可以传递token等业务元信息到try,confirm,cancel等异步处理线程

* RemoteServiceCaller.getCurrentLogProcessContext() 用在RPC的filter里 * 主业务线程里通过以下方法获取LogProcessContext * 获取前需要开启全局事务，即调用EasyTransFacade.startEasyTrans(String, long)。 * 可以将调用EasyTransFacade.startEasyTrans及设置token到LogProcessContext写成切面自动执行 * 注入 EasyTransSynchronizer 后 调用 getLogProcessContext()

建议补偿方法不要校验token，因为crashRecovery的时候： * 拿不到token * token会过期 从而导致补偿失败

* 只有框架控制范围内的调用才是幂等的（通过直接/间接调用transaction.execute） * 在TCC里，与外部交互只有三个方法，框架只会对这三个方法进行幂等控制（其他形态有其他形态的方法，也会有幂等） * Demo里的Order端通过代码直接/间接调用多次transaction.execute，会被认为是多个不同请求（但RPC框架的重试/或者重复消息等会被认为是同一个请求）

为了代码简单处理，目前设计如此。失败后将会等待一段时间后重试，目前实现将会延迟达到最终一致的时间。但相对于正常成功的数量，这应该是少数情况。后续会优化本实现

海信HICS技术团队压测评估 http://springcloud.cn/view/374 本文中提到的ET的不足： * 入侵性大、没有DEMO、即使不需要使用队列框架也做了检查 等问题已经解决 * RPC SpringCloud Ribbon-Rest作为底层RPC通讯时注解配置的超时无效的问题暂时没有解决，因为RPC SpringCloud Ribbon-Rest底层就不支持URI/Request级别的超时设置，只能按照Ribbon的配置按照服务级别设置超时，后续会研究如何解决 同时，评测文章中的LCN使用的是REDIS的事务日志存储，这个是一个对其他框架评测的不公平点，ET改为Redis后，性能也会有大幅提升。同时个人认为LCN有设计原理缺陷，应用崩溃时会导致数据不一致。

If you want to get a better ET benchmark, here's the points: * If your Global transaction contains multiple sub-trans please use Future to get Result as late as possible...

> 这里附上我个人的测试结果：https://blog.csdn.net/yongyou890410/article/details/82719062 Thx!

> 我的压测结果： > https://shimo.im/docs/dyojGFXPsCIYxmCI 谢谢，咨询过作者，补充一些环境信息： ET 采用Mysql存储事务日志 4核4G内存 SSD存储 Server 包含 JAVA应用、DB、KAFKA，ZK 4核8G内存 Client 用于发送压力请求 没有使用框架幂等 测试的是TCC+可靠消息

Feign底层是Ribbon,你参考Ribbon相关配置就可以了。 同时ET对客户暴露的不是原有的RPC接口，而是通过ET的接口间接访问底层RPC的，你看下Sample应该会有了解