JMS微服务架构 - 关于事务提交失败，自动重新提交的机制

用JMS编写的微服务，由调用端决定了各个微服务执行时，是否需要保持事务的一致性。

也就是RemoteClient在调用微服务方法前，先调用BeginTransaction明确后面所调用的微服务需要保持事务一致性。

微服务的底层执行流程如下：

1、调用端标识此次业务需要微服务支持分布式事务

2、调用端同步或者异步调用各个微服务

微服务各自执行完自己的代码，会把事务挂起，等候调用端统一调令

3、调用端等待所有微服务执行完毕

4、调用端通知网关本次事务状态为：成功

5、调用端通知各个微服务提交事务

如果有哪个微服务提交事务时发生意外（例如宕机），之后会自动与网关确认此次事务状态，再自动重新执行代码，提交事务

 

事务的数据默认保存在$$JMS_RetryCommitPath文件夹

$$JMS_RetryCommitPath文件夹下有以下几种扩展名的文件：

*.txt : 需要提交事务的原请求数据，这些文件会在微服务重启时，自动解析，并重新执行请求和提交事务

*.err : 提交事务失败后保留下来的原请求数据，这些文件会被微服务每隔5秒重新解析，重新执行请求和提交事务

*.trying：正在重新提交的请求数据，发现这些文件，需要人工查一下这个事务是否成功提交了，再确定是否要重新执行一次

*.timeout : 当一个请求，微服务器由于和调用端失去联系，无法判断是否应该提交事务，就会把原请求数据保存在此，需要人工处理。你如果希望这个请求重新执行，那么，把它的扩张名改为.err即可

*:faild : 重新提交事务失败，保存成此文件，同样需要人工处理。