不管是1.4.2版本还是最新的1.6.1版本中,seata集群的全局事务AsyncCommitting都是加分布式锁单节点处理的,所以说我们不管seata是否有集群,并不能加快AsyncCommitting的效率,最终会导致undo_log日志的挤压。如果我们想要提高AsyncCommitting的效率,就只能增加单节点的配置,但是也不可能无限加,最终也会达到一个瓶颈。是的,这一块很容易达到瓶颈,不知道把异步提交的线程数配置开放出来有没有风险,这样我们可以根据实际的业务进行调整。是不是可以用先占用再下发的方式解决幂等问题,每个tc只处理自己begin的事务,万一tc挂掉了重启,ip就变了,这样会造成脏数据积压,是可以提高一部分效率,但是业务线程可以分布在不同的节点,异步提交线程只能在一个节点处理,分片处理感觉是一个方向。好的,明白了,我们找一下issue有没有提过类似的问题,如果没有,我们去提一个。好的,明白了,我们找一下issue有没有提过类似的问题,如果没有,我们去提一个。
根据您的描述,seata集群中的全局事务AsyncCommitting在处理时存在加分布式锁单节点处理的问题,这导致即使是集群部署也无法提高其效率,最终可能导致undo_log日志的挤压。为了提高AsyncCommitting的效率,您提出了增加单节点的配置和开放异步提交的线程数配置的想法,但是同时也存在一些风险和问题。
先占用再下发的方式是一种解决幂等问题的方法,可以使每个tc只处理自己begin的事务,避免了分布式锁单节点处理的问题,提高了一部分效率。但是,如果业务线程分布在不同的节点,异步提交线程只能在一个节点处理,这就可能导致分布式事务的性能问题。
分片处理是另一个解决方案,可以将全局事务切分成多个小事务进行处理,提高了并发性和吞吐量。但是在实际应用中,分片的设计需要考虑到多个因素,例如数据一致性、容错性、负载均衡等,这需要综合考虑并进行合理的设计和实现。
总的来说,针对AsyncCommitting效率问题,可以从多个方面进行优化,例如优化分布式锁、增加单节点配置、分片处理等,最终需要根据实际情况进行选择和实现,以确保分布式事务的性能和稳定性。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
涵盖 RocketMQ、Kafka、RabbitMQ、MQTT、轻量消息队列(原MNS) 的消息队列产品体系,全系产品 Serverless 化。RocketMQ 一站式学习:https://rocketmq.io/