A dual-channel elastic quota borrowing method based on a token bucket and a global lock

Abstract

This invention relates to the field of distributed flow control technology and discloses a dual-channel elastic quota borrowing method based on token buckets and global locks. The method includes: 1) routing client-initiated business requests to a high-concurrency channel or a low-concurrency channel according to preset rules; 2) when a business request is routed to the high-concurrency channel, obtaining a token from the dedicated token bucket of the high-concurrency channel, prioritizing the use of the high-concurrency channel's own quota, and when the high-concurrency channel's own quota is exhausted, performing quota probing and borrowing the quota of the low-concurrency channel when it is idle, allowing the request to pass flow control; 3) when a business request is routed to the low-concurrency channel, firstly constructing a low-concurrency channel occupancy lock, then obtaining a token from the dedicated token bucket of the low-concurrency channel, and allowing the request to pass flow control when the low-concurrency channel has sufficient own quota. Using this invention, high-concurrency channels can safely borrow the quota of low-concurrency channels when they are idle, improving overall throughput.

Description

Technical Field

[0001] This invention relates to the field of distributed flow control technology, specifically to a dual-channel elastic quota borrowing method based on token bucket and global lock. Background Technology

[0002] With technological advancements, distributed systems are becoming increasingly complex, exhibiting significant heterogeneity and dynamism in their traffic characteristics. To address this challenge, the "high-speed / low-speed channel" architecture pattern is widely adopted. This pattern divides business traffic into high-speed and low-speed channels based on their latency sensitivity, computational intensity, and priority. High-speed channels typically handle real-time, critical requests, characterized by low latency and high throughput, while low-speed channels generally handle offline, non-critical requests and can tolerate higher latency. The high-concurrency message gateway, as the system's traffic entry point, is a typical scenario for implementing this architecture pattern, responsible for managing massive connections, protocol conversion, and message routing. Existing automated quota scheduling solutions for high-concurrency message gateways in high-speed / low-speed channel and rigid total quota scenarios mainly include static fixed quota schemes and distributed lock preemption schemes.

[0003] Static fixed quota schemes pre-set fixed quota ratios or absolute values ​​for high-speed and low-speed channels based on historical experience, business forecasts, or simple capacity planning, and these ratios remain unchanged during system operation. Currently, mainstream gateways (such as Nginx-limit-req and Spring-Cloud-RateLimiter) pre-allocate the total quota to each channel according to weight: high-concurrency channel A is assigned a fixed rate, and low-concurrency channel B is also assigned a fixed rate. When traffic surges in any channel, the remaining quota of the other channel cannot be consumed, resulting in low overall resource utilization. Specifically, the biggest drawback of this scheme is its "rigid allocation and inability to flow." Once the total quota is pre-allocated to each channel according to weight, even if the high-concurrency channel experiences a sudden surge, it cannot utilize any available quota in the low-concurrency channel, and can only passively trigger flow control rejection; while the low-concurrency channel remains in a state of "underutilization," its remaining quota is wasted by the system, and the utilization rate of the low-concurrency channel remains consistently low.

[0004] The distributed lock preemption scheme is a strategy that dynamically allocates fixed quotas through a competitive locking mechanism. With a rigid total quota, processors (or threads) in high-speed and low-speed channels compete to acquire distributed locks to win processing quotas. The number of locks corresponds to the number of available quotas, achieving dynamic quota allocation. This scheme utilizes the multi-node distributed lock algorithm Redis RedLock. When a high-concurrency channel exhausts its local quota, it directly attempts to create a global lock. If successful, it "preempts" all quotas from the low-concurrency channel. Subsequent requests from the low-concurrency channel are rejected because they cannot acquire the same lock, resulting in "channel starvation." The global lock has coarse granularity and strong mutual exclusion, making it impossible to achieve "on-demand borrowing and return." Specifically, the biggest drawback of this scheme is the use of "exclusive" coarse-grained locks, which introduces new problems such as channel starvation and performance fluctuations. After a high-concurrency channel exhausts its local quota, it needs to compete for a global exclusive lock through multiple rounds of Redis commands. Once successful, it will acquire the entire quota of the low-concurrency channel at once. During this period, even if the low-concurrency channel only has a single request, it will be continuously rejected by the system because it cannot acquire the same lock, resulting in an unfair "channel starvation".

