背景描述：
项目中使用到关于atomikos JTA解决分布式事务问题，其中一个数据源连接账单库，一个连接订单库，在账单处理进程中，会去调用订单库查询，再做一些操作。在压测的过程中，发现进程消费处理能力跟不上生产消息，从而造成堆积现象。
问题分析：
1、消费进程用了5个线程进行消费，这几天的订单量成增长比较大，第一反应是消费数比较少，未能及时的处理消息，于是添加添加线程数10；
2、添加10个线程后，消费能力发现并没有提升，然而引发出了另一个问题出现，立马把线程数改为5个。继续查看日志并未发现这个问题出现。
3、添加线程数为什么会带来事务超时问题？错误里面指出了JTA transaction error，也说了maybe due to a timeout，为什么会超时？
4、第一想到的是事务超时时间配置的太短？查看Atomikos源码包，在transactions-default.properties中，默认的超时时间10s，正常来讲，这个时间已经足够。
5、在这个逻辑里面，需要调用到第三方系统，怀疑是不是第三方返回的太慢，通过日志排查，第三方调用返回确实有点慢，平均用了3S！这个有点过了。和第三方沟通后，反馈说他们又一些其他东西在里面导致有点慢。讨论过后，第三方控制在1S内，继续观察日志，发现还是没有自己想要的效果 。
6、排除了第三方，对内部代码进行排查，里面对订单库进行查询，会不会是因为订单查询问题？日志查看，项目启动的时候查询时间还比较快，但是随着时间推移，发现查询order库耗费的时间达到了几百毫秒，为什么查询这么慢？在Grafana中查看MySql Max Connections，也并没有发现什么异常，配置的MaxActivate:200。排查这个Sql也并不是慢查询，那么问题只能出现在代码中。
7、继续查看关于Atomikos配置，在createDataSource中，首先通过MysqlXADataSource创建一个Connection，最终把这个mysqlXADataSource放到AtomikosDataSourceBean中，通过源码查看，发现MysqlXADataSource实现了XADataSource，那么AtomikosDataSourceBean中是不是没用到MySql默认的MaxPoolSize默认值，查看AtomikosDataSourceBean源码，发现确实有关于AtomikosDataSourceBean MaxPoolSize的配置。
8、MySql有自己的默认值，AtomikosDataSourceBean应该也有自己的默认值，查看源码确实有默认值。
9、AtomikosDataSourceBean 默认的minPoolSize与MaxPoolSize是1！代码重新设值，最小配置5，最大200。
10、再次压测，还是10个线程，不配置xaDataSource maxPoolSize与minPoolSize，查询耗时：
11、配置xaDataSource maxPoolSize与minPoolSize，耗时：
12、对比后，一个连接三四十倍之差！配置后重新压测，上面事务超时问题也没出现，消息也没出现堆积现象。
特此记录一下这次排查过程。
