Seata中不管是1.4.2版本还是最新的1.6.1版本中，seata集群的全局事务AsyncCommitting都是加分布式锁单节点处理的，所以说我们不管seata是否有集群，并不能加快AsyncCommitting的效率，最终会导致undo_log日志的挤压。如果我们想要提高AsyncCommitting的效率，就只能增加单节点的配置，但是也不可能无限加，最终也会达到一个瓶颈。这一块很容易达到瓶颈，不知道把异步提交的线程数配置开放出来有没有风险，这样我们可以根据实际的业务进行调整。是不是可以用先占用再下发的方式解决幂等问题，每个tc只处理自己begin的事务，万一tc挂掉了重启，ip就变了，这样会造成脏数据积压，是可以提高一部分效率呢？，但是业务线程可以分布在不同的节点，异步提交线程只能在一个节点处理，分片处理感觉是一个方向我们找一下issue有没有提过类似的问题呢？
写回答
这个最大原因是因为业务线程多余处理的线程导致的，目前是按globalsession为维度，以核心数为线程数去做异步提交，业务线程是50个，异步提交比如机器是4c的就是4个，即便你一次limit 10000条事务出来，假设业务线程50个，一个全局事务rt为10ms，一个线程的tps就是100,50个就是5000，而异步提交的就算查出10000条来，也是4个线程在工作，你算一个线程异步删除undolog为5ms，1个线程也才200tps，4个才800，远低于事务的创建，这块我们看看怎么优化下比较好，2.x上会根据rm粒度(同个rm下串行，保证有序)做并行下发，如果一个全局事务下分支事务较多，会以核心数大小下发，以前是一个全局事务下的分支事务是串行执行的，会比现在效率更高一些，是要分片的，以前存在幂等问题，我们认为这种可能会影响业务的数据一致性，所以改成单tc下发，这样数据一致上是没什么问题的，先保证一致性优先。分片的具体方案还没定，欢迎提个issue大家集思广益一下，tc处理自己begin的事务，raft感知/tc也去注册中心感知是否有节点下线，去做接管，此回答整理自钉群“Seata(分布式事务)”
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践，通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式，助力制造业企业高效上云，实现系统稳定、应用敏捷智能。拥抱云原生，让创新无处不在。