[0005] To address this, we invented a dual-channel elastic quota borrowing method based on token bucket and global lock, which solves the above technical problems. Summary of the Invention

[0006] This invention provides a dual-channel elastic quota borrowing method based on token bucket and global lock. It adopts a lightweight, millisecond-level, non-exclusive, and disaster recovery-friendly quota borrowing mechanism, which enables high-concurrency channels to safely borrow quotas from low-concurrency channels when they are idle, thereby improving overall throughput.

[0007] Therefore, the present invention provides the following technical solution: A dual-channel elastic quota borrowing method based on token bucket and global lock, the method comprising: Step 1: Based on preset rules, route the business requests initiated by the client to either a high-concurrency channel or a low-concurrency channel; Step 2: When a business request is routed to the high-concurrency channel, a token is obtained from the dedicated token bucket of the high-concurrency channel. The high-concurrency channel's own quota is used first. When the high-concurrency channel's own quota is exhausted, quota detection is performed. When the low-concurrency channel is idle, the quota of the low-concurrency channel is borrowed to allow the request flow control to pass. Step 3: When a business request is routed to the low-concurrency channel, a low-concurrency channel occupancy lock is first constructed, then a token is obtained from the dedicated token bucket of the low-concurrency channel, and when the low-concurrency channel has sufficient quota, the request flow control is allowed to pass.

[0008] Optionally, in step 1, the service request is routed to the high-concurrency channel or the low-concurrency channel according to preset rules such as the service type and traffic characteristics of the service request, thereby completing the reception and parameter verification of the service request.

[0009] Optionally, step 2 includes: Step 21: Call the Sentinel native interface tryAcquire(a) to attempt to obtain a token from the dedicated token bucket of the high-concurrency channel and determine whether the quota of the high-concurrency channel is sufficient. Step 22: When the high-concurrency channel's own quota is exhausted, send an EXISTS atomic query command to the Redis cluster or sentinel node to query whether the key value of the lock held by the low-concurrency channel exists, and determine the current state of the low-concurrency channel. Step 23: If Redis returns EXISTS=0, it means that the low-concurrency channel is currently not processing any requests and the quota is idle. Call the Sentinel native interface tryAcquire(b) to try to obtain a token from the dedicated token bucket of the low-concurrency channel. Step 24: If the token in the dedicated token bucket of the low-concurrency channel is successfully obtained, it means that the idle quota of the low-concurrency channel is available, and the request for flow control is allowed to pass.

[0010] Optionally, in step 21, when determining whether the high-concurrency channel's own quota is sufficient, if a token is successfully obtained from the high-concurrency channel's dedicated token bucket, it indicates that the high-concurrency channel's own quota has not been exhausted, allowing the request flow control to pass without triggering any borrowing logic; if a token cannot be obtained from the high-concurrency channel's dedicated token bucket, it indicates that the high-concurrency channel's own quota has been exhausted, and the process proceeds to step 22.

[0011] Optionally, in step 22, when determining the current state of the low-concurrency channel, if Redis returns EXISTS=1, it indicates that the low-concurrency channel is in the request processing state, and the quota of the low-concurrency channel cannot be borrowed, triggering the flow control rejection mechanism to reject the current request; if Redis returns EXISTS=0, the process proceeds to step 23.

[0012] Optionally, in step 23, if a token cannot be obtained from the dedicated token bucket of the low-concurrency channel when attempting to obtain a token, it indicates that the low-concurrency channel's own quota has been exhausted and there is no available quota to borrow, triggering the flow control rejection mechanism to reject the current request.

