需要进一步详情，请联系QQ: 406748509
处理过程：
1、服务A业务1使用注解开启分布式事务2、分布式事务代理类(通过Spring AOP对注解进行处理的类)，通过SOCKET通知事务处理中心开启分布式事务，将分布式事务流水号写入线程变量
3、服务A业务1执行一条SQL
4、服务A中的数据库连接池代理根据线程变量中的分布式事务流水号的有或无，决定使用被代理的连接池或将SQL的执行数据通过SOCKET发往事务处理中心。
5、事务处理中心执行服务A业务1的SQL并通过SOCKET返回结果
6、服务A业务1调用服务（另一JAVA虚拟机）B的业务2（需要传递分布式事务流水号，HTTP方式下需要加过滤器将流水号写入线程变量）
7、服务B的业务2执行SQL
8、服务B的数据库连接池代理根据线程变量中的分布式事务流水号（HTTP过滤器给出的），执行上述4、5
9、服务A中的分布式事务代理类在业务1提交或回滚事务时，通过SOCKET通知事务处理中心提交或回滚事务
注：事务处理中心是一个定制的SOCKET服务器（应该也能支持集群），接收SQL的所有操作参数，将不同虚拟机的分布式事务变为事务处理中心这个JVM内执行的JTA（XA）事务。
事务处理中心需要服务A和B在启动时，将原始数据源信息提交过来。服务A、B中的和事务处理中心，数据库驱动程序和连接池类要一致，同一数据源需要配置一定数据库连接的比例。
比较：和网上见的通过MQ二段提交方案比，处理协议相对简单，不影响那些不需要分布式事务只需要本地事务的程序，一个虚拟机内的JTA（XA）事务也有相当成熟的方案。
问题：上例中业务1调用业务2时需要增加参数（比如通过Spring RestTemplate调用时，需要增加分布式事务流水号的传递工作），可能有少部分代码侵入，除HTTP外的协议（如dubbo)在不修改底层代码时，可能无法支持。
系统关键点：
事务处理中心必须是一个集群
同一事务流水号，必须分发到同一事务处理中心的服务器上处理。
好处：
相比事务补偿和最终一致性，此方案对应用的开发人员能力的要求很低（不是此方案实现本身），只需要2个注解和连接池代理的配置。不需要额外的业务代码及测试。