+1 bucket4j I would choose bucket4j. Because it is ready to use. And the functions meet our needs.
Best Regards, Jiangke Wu(xingfudeshi) 熊靖浏 <jingliu_xi...@foxmail.com> 于2024年7月16日周二 12:20写道： > There is still a decision we need to make, use Apache Guava or Bucket4j? > > > > There are currently two options for flow limit control components. > One is > > to use RateLimiter in Apache Guava, and the second is Bucket4j. Both > have > > active communities and are easy to use and integrate. Here are the > > advantages and disadvantages: > > > > Apache Guava: Its advantages are that it has been integrated into > Seata > > and will not increase the packaging volume. The disadvantage is that > it > > does not directly support setting the maximum and initial number of > token > > buckets. The RateLimiter is relatively simple and requires expansion > before > > it can be used. > > > > Bucket4j: The advantage is that it can be used directly. The > disadvantage > > is that it increases the packaging volume. > > > > Jingliu Xiong, github id: xjlgod > ------------------ Original Email ------------------ > 发件人: > "dev" > < > xingfude...@apache.org>; > 发送时间: 2024年7月16日(星期二) 上午10:41 > 收件人: "dev"<dev@seata.apache.org>; > > 主题: Re: Start an SIP(Seata Improvement Proposals): support flow limit > control control for a single server. > > > > This feature looks great. > Looking forward to its implementation. > > Best Regards, > Jiangke Wu(xingfudeshi) > > > 熊靖浏 <jingliu_xi...@foxmail.com> 于2024年7月15日周一 22:12写道： > > > Dear community, > > > > I want to start an SIP about "support flow limit control for a single > > server". The SIP of this mail in Chinese can be seen at&nbsp; > > > https://www.yuque.com/cairusigoudenanpeijiao/izo0ob/pl4abtngc92icaf0?singleDoc# > > > <https://www.yuque.com/cairusigoudenanpeijiao/izo0ob/pl4abtngc92icaf0?singleDoc#>>; > . > > > > > > > > Motivation: > > > > The TC server side currently lacks flow limit control. When > transactions > > are exceeded, excessive pressure on the server side may cause the > server to > > crash . Therefore, it is necessary to provide a flow limit control > for the > > server side to protect server flow traffic security. > > > > > > > > Proposed Change: > > > > Add server single-node flow control. It is currently not recommended > that > > distributed flow control be implemented. The first version should have > > simple functions and only be considered from an Ops perspective. In > the > > future, it is planned to add resourceId level limiting to impose flow > limit > > control on transaction initiators. > > > > > > > > New or Changed Public Interfaces: > > > > 1.Interface design > > > > Configure on the server side. The flow control takes effect on a > single > > server. Use the following parameter configuration: > > # whether to enable flow limit control server.ratelimit.enable=true # > > limit token number of bucket per second > > server.ratelimit.bucket.token.second.num=10 # limit token max number > of > > bucket server.ratelimit.bucket.token.max.num=100 # limit token initial > > number of bucket server.ratelimit.bucket.token.initial.num=10 > > 2.Flow limit control design > > > > Flow limit control is based on global transactions. When a global > > transaction starts, the flow limit controls the global transaction > start > > request, and other types of requests do not. This prevents > transactions > > from being limited in the middle and causing resource waste due to > > rollback. The current limiting algorithm uses the token bucket > algorithm. > > The advantage of this algorithm is that it can better detect sudden > traffic > > changes instead of bringing a constant rate limit flow. > > > > > > > > There are currently two options for flow limit control components. > One is > > to use RateLimiter in Apache Guava, and the second is Bucket4j. Both > have > > active communities and are easy to use and integrate. Here are the > > advantages and disadvantages: > > > > Apache Guava: Its advantages are that it has been integrated into > Seata > > and will not increase the packaging volume. The disadvantage is that > it > > does not directly support setting the maximum and initial number of > token > > buckets. The RateLimiter is relatively simple and requires expansion > before > > it can be used. > > > > Bucket4j: The advantage is that it can be used directly. The > disadvantage > > is that it increases the packaging volume. > > > > 3.Flow limit control position design > > > > Check the request method at DefaultCordinator and enter the limiting > logic > > judgment. > > @Override public AbstractResultMessage onRequest(AbstractMessage > request, > > RpcContext context) { if (!(request instanceof > > AbstractTransactionRequestToTC)) > { throw new > > IllegalArgumentException(); > } AbstractTransactionRequestToTC > > transactionRequest = (AbstractTransactionRequestToTC) request; > > > transactionRequest.setTCInboundHandler(this); if > > (ENABLE_SERVER_RATELIMIT &amp;&amp; isGloabalBegin(request)) > { // > > start flow limit > control if (resultMessage > != null &amp;&amp; > > !rateLimiter.canPass()) > { > // record metrics > > eventBus.post(new GlobalTransactionEvent(-1, > > GlobalTransactionEvent.ROLE_TC, null, > > > context.getApplicationId(), > > context.getTransactionServiceGroup(), > > > null, null, null, true)); > > > handleRateLimited(transactionRequest); > return resultMessage; > > } > } return transactionRequest.handle(context); } > > Implementation points > > > > Flow limiting components: Select third-party flow limit components to > > implement flow limit control. > > > > Processing flow limit control: Process flow is limited at the top > level in > > DefaultCordinator, and flow limiting checks are performed in the > onRequest > > method. > > > > Transaction end: All transaction ends (like client end) need to > identify > > flow limit control and throw corresponding exceptions correctly. > > > > Metrics: Extended GlobalTransactionEvent, metrics record events when > > current limiting is triggered > > > > > > > > Migration Plan and Compatibility: > > > > This function will not make other Seata functions unusable; it is a > newly > > added function. Possible compatibility issues include how the client > > handles the flow-limiting exception thrown. At present, it can be > thrown > > directly without modification. > > > > It is planned to be improved from both the Ops and business > perspectives: > > > > Improvement from the Ops: Adding flow limit control based on > resourceId, > > limiting the transaction initiator (TM) to start global transactions. > > > > Improvements from the business: Adding a transaction allowlist > mechanism, > > allowing notable business transactions to pass the flow limit. > > > > > > > > Rejected Alternatives: > > > > There are two rejected alternatives: The first is strongly related to > > business and will not be considered in the first version. The second > is too > > costly to limit the flow of all RPC requests, which will cause many > > transactions to be rolled back and waste resources. > > > > Option One: > > > > Add a flow limit control context to the global transaction. Different > > priority levels correspond to different strategies: > > > > ● The priority is 0, and it does not participate in the flow limit. > > > > ● The priority is 1, the default priority level, and participate in > the > > flow limit. > > > > Option Two: > > > > ● Taking RPC requests as the flow limit control unit, all RPC requests > > will be flow-limited. If the current RPC request is limited, the > > corresponding failed request of the current request will be directly > > returned. > > > > > > > > > > Thanks for your attention. > > > > Jingliu Xiong, github id: xjlgod