[0013] Optionally, step 3 includes: Step 31: Send a SETEX atomic write command to the Redis cluster or sentinel node to create a dedicated lock for the low-concurrency channel; Step 32: Call the Sentinel native interface tryAcquire(b) to attempt to obtain a token from the dedicated token bucket of the low-concurrency channel and determine whether the low-concurrency channel's own quota is sufficient. Step 33: If the token in the dedicated token bucket of the low-concurrency channel is successfully obtained, it means that the low-concurrency channel has sufficient quota and the request flow control is allowed to pass. Step 34: Automatically release the lock of the low-concurrency channel according to the expiration time set by SETEX, or release it through an explicit deletion command after the request is processed, to ensure that the state of the lock of the low-concurrency channel is cleared in time, restore the idle state of the low-concurrency channel, and allow the high-concurrency channel to borrow quotas when needed.

[0014] Optionally, in step 32, when determining whether the low-concurrency channel's own quota is sufficient, if it is impossible to obtain a token from the low-concurrency channel's dedicated token bucket, it indicates that the low-concurrency channel's own quota is exhausted, triggering a flow control rejection mechanism to reject the current request.

[0015] A dual-channel elastic quota borrowing device based on token bucket and global lock, the device comprising: The request routing unit routes the business requests initiated by the client to a high-concurrency channel or a low-concurrency channel according to preset rules; The high-concurrency channel processing unit obtains a token from the dedicated token bucket of the high-concurrency channel when a service request is routed to the high-concurrency channel. It prioritizes using the high-concurrency channel's own quota. When the high-concurrency channel's own quota is exhausted, it performs quota detection and borrows the quota of the low-concurrency channel when the low-concurrency channel is idle, allowing the request flow control to pass. The low-concurrency channel processing unit first constructs a low-concurrency channel occupancy lock when a service request is routed to the low-concurrency channel, then obtains a token from the dedicated token bucket of the low-concurrency channel, and allows the request flow control to pass when the low-concurrency channel has sufficient self-owned quota.

[0016] A computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to perform the steps of the dual-channel elastic quota borrowing method based on token bucket and global lock.

[0017] This invention provides a dual-channel elastic quota borrowing method based on token buckets and global locks, solving the problems of high-concurrency channels being unable to flexibly expand when quotas are insufficient and low-concurrency channels having idle and wasted quotas. By introducing a "quota borrowing" mechanism, when high-concurrency channel A runs out of its own token bucket, it can detect in real time whether low-concurrency channel B is occupied. If channel B is idle, channel A is allowed to temporarily borrow channel B's token, achieving dynamic traffic balance and maximizing resource utilization, thereby improving the overall system throughput and stability. Compared with existing technologies, this invention has the following technical advantages: 1) Compared to the traditional static fixed quota scheme, this invention introduces a dynamic quota borrowing mechanism, breaking the limitation that quotas cannot be shared between high-concurrency and low-concurrency channels. In the static scheme, even if the quota of low-concurrency channel B is idle for a long time, high-concurrency channel A cannot use it, resulting in resource waste. However, this invention allows A to conditionally borrow B's quota when its tokens are exhausted, significantly improving the overall resource utilization and throughput of the system.

[0018] 2) Compared to distributed lock preemption schemes, this invention does not simply achieve resource preemption through lock contention. Instead, it uses locks as state identifiers and combines them with token buckets for fine-grained flow control. Traditional lock preemption mechanisms suffer from an exclusive, "either / or" preemption problem. This invention, however, combines Redis's lightweight lock detection (EXISTS) with Sentinel's token bucket quota control to achieve predictable and controllable quota sharing, avoiding the uncertainty caused by lock contention. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0020] Figure 1 This is an architecture diagram of a dual-channel elastic quota borrowing method based on token bucket and global lock in a specific embodiment of the present invention; Figure 2 This is a flowchart of a dual-channel elastic quota borrowing method based on token bucket and global lock in a specific embodiment of the present invention; Figure 3 This is a structural diagram of a dual-channel elastic quota borrowing device based on a token bucket and a global lock in a specific embodiment of the present invention. Detailed Implementation

