开发者社区 > 云原生 > 云消息队列 > 正文

不管是1.4.2版本还是最新的1.6.1版本中,seata集群的全局事务AsyncCommittin

不管是1.4.2版本还是最新的1.6.1版本中,seata集群的全局事务AsyncCommitting都是加分布式锁单节点处理的,所以说我们不管seata是否有集群,并不能加快AsyncCommitting的效率,最终会导致undo_log日志的挤压。如果我们想要提高AsyncCommitting的效率,就只能增加单节点的配置,但是也不可能无限加,最终也会达到一个瓶颈。是的,这一块很容易达到瓶颈,不知道把异步提交的线程数配置开放出来有没有风险,这样我们可以根据实际的业务进行调整。是不是可以用先占用再下发的方式解决幂等问题,每个tc只处理自己begin的事务,万一tc挂掉了重启,ip就变了,这样会造成脏数据积压,是可以提高一部分效率,但是业务线程可以分布在不同的节点,异步提交线程只能在一个节点处理,分片处理感觉是一个方向。好的,明白了,我们找一下issue有没有提过类似的问题,如果没有,我们去提一个。好的,明白了,我们找一下issue有没有提过类似的问题,如果没有,我们去提一个。

展开
收起
真的很搞笑 2023-05-02 08:06:57 117 0
1 条回答
写回答
取消 提交回答
  • 随心分享,欢迎友善交流讨论:)

    根据您的描述,seata集群中的全局事务AsyncCommitting在处理时存在加分布式锁单节点处理的问题,这导致即使是集群部署也无法提高其效率,最终可能导致undo_log日志的挤压。为了提高AsyncCommitting的效率,您提出了增加单节点的配置和开放异步提交的线程数配置的想法,但是同时也存在一些风险和问题。

    先占用再下发的方式是一种解决幂等问题的方法,可以使每个tc只处理自己begin的事务,避免了分布式锁单节点处理的问题,提高了一部分效率。但是,如果业务线程分布在不同的节点,异步提交线程只能在一个节点处理,这就可能导致分布式事务的性能问题。

    分片处理是另一个解决方案,可以将全局事务切分成多个小事务进行处理,提高了并发性和吞吐量。但是在实际应用中,分片的设计需要考虑到多个因素,例如数据一致性、容错性、负载均衡等,这需要综合考虑并进行合理的设计和实现。

    总的来说,针对AsyncCommitting效率问题,可以从多个方面进行优化,例如优化分布式锁、增加单节点配置、分片处理等,最终需要根据实际情况进行选择和实现,以确保分布式事务的性能和稳定性。

    2023-05-05 14:32:57
    赞同 展开评论 打赏

涵盖 RocketMQ、Kafka、RabbitMQ、MQTT、轻量消息队列(原MNS) 的消息队列产品体系,全系产品 Serverless 化。RocketMQ 一站式学习:https://rocketmq.io/

相关电子书

更多
《Seata 1.3 新特性以及如何参与社区》 立即下载
低代码开发师(初级)实战教程 立即下载
阿里巴巴DevOps 最佳实践手册 立即下载