TCC-Hmily 实现高性能？

Hmily

支持嵌套事务(Nested transaction support).

1. 采用disruptor框架进行事务日志的异步读写，与RPC框架的性能毫无差别
2. 支持SpringBoot-starter 项目启动，使用简单
3. RPC框架支持 : dubbo,motan,springcloud。
4. 本地事务存储支持 : redis,mongodb,zookeeper,file,mysql
5. 事务日志序列化支持 ：java，hessian，kryo，protostuff。
6. 采用Aspect AOP 切面思想与Spring无缝集成，天然支持集群。
7. RPC事务恢复，超时异常恢复等。

Hmily如何实现高性能？
采用disruptor进行事务日志的异步读写（disruptor是一个无锁，无GC的并发编程框架）
详情：https://mp.weixin.qq.com/s/Eh9CKTU0nwLZ1rl3xmaZGA

这里有人可能会问：那么cancel方法异常，或者confrim方法异常怎么办呢？
答：首先这种情况是非常罕见的，因为你上一面才刚刚执行完try。其次如果出现这种情况，在try阶段会保存好日志，Hmily有内置的调度线程池来进行恢复，不用担心。

有人又会问：这里如果日志保存异常了怎么办？
答：首先这又是一个牛角尖问题，首先日志配置的参数，在框架启动的时候，会要求你配置的。其次，就算在运行过程中日志保存异常，这时候框架会取缓存中的，并不会影响程序正确执行。最后，万一日志保存异常了，系统又在很极端的情况下down机了，恭喜你，你可以去买彩票了，最好的解决办法就是不去解决它。

Hmily的性能问题？

答：Hmily是采用AOP切面的方式与你的RPC方法绑定，无非就是在你RPC调用的时候，保存了日志（通过异步disruptor），传递了一些参数。现在confrim，cancel也都为异步的调用，因此其性能与你的rpc性能一样。记住Hmily不生产事务，Hmily只是分布式事务的搬运工。之前Hmily在AOP切面加了一把锁，导致了性能下降，也就是Spring cloud 中国社区做的那篇文章。现在已经全部修复，并且全部异步化。其实那么测试时不合理的，因为是压测的demo，都是默认的配置。下文我会讲解，怎么样才能提高Hmiy性能。

关于RPC调用超时Hmily是怎么处理的？

答： 我们支持在分布式环境中调用一个RPC方法，如果超时了。比如dubbo设置的超时时间是100ms,可能你的方法用了140ms,但是你的方法是执行成功了的。但是对调用方来说，你是失败的。这个时候需要回滚。所以Hmily的做法是。调用者认为你是失败的，不会将加入的回滚调用链条中。因此超时的rpc接口方，进行自身的回滚。会有一个定时任务来进行回滚，因为日志状态是try阶段，会调用cancel方法进行回滚，从而到达最终一致性！

Hmily支持集群部署的问题？以及集群环境中，定时任务日志恢复的问题？

答：Hmily是和你的应用AOP切面绑定在一起的，天然支持集群。集群环境中定时恢复问题，其实几乎没有，除非你的集群同时一下挂掉，才会有这个问题。当你集群同时挂掉，在恢复的时候，日志会有一个version字段，更新成功的，才会去进行恢复

Hmily是异步保存日志的，那么很极端情况下（代码刚好执行到这一行,然后jvm退出，断电啦什么的），日志还没保存那怎么处理呢？

答：这种想法的，肯定是没看源码，或者是看了没怎么看懂。在AOP切面中，会先进行日志的异步保存，注意状态是PRE_TRY。在try执行完成后，更新为try。就算存在可能你说的什么断电，什么你在打断电调试，然后kill服务之类的。（Mysql我都可以让他事务失效，你信不信？）我只能说，不要花大力气去解决那些偶然的事情，最好的解决办法是不解决它。

Hmily针对高并发时候的参数配置调优？

org:
  dromara:
    hmily:
      serializer: kryo
      recoverDelayTime: 30
      retryMax: 30
      scheduledDelay: 30
      scheduledThreadMax:  10
      repositorySupport: db
      started: true    #注意这个设置
      hmilyDbConfig:
        driverClassName: com.mysql.jdbc.Driver
        url:  jdbc:mysql://192.168.0.73:3306/hmily?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai
        username: root
        password: 111111

1. serializer :这里我推荐使用是kryo。当然hmily也支持hessian,protostuff,jdk。
   在我们测试中表现为： kryo>hessian>protostuff>jdk
2. recoverDelayTime :定时任务延迟时间（单位是秒，默认120。这个参数只是要大于你的rpc调用的超时时间设置。
3. retryMax : 最大重复次数，默认3次。当你的服务down机，定时任务会执行retryMax次数去执行你的cancel还是confrim。
4. bufferSize: disruptor的bufferSize,当高并发的时候，可以调大。注意是 2n
5. consumerThreads distuptor消费线程数量,高并发的时候，可以调大。
6. started: 注意在是发起方的时候，把此属性设置为true。参与方为false。
7. asyncThreads 异步执行confirm和cancel线程池线程的大小，高并发的时候请调大

事务日志的存储

mongodb>redis集群>mysql>zookeeper