[0021] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0022] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0023] Existing multi-channel flow control suffers from pain points such as "rigid quotas that cannot flow, unfair borrowing mechanisms, and high latency": traditional static allocation locks quotas within each channel, forcing high-concurrency channels to passively reject requests in the face of sudden surges, while idle quotas in low-concurrency channels are systematically left idle; and existing distributed lock preemptive borrowing uses exclusive global locks, so once a high-concurrency channel successfully acquires the lock, all subsequent requests from low-concurrency channels are rejected, resulting in "channel starvation." Therefore, a millisecond-level, non-exclusive, fair, and disaster-tolerant dynamic quota borrowing mechanism is needed to achieve "on-demand instant borrowing and automatic release after use," maximizing resource utilization and ensuring system stability with zero intrusion.

[0024] like Figure 1 The diagram shows the overall architecture design of the dual-channel elastic quota borrowing method based on token bucket and global lock in this embodiment of the invention, which mainly includes: The Sentinel token bucket component located in the control layer configures independent token buckets (token bucket a and token bucket b) for high-concurrency channel A and low-concurrency channel B respectively. As the core control carrier of each channel's own quota, it is responsible for implementing basic flow control for a single channel. All token acquisition and flow control judgment operations are completed through the Sentinel native interface tryAcquire() to ensure the efficiency of flow control.

[0025] The Redis component located in the management layer only provides atomic operation capabilities for distributed locks (lock occupancy of low-concurrency channel B). It serves as a carrier for the occupancy status of low-concurrency channel B, does not participate in any quota calculation, and realizes the detection and setting of channel occupancy status through lightweight key-value pair operations (EXISTS, SETEX), ensuring global state consistency under multi-node deployment.

[0026] High-concurrency and low-concurrency channels at the channel layer: Physical isolation is performed based on business traffic characteristics. High-concurrency requesters at the client layer send business requests to high-concurrency channel A, while low-concurrency requesters at the client layer send business requests to low-concurrency channel B. High-concurrency channel A has the ability to conditionally borrow quotas, prioritizing the use of its own quotas. After the quota is exhausted, it performs quota probing and can only borrow quotas from channel B when it is idle. Low-concurrency channel B has the ability to protect its quotas by using Redis locks to atomically identify its own occupancy status, ensuring that its own request processing is not interfered with by the borrowing behavior of channel A.

[0027] like Figure 2 The diagram illustrates the overall process of the dual-channel elastic quota borrowing method based on token buckets and global locks in this embodiment of the invention. The client distributes requests to corresponding high- and low-concurrency channels according to business type and traffic characteristics. The system combines Sentinel's token bucket quota management capabilities with Redis's atomic state identification capabilities to complete the process of prioritizing the use of existing quotas and borrowing idle quotas in high-concurrency channel A, and prioritizing its own requests and protecting its quotas in low-concurrency channel B. All steps are synchronous millisecond-level operations, without multi-round lock contention or exclusive resource preemption. The specific processing steps are as follows: Step 1, Request Routing: The client initiates a business request. The system automatically routes the business request to the corresponding high-concurrency channel A or low-concurrency channel B according to preset rules such as the business type and traffic characteristics of the request, and completes request reception and parameter verification.

