I have three questions: 1. How much does Bucket4j increase the size of the release package? 2. From the current Seata needs to implement the current limiting function which is more suitable? 3. What should the default value of this limit be?
Warm regards, Ji Min 熊靖浏 <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 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 > && isGloabalBegin(request)) { // start flow limit control > if (resultMessage != null && !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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@seata.apache.org For additional commands, e-mail: dev-h...@seata.apache.org
