seata Low performance of two-phase asynchronous commit in AT mode

pu82cl6c 于 4个月前发布在其他

关注(0)|答案(2)|浏览(68)

I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description

Scenario description:
Our seata-server cluster environment has five node nodes, using AT mode, and the current daily transaction volume is about 300w

Question:
Discover global at peak_ Table and branch_ Table will generate a large amount of data backlog. Through 1.3.0 source code analysis, it is found that there is data competition between multiple nodes in the submission process of phase II, which affects the execution efficiency. Looking at the implementation of version 1.6.1, although distributed locks are added to solve the data competition problem, the processing speed is not improved. Rough filtering estimates that the daily throughput of phase II in the current environment is about 200w

doubt:
The problem of data backlog may still occur during the peak period. Does the middleware have a solution to this problem?

Suggestion:
Is it possible to partition data for two-phase asynchronous submission and improve data processing efficiency by concurrent execution of multiple nodes?

Ⅱ. Describe what happened

If there is an exception, please attach the exception trace:

Just paste your stack trace here!

Ⅲ. Describe what you expected to happen

Ⅳ. How to reproduce it (as minimally and precisely as possible)

xxx
xxx
xxx

Ⅴ. Anything else we need to know?

Ⅵ. Environment:

JDK version :1.8
Seata version: 1.3.0
OS :
Others:

seata

来源：https://github.com/apache/incubator-seata/issues/5422

2条答案

按热度按时间

z0qdvdin1#

Try the following configuration. store.redis.queryLimit=1000
the value represents the number of asyn commit sessions fetched per grab.

赞(0）回复(0）举报 4个月前

m4pnthwp2#

Try the following configuration. store.redis.queryLimit=1000 the value represents the number of asyn commit sessions fetched per grab.

After the configuration is increased, the amount of data obtained each time is much more. In addition, the transaction's second submission process is executed in a circular way. The data between nodes in version 1.3.0 compete with each other and interrupt. Instead, time is wasted on querying data

赞(0）回复(0）举报 4个月前

我来回答