[0028] Step 2: When a request is routed to a high-concurrency channel, a token is first obtained from the dedicated token bucket of high-concurrency channel A, prioritizing the use of its own quota. When the quota is exhausted, a quota probe is performed, and the quota of channel B is borrowed when it is idle. This completes the priority use of the high-concurrency channel A's own quota and the borrowing of idle quota, specifically including: 2.1 The system calls the Sentinel native interface tryAcquire(a) to attempt to obtain a token from the dedicated token bucket (token bucket a) of the high-concurrency channel A and determine whether the available quota is sufficient; 2.2, Scenario with sufficient self-owned quota: If the token in token bucket a is successfully obtained, it means that the self-owned quota has not been exhausted. The request flow control passes and directly enters the subsequent business processing flow without triggering any borrowing logic. 2.3, Scenarios where self-owned quota is exhausted: If a token cannot be obtained from token bucket a, it means that the self-owned quota has been exhausted, and the system enters the low-concurrency channel B to perform quota detection and borrowing phase; 2.4 The system sends an EXISTS atomic query command to the Redis cluster or sentinel node to check if the lock key value corresponding to the low-concurrency channel B exists, thereby determining the current state of channel B; 2.5, Scenario where borrowed channels are occupied: If Redis returns EXISTS=1, it means that low-concurrency channel B is in the request processing state and its quota cannot be borrowed. The system directly triggers the flow control rejection mechanism to reject the current request and there is no subsequent operation. 2.6 Borrowing Channel Idle Scenario: If Redis returns EXISTS=0, it means that the low-concurrency channel B is currently not processing any requests and the quota is idle. The system calls the Sentinel native interface tryAcquire(b) to try to obtain a token from the dedicated token bucket (token bucket b) of the low-concurrency channel B. 2.7 Scenario with sufficient borrowed channel quota: If the token in token bucket b is successfully obtained, it means that the idle quota of channel B is available. The request for flow control is approved, and the subsequent business processing flow is entered to complete an on-demand borrowing of quota. 2.8 Borrowing Channel Quota Exhaustion Scenario: If a token cannot be obtained from token bucket b, it means that the low-concurrency channel B's own quota has also been exhausted, and there is no available quota to borrow. The system triggers the flow control rejection mechanism and rejects the current request.

[0029] Step 3: When a request is routed to a low-concurrency channel, low-concurrency channel B has quota self-protection capabilities. It uses Redis locks to atomically identify its own occupancy status, ensuring that its request processing is not interfered with by borrowing from channel A. Specifically, this includes: 3.1 The system sends a SETEX atomic write command to the Redis cluster or sentinel node to create a dedicated lock for low-concurrency channel B (set the lock key value and specify a reasonable expiration time). This operation is atomic and can avoid state conflicts in multi-node deployments, marking channel B as entering the "occupied state". 3.2 The system calls the Sentinel native interface tryAcquire(b) to attempt to obtain a token from the dedicated token bucket (token bucket b) of the low-concurrency channel B and determine whether the available quota is sufficient. 3.3, Scenario with sufficient self-owned quota: If the token in token bucket B is successfully obtained, the flow control request passes and the subsequent business processing flow is entered; 3.4, Scenario where self-owned quota is exhausted: If a token from token bucket B cannot be obtained, the system will directly trigger the flow control rejection mechanism to reject the current request; 3.5 Lock Release: Regardless of whether the request passes the flow control and is processed, or is directly rejected, the Redis lock held by the low-concurrency channel B will be automatically released according to the expiration time set by SETEX, or released by an explicit delete command after the request is processed, ensuring that the lock state is cleared in time, restoring the "idle state" of channel B, and allowing the high-concurrency channel A to borrow quotas when needed; Step 4, Process Closure: All requests that pass flow control complete subsequent business processing, while requests rejected by flow control return a rejection response according to the system's preset rules. All token consumption throughout the process is Sentinel's native logic, with no additional quota return operations.

[0030] In summary, the dual-channel elastic quota borrowing method based on token bucket and global lock of the present invention has the following technical features: Dual-channel quota isolation and borrowing mechanism: High-concurrency channel A and low-concurrency channel B are each configured with independent token buckets. Channel A has the ability to borrow quota from channel B when tokens are insufficient. The channel occupancy determination mechanism based on Redis distributed locks: Channel B is locked using the Redis SETEX command, and Channel A atomically checks whether Channel B is occupied using the EXISTS command, ensuring that the borrowing behavior will not interfere with the normal requests of Channel B; Sentinel and Redis work together to implement a dynamic flow control strategy: By combining Sentinel's token bucket flow control capabilities with Redis's locking mechanism, elastic flow control can be achieved in high-concurrency scenarios, avoiding the resource waste caused by traditional static quota allocation.

[0031] Accordingly, embodiments of the present invention also provide a dual-channel elastic quota borrowing device based on a token bucket and a global lock, such as... Figure 3 The diagram shown is a structural schematic of the device. This dual-channel flexible quota borrowing device based on token bucket and global lock includes the following modules: The request routing unit 301 routes the business request initiated by the client to a high-concurrency channel or a low-concurrency channel according to preset rules; The high-concurrency channel processing unit 302, when a service request is routed to the high-concurrency channel, obtains a token from the dedicated token bucket of the high-concurrency channel, prioritizes using the high-concurrency channel's own quota, performs quota detection when the high-concurrency channel's own quota is exhausted, and borrows the quota of the low-concurrency channel when the low-concurrency channel is idle, allowing the request flow control to pass. When a service request is routed to the low-concurrency channel, the low-concurrency channel processing unit 303 first constructs a low-concurrency channel occupancy lock, then obtains a token from the dedicated token bucket of the low-concurrency channel, and allows the request flow control to pass when the low-concurrency channel has sufficient quota.

[0032] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0033] The present invention also provides a storage medium, which is a computer-readable storage medium storing a computer program thereon, the computer program being executable when it runs. Figure 1 The method shown may include some or all of the steps. The storage medium may include read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc. The storage medium may also include non-volatile memory or non-transitory memory, etc.

[0034] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer program are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data provider to another website, computer, server, or data provider via wired or wireless means.

[0035] The embodiments of the present invention have been described in detail above. Specific implementation methods have been used to illustrate the present invention. The descriptions of the embodiments above are only for the purpose of helping to understand the methods and systems of the present invention, and are merely some, not all, embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention, and the content of this specification should not be construed as a limitation of the present invention. Therefore, any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A dual-channel elastic quota borrowing method based on token bucket and global lock, characterized in that, The method includes: Step 1: Based on preset rules, route the business requests initiated by the client to either a high-concurrency channel or a low-concurrency channel; Step 2: When a business request is routed to the high-concurrency channel, a token is obtained from the dedicated token bucket of the high-concurrency channel. The high-concurrency channel's own quota is used first. When the high-concurrency channel's own quota is exhausted, quota detection is performed. When the low-concurrency channel is idle, the quota of the low-concurrency channel is borrowed to allow the request flow control to pass. Step 3: When a business request is routed to the low-concurrency channel, a low-concurrency channel occupancy lock is first constructed, then a token is obtained from the dedicated token bucket of the low-concurrency channel, and when the low-concurrency channel has sufficient quota, the request flow control is allowed to pass.

2. The dual-channel elastic quota borrowing method based on token bucket and global lock according to claim 1, characterized in that, In step 1, based on preset rules such as the service type and traffic characteristics of the service request, the service request is routed to the high-concurrency channel or the low-concurrency channel to complete the reception and parameter verification of the service request.

3. The dual-channel elastic quota borrowing method based on token bucket and global lock according to claim 1, characterized in that, Step 2 includes: Step 21: Call the Sentinel native interface tryAcquire(a) to attempt to obtain a token from the dedicated token bucket of the high-concurrency channel and determine whether the quota of the high-concurrency channel is sufficient. Step 22: When the high-concurrency channel's own quota is exhausted, send an EXISTS atomic query command to the Redis cluster or sentinel node to query whether the key value of the lock held by the low-concurrency channel exists, and determine the current state of the low-concurrency channel. Step 23: If Redis returns EXISTS=0, it means that the low-concurrency channel is currently not processing any requests and the quota is idle. Call the Sentinel native interface tryAcquire(b) to try to obtain a token from the dedicated token bucket of the low-concurrency channel. Step 24: If the token in the dedicated token bucket of the low-concurrency channel is successfully obtained, it means that the idle quota of the low-concurrency channel is available, and the request for flow control is allowed to pass.

4. The dual-channel elastic quota borrowing method based on token bucket and global lock according to claim 3, characterized in that, In step 21, when determining whether the high-concurrency channel's own quota is sufficient, if a token is successfully obtained from the high-concurrency channel's dedicated token bucket, it means that the high-concurrency channel's own quota has not been exhausted, allowing the request flow control to pass without triggering any borrowing logic; if a token cannot be obtained from the high-concurrency channel's dedicated token bucket, it means that the high-concurrency channel's own quota has been exhausted, and the process proceeds to step 22.

5. The dual-channel elastic quota borrowing method based on token bucket and global lock according to claim 3, characterized in that, In step 22, when determining the current state of the low-concurrency channel, if Redis returns EXISTS=1, it means that the low-concurrency channel is in the request processing state, the quota of the low-concurrency channel cannot be borrowed, triggering the flow control rejection mechanism to reject the current request. If Redis returns EXISTS=0, the process proceeds to step 23.

6. The dual-channel elastic quota borrowing method based on token bucket and global lock according to claim 3, characterized in that, In step 23, if a token cannot be obtained from the dedicated token bucket of the low-concurrency channel when attempting to obtain a token, it indicates that the low-concurrency channel's own quota has been exhausted and there is no available quota to borrow, triggering the flow control rejection mechanism and rejecting the current request.

7. The dual-channel elastic quota borrowing method based on token bucket and global lock according to claim 1, characterized in that, Step 3 includes: Step 31: Send a SETEX atomic write command to the Redis cluster or sentinel node to create a dedicated lock for the low-concurrency channel; Step 32: Call the Sentinel native interface tryAcquire(b) to attempt to obtain a token from the dedicated token bucket of the low-concurrency channel and determine whether the low-concurrency channel's own quota is sufficient. Step 33: If the token in the dedicated token bucket of the low-concurrency channel is successfully obtained, it means that the low-concurrency channel has sufficient quota and the request flow control is allowed to pass. Step 34: Automatically release the lock of the low-concurrency channel according to the expiration time set by SETEX, or release it through an explicit deletion command after the request is processed, to ensure that the state of the lock of the low-concurrency channel is cleared in time, restore the idle state of the low-concurrency channel, and allow the high-concurrency channel to borrow quotas when needed.

8. The dual-channel elastic quota borrowing method based on token bucket and global lock according to claim 7, characterized in that, In step 32, when determining whether the low-concurrency channel's own quota is sufficient, if it is impossible to obtain a token from the low-concurrency channel's dedicated token bucket, it indicates that the low-concurrency channel's own quota is exhausted, triggering the flow control rejection mechanism to reject the current request.

9. A dual-channel flexible quota borrowing device based on token bucket and global lock, characterized in that, The device includes: The request routing unit routes the business requests initiated by the client to a high-concurrency channel or a low-concurrency channel according to preset rules; The high-concurrency channel processing unit obtains a token from the dedicated token bucket of the high-concurrency channel when a service request is routed to the high-concurrency channel. It prioritizes using the high-concurrency channel's own quota. When the high-concurrency channel's own quota is exhausted, it performs quota detection and borrows the quota of the low-concurrency channel when the low-concurrency channel is idle, allowing the request flow control to pass. The low-concurrency channel processing unit first constructs a low-concurrency channel occupancy lock when a service request is routed to the low-concurrency channel, then obtains a token from the dedicated token bucket of the low-concurrency channel, and allows the request flow control to pass when the low-concurrency channel has sufficient self-owned quota.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor, it executes the steps of the dual-channel elastic quota borrowing method based on token bucket and global lock as described in any one of claims 1 to 8.

Images