Token dynamic multiplexing method and computer program product
By dynamically reusing tokens and adjusting token allocation based on scenarios and departmental identifiers, the resource waste and response latency issues of static QPS allocation are resolved, enabling flexible resource scheduling and efficient service response.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- QIAN JIN NETWORK INFORMATION TECH SHANGHAI LTD
- Filing Date
- 2026-01-05
- Publication Date
- 2026-05-15
AI Technical Summary
Existing rate limiting and resource scheduling solutions use a static QPS allocation method, which leads to resource waste and service response delays. They are difficult to adapt to frequent changes in the resource requirements of business nodes, and adjusting strategies is cumbersome and time-consuming.
By receiving token requests, the system obtains the number of remaining tokens globally, determines the number of departmental permits to be allocated based on the scenario identifier and department identifier, and if the number is insufficient, it borrows tokens from idle departments within the same business scenario to achieve dynamic token reuse.
This improved token utilization, reduced resource idleness, enhanced service response speed for business departments during peak periods, and improved service quality and overall resource utilization.
Smart Images
Figure CN122044833A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a method for dynamic reuse of tokens and a computer program product. Background Technology
[0002] As enterprise business platforms expand, multiple business nodes are typically set up to handle different business scenarios, thereby providing diversified business services. Each business node needs to access various resources provided by the enterprise operations platform while providing these services. For example, the platform can assign tokens to each business node to achieve unified control over node traffic, API call quotas, message consumption rates, and computing resource usage. Because different business nodes differ in business type, access frequency, and resource consumption intensity, it is necessary to reasonably limit the resource consumption of each node to ensure the stability and availability of the overall enterprise service, preventing some nodes from excessively consuming resources and affecting the overall system operation.
[0003] Existing rate limiting and resource scheduling solutions typically employ a static QPS (Queries per second) allocation method. Specifically, the total QPS of the system is pre-allocated to a fixed level based on departments or business scenarios. This static allocation method suffers from several technical flaws and pain points in practical applications. For example, when resource demands differ across business nodes, some business nodes may have their allocated QPS idle for extended periods, leading to underutilization of system resources and resource waste. Furthermore, when a business node experiences a sudden surge in traffic within a short period, the fixed QPS allocation often fails to meet its actual needs in a timely manner, resulting in service response delays or even system anomalies or crashes. Moreover, adjusting the resource allocation strategy requires manual modification of configurations and redeployment, a cumbersome and time-consuming process that is ill-suited to adapt to frequent changes in business node resource demands. To address these issues, it is necessary to improve the existing token allocation strategy. Summary of the Invention
[0004] In view of this, embodiments of this application provide a method for dynamic reuse of tokens and a computer program product, which can improve the overall flexibility of token allocation and adapt to diverse token consumption scenarios.
[0005] This application provides a method for dynamic token reuse, comprising: receiving a token request, the token request including a token request quantity, a scenario identifier of the business scenario corresponding to the token requester, and a department identifier of the business department corresponding to the token requester; obtaining the global remaining token quantity; if the global remaining token quantity is greater than a first preset quantity, determining a target allocation quantity based on the global remaining token quantity and the token request quantity; determining the department permission allocation quantity for the business department within the business scenario based on the scenario identifier and the department identifier; if the department permission allocation quantity is less than the target allocation quantity, determining the token borrowing quantity based on the department permission allocation quantity and the target allocation quantity; and identifying idle departments among the peer departments of the business department within the business scenario; extracting tokens from the department tokens within the business scenario based on the department permission allocation quantity, and extracting tokens from the remaining tokens of the idle departments based on the borrowing quantity, and allocating tokens to the token requester.
[0006] Optionally, in some embodiments of this application, determining the target license allocation quantity based on the global remaining token quantity and the token request quantity includes: determining the minimum value between the global remaining token quantity and the token request quantity as the target license allocation quantity.
[0007] Optionally, in some embodiments of this application, determining the number of departmental licenses allocated to a business department within a business scenario based on a scenario identifier and a department identifier includes: Based on the department identifier and scenario identifier, obtain the number of remaining tokens for the business department and the idle time of the business department in the traffic configuration information table; determine the number of licenses to be allocated to the department based on the token distribution threshold, the number of remaining tokens for the department and the idle time.
[0008] Optionally, in some embodiments of this application, determining the number of licenses allocated to a department based on the number of remaining tokens in the department and the idle time of the token distribution threshold includes: determining the current remaining usage of the business department according to the token distribution rate corresponding to the token distribution threshold, the number of remaining tokens in the department, and the idle time; and determining the minimum value between the token distribution threshold and the current remaining usage as the number of licenses allocated to the department.
[0009] Optionally, in some embodiments of this application, determining the current remaining usage of a business department based on the token distribution rate corresponding to the token distribution threshold, the number of remaining tokens in the department, and the idle time includes: determining the current token allocation amount of the business department based on the product of the token distribution rate and the idle time; and determining the current remaining usage of the business department based on the sum of the current token allocation amount and the number of remaining tokens in the department.
[0010] Optionally, in some embodiments of this application, the number of peer departments is at least one; determining idle departments among the peer departments of the business department in the business scenario includes: obtaining the current time and the last active time of each peer department; determining the idle duration of each peer department based on the current time and the last active time of each peer department; and determining idle departments with an idle duration greater than a preset duration as idle departments.
[0011] Optionally, in some embodiments of this application, extracting tokens from the remaining tokens in an idle department based on the borrowing quantity includes: determining the borrowing priority of each idle department when there are multiple idle departments; extracting tokens according to the borrowing order corresponding to the borrowing priority, until the number of extracted tokens reaches the borrowing quantity, or there are no tokens available to extract from the idle department.
[0012] Optionally, in some embodiments of this application, the method further includes: when the number of departmental license allocations is greater than or equal to the target allocation number, extracting tokens from the departmental tokens of the business department within the business scenario according to the target allocation number, and allocating tokens to the token requesting end.
[0013] Optionally, in some embodiments of this application, the method further includes: when the number of remaining tokens globally is less than or equal to a first preset number, allocating zero tokens to the token requester.
[0014] This application provides an electronic device, which includes a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the steps of the method described above.
[0015] This application provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the steps of the method described above.
[0016] This application provides a computer program product, which includes computer program instructions. When the computer program instructions are executed by a processor, they implement the steps of the method described above.
[0017] In the embodiments of this application, after receiving a token request, the target allocation quantity is determined only after confirming that the remaining global token quantity is sufficient for allocation. This avoids blind allocation when overall resources are insufficient, thus improving the stability of global operation. Subsequently, based on the business scenario identifier and department identifier, the departmental license allocation quantity for each business department within a specific business scenario is further determined. If the departmental license allocation quantity is insufficient to meet the target allocation quantity, idle departments and tokens that can be temporarily borrowed by these departments are identified within the same business scenario. The borrowed tokens and the departmental license allocation tokens are then allocated to the token requesting party. Therefore, by reusing idle tokens within the same scenario, not only is token utilization improved and token idleness reduced, but the service response speed of business departments during peak business periods is also effectively improved, thus enhancing service quality. Attached Figure Description
[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings of the embodiments of this application will be briefly described below.
[0019] Figure 1 This is a schematic diagram of the system architecture of an embodiment of this application.
[0020] Figure 2 This is a flowchart of a method for dynamically reusing a token according to an embodiment of this application.
[0021] Figure 3 This is a flowchart of another token dynamic reuse method according to an embodiment of this application.
[0022] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation
[0023] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.
[0024] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.
[0025] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.
[0026] Various modifications and variations can be made to this application without departing from its spirit or scope, which will be apparent to those skilled in the art. Therefore, this application is intended to cover modifications and variations falling within the scope of the corresponding claims (the claimed technical solutions) and their equivalents. It should be noted that the implementation methods provided in the embodiments of this application can be combined with each other without contradiction.
[0027] Embodiments of this application relate to terminal devices and / or servers. Those skilled in the art will recognize that embodiments of this application can be implemented as a system, apparatus, device, method, computer-readable storage medium, or computer program product. Therefore, this disclosure can be specifically implemented in at least one of the following forms: entirely hardware, entirely software, or a combination of hardware and software.
[0028] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of laws and regulations.
[0029] In existing technologies, distributed rate limiting typically employs a static quota allocation model (such as a fixed QPS allocation) or uses a simple token bucket / leaky bucket algorithm for independent control. Resources are strictly isolated between different business scenarios and cannot be shared. When traffic is low in some scenarios, their quotas are idle, while high-priority scenarios experience a surge in traffic but cannot obtain sufficient permissions, leading to service limitations or resource waste.
[0030] Those skilled in the art have discovered that by introducing access timeliness and token borrowing priority ranking for idle resource determination and cross-departmental resource borrowing mechanisms, static isolation boundaries can be broken, and idle quotas in low-activity scenarios can be dynamically reused while ensuring the supply of high-priority business resources, thereby achieving elastic flow and efficient utilization of global resources.
[0031] Figure 1 A schematic diagram of a system architecture according to an embodiment of this application is shown. For example... Figure 1 As shown, the system includes a token requester and a token distributor. The number of token requesters can be multiple, for example, Figure 1 The token request terminals 102a and 102b shown can provide services for different business scenarios and can be used by different business departments.
[0032] The token request terminal 102a can be any service device corresponding to a business department that needs to use rate-limited resources. When providing services for a business scenario, the token request terminal 102a needs to request a certain number of tokens from the token distribution terminal 104.
[0033] The token distribution terminal 104 can include one or more servers to balance the number of tokens consumed in different business scenarios, thus avoiding excessive resource consumption in some business scenarios.
[0034] Optionally, the token distribution terminal 104 can maintain a traffic configuration information table to store configuration information for various rate-limiting scenarios. Alternatively, a Redis table can be used as the traffic configuration information table. Redis is an in-memory key-value store that supports various data structures, such as hash, which allows mapping a key to a collection of multiple field-value pairs, suitable for storing object-type data. In this embodiment, Redis can be used to store configuration information for various rate-limiting scenarios.
[0035] After receiving a token request, the token distribution terminal 104 distributes a token to the token request terminal 102a according to the business department and business scenario corresponding to the token request. When the number of departmental licenses allocated to a business department is insufficient to meet the target allocation number, it seeks an idle department to borrow a token to meet the actual application needs of the token request terminal 102a.
[0036] Based on the embodiments of this application, when a business department has insufficient tokens, it can borrow tokens from other departments in the same scenario. This not only improves the utilization rate of idle tokens and reduces resource idleness, but also effectively improves the service response speed of the business department during peak business periods and enhances service quality.
[0037] Figure 2A flowchart illustrating a method for dynamic token reuse according to an embodiment of this application is shown, the method including steps 201 to 206.
[0038] Step 201: Receive token requests. The token requests include the number of token requests, the scenario identifier of the business scenario corresponding to the token requesting end, and the department identifier of the business department corresponding to the token requesting end.
[0039] Step 202: Obtain the total number of remaining tokens globally.
[0040] Step 203: If the number of remaining tokens in the world is greater than the first preset number, determine the target allocation number based on the number of remaining tokens in the world and the number of token requests.
[0041] Step 204: Determine the number of departmental licenses allocated to each business department within the business scenario based on the scenario identifier and department identifier.
[0042] Step 205: If the number of departmental licenses allocated is less than the target number of allocations, determine the number of tokens to be borrowed based on the number of departmental licenses allocated and the target number of allocations; and identify idle departments among the peer departments of the business department within the business scenario.
[0043] Step 206: Extract tokens from the department tokens within the business scenario according to the department permission allocation quantity, and extract tokens from the remaining tokens in the idle departments according to the borrowing quantity, and allocate tokens to the token requesting end.
[0044] The above steps will be described in detail below with reference to specific embodiments, as shown in the following figures.
[0045] First, step 201 involves the token request being initiated by the token requesting end. The token request includes at least the number of token requests, the scenario identifier of the business scenario corresponding to the token requesting end, and the department identifier of the business department corresponding to the token requesting end.
[0046] The token distribution end can quickly determine the specific business scenario to which the token request is applied based on the scenario identifier, and identify the business department that initiated the token request based on the department identifier, thereby facilitating subsequent token distribution under different business scenarios and different business department dimensions.
[0047] For example, a recruitment platform can have multiple business departments, such as Marketing, Operations, and Advertising. Simultaneously, the platform can support various business scenarios, including push notifications, similar job recommendations, recommendations for multiple applications, and recommendations for popular job postings. Each business department can select the desired scenario based on its business needs and request a token from the token distribution provider. The next steps, 202 and 203, involve obtaining the total number of remaining global tokens. This number represents the total amount of tokens that have not yet been allocated in the current system. Specifically, if the number of remaining global tokens is greater than a first preset number, it indicates that there are still globally available token resources, thus allowing tokens to be allocated to the token requesting end. Optionally, the first preset number can be 0 or other preset values.
[0048] In some embodiments, if the number of remaining global tokens is less than or equal to a first preset number, the number of tokens allocated to the token requester is zero.
[0049] Specifically, if the number of remaining tokens globally is less than or equal to the first preset number, the global token resources cannot be allocated, and therefore, this token request needs to be rejected.
[0050] Based on this, we can avoid blindly allocating resources when overall resources are insufficient, thereby improving the stability of global operation.
[0051] After determining that tokens can be allocated to the token requester, the target allocation quantity can be further determined based on the global remaining token quantity and the number of token requests. The target allocation quantity should be within the range of the global remaining token quantity and should not exceed the number of tokens requested by the token requester.
[0052] For example, when determining the target license allocation quantity, the minimum of the global remaining token quantity and the token request quantity can be used as the target license allocation quantity.
[0053] Specifically, by limiting the target number of licenses allocated to the number of remaining global tokens and the actual demand from the token requesting end, it is ensured that the subsequent token allocation process will not exceed the carrying capacity of global token resources.
[0054] After determining the target allocation quantity, the next step involves step 204, which determines the departmental license allocation quantity within the business scenario where the business department is located.
[0055] For example, a traffic configuration information table is maintained on the token allocation end to record information such as the number of tokens requested each time, the number of tokens available, the number of tokens used, and the number of tokens available globally. For instance, after allocating a token to a token requester each time, the token allocation end will record in real time the number of tokens allocated to the corresponding business department of the requester in the business scenario (i.e., the token consumption) and the time of each allocation in the traffic configuration information table.
[0056] In this way, the system can quickly determine the number of departmental licenses allocated within the current business scenario based on the information recorded in the traffic configuration information table and the preset token replenishment rules. Optionally, the preset token replenishment rules could be that the number of usable tokens for each business department in a business scenario increases by 100 every predetermined time period, or that the specific number of tokens replenished is determined based on the time interval and the amount of tokens replenished per unit time.
[0057] Based on the preset token replenishment rules, on the one hand, tokens can be evenly distributed to various business departments to ensure that the business services of each business department can operate normally. On the other hand, the consumption rate of global tokens by a business department can also be controlled to control the amount of tokens consumed by that business department.
[0058] After determining the number of departmental licenses to be allocated, the next step is step 205. If the number of departmental licenses to be allocated is less than the target number, it means that relying solely on the current department's own token quota is insufficient to meet the target number. In this case, it is necessary to borrow a certain number of tokens from other departments to reach the target number.
[0059] Specifically, by calculating the difference between the number of departmental licenses allocated and the target allocation number, the number of tokens to be borrowed, i.e., the number of tokens that need to be temporarily borrowed from other departments, can be determined. After determining the number to be borrowed, the next step is to identify idle departments among the peer departments of the business department in the business scenario, and borrow tokens from the idle departments.
[0060] Peer departments refer to other business departments that jointly participate in the consumption of business resources within the same business scenario. For example, in a recruitment platform, business scenarios include push notifications, similar job recommendations, multiple application recommendations, and recommendations for popular job postings in the market. The Marketing, Operations, and Advertising departments can all provide business services within the push notification business scenario.
[0061] For example, an idle department is a department that has not performed business services for a long time in a business scenario. Since the global system will also replenish tokens to idle departments based on the preset token replenishment rules, there will be a certain amount of unused tokens when idle departments do not perform business services.
[0062] Optionally, when determining the idle departments, the current load status of the departments or the estimated business growth trend can be combined to screen the idle departments, thereby avoiding long-term, one-way token consumption for a certain department.
[0063] After identifying the available departments, step 206 involves extracting tokens from the department tokens within the business scenario based on the number of departmental permits allocated, and extracting tokens from the remaining tokens in the available departments based on the borrowing quantity, and allocating the extracted tokens to the token requesting end.
[0064] For example, if the marketing department does not use all the allocated token resources within a certain period of time, and the operations department needs more token resources, the idle token resources of the marketing department can be borrowed, thus enabling effective token reuse.
[0065] Based on the embodiments of this application, when global token resources are limited, tokens can be adjusted within the same scenario. Thus, when global allocation is allowed, the actual needs of the token requesting end can be met by borrowing tokens. This not only improves the service response speed and service quality of business departments during peak business periods, but also makes effective use of the remaining tokens of idle departments, thereby increasing the utilization rate of idle tokens and reducing resource idleness.
[0066] In some embodiments of this application, the number of departmental licenses allocated to a business department within a business scenario is determined based on the scenario identifier and the department identifier. Specifically, the following steps can be referenced: Based on the department identifier and the scenario identifier, the number of remaining departmental tokens and the idle time of the business department within the business scenario are obtained from the traffic configuration information table; the number of departmental licenses allocated is determined based on the token distribution threshold, the number of remaining departmental tokens, and the idle time.
[0067] Specifically, based on the department identifier and scenario identifier, information such as the number of remaining tokens for a department and the last time a token was allocated can be extracted from the traffic configuration information table. The number of remaining tokens for a department refers to the number of tokens remaining for that business department within that business scenario after the last token allocation. For example, the traffic configuration information table can be shown in Table 1.
[0068] Table 1:
[0069] Scene:A1, scene:A2, and scene:A3 represent different business scenario identifiers. The table records token usage records for the Marketing, Operations, and Advertising departments in different departments. `left permit` indicates the remaining token quantity for the `left permit` department, and `last access` indicates the last active time. By recording metadata such as the last active time of each business department within a business scenario, the table provides a foundation for identifying and borrowing idle resources, and is a prerequisite for the effective reuse and release of token resources.
[0070] Based on the last token allocation time and the current time, the idle time of the business unit in this scenario can be accurately determined, that is, the duration during which the business unit has not consumed any tokens in the business scenario.
[0071] The token distribution threshold refers to the maximum range of tokens that a single business unit can allocate within a single business scenario. By setting a token distribution threshold, excessive consumption of token resources by a single business unit can be avoided. Optionally, the token distribution threshold can be determined based on QPS, where QPS can be used to identify the maximum number of accesses allowed per unit of time for a certain resource.
[0072] Next, the remaining number of tokens in a department can be compared with the token distribution threshold, and the number of permissions allocated to the department can be dynamically adjusted based on the idle time. For example, when the idle time is long, it indicates that the business department consumes fewer tokens in the business scenario, and the number of supplementary tokens can be appropriately increased without exceeding the token distribution threshold, thereby increasing the number of permissions allocated to the department. When the idle time is short, it indicates that the business department consumes more tokens in the business scenario, therefore, it is not allowed to supplement too many tokens to control the number of permissions allocated to the department from being too high.
[0073] Ultimately, based on the token distribution threshold, the number of remaining tokens in a department, and the idle time, the system can estimate in real time the number of departmental licenses that should have been allocated since the last access. This allows the system to automatically replenish the token resources of business departments in real time, based on the real-time usage status of business departments in business scenarios. This avoids long-term resource lockout due to short-term sudden exhaustion and improves time utilization within a single scenario.
[0074] In some embodiments, the number of licenses allocated to a department is determined based on a token distribution threshold, the number of remaining tokens in the department, and the idle time. Specifically, this may include the following steps: determining the current remaining usage of the business department based on the token distribution rate corresponding to the token distribution threshold, the number of remaining tokens in the department, and the idle time; and determining the minimum value between the token distribution threshold and the current remaining usage as the number of licenses allocated to the department.
[0075] Specifically, the token distribution rate corresponding to the token distribution threshold represents the maximum number of tokens allowed to be distributed to business departments per unit of time. By combining the token distribution rate, the number of remaining tokens in the department, and the idle time, the number of tokens that the business department can continue to consume at the current moment, i.e., the current remaining usage, can reflect the upper limit of token resources that the department can use and the recovery space of token resources accumulated over time. This allows for the reasonable replenishment of the number of tokens in the current business scenario for the business department, avoiding the over-allocation of token resources.
[0076] After determining the current remaining usage, the token distribution threshold is compared with the current remaining usage, and the minimum of the two is selected as the number of departmental licenses allocated to the business department within the stated business scenario. Based on this, the number of departmental licenses allocated will not exceed the token distribution threshold, thereby ensuring that the token consumption of departments within a unit of time is always under control. At the same time, the number of departmental licenses allocated will not exceed the current remaining usage, ensuring the uniformity of global token distribution.
[0077] In some embodiments, determining the current remaining usage of a business department based on the token distribution rate corresponding to the token distribution threshold, the number of remaining tokens in the department, and the idle time includes: determining the current token allocation amount of the business department based on the product of the token distribution rate and the idle time; and determining the current remaining usage of the business department based on the sum of the current token allocation amount and the number of remaining tokens in the department.
[0078] For example, the calculation process can be shown in formula (1): Current remaining usage = left permit + (now() - last access) QPS / 1000 Where left permit refers to the number of tokens remaining in the department, now() is the current time, last access is the time of the last token allocation, now()-last access is the idle time, and QPS / 1000 is the token distribution rate. QPS / 1000 is just an example, and the specific value can be adjusted according to actual needs.
[0079] After calculating the number of departmental licenses to be allocated, a specific token acquisition strategy can be determined based on the relationship between the number of departmental licenses allocated and the target allocation number, and the acquired tokens can be allocated to the token requesting party. For example, when the number of departmental licenses allocated is greater than or equal to the target allocation number, tokens are extracted from the departmental tokens within the business scenario according to the target allocation number, and the tokens are allocated to the token requesting party.
[0080] If the number of departmental permits allocated is less than the target allocation, tokens need to be obtained by borrowing from departments at the same level.
[0081] In some embodiments of this application, the number of peer departments is at least one; determining idle departments among the peer departments of the business department in the business scenario includes: obtaining the current time and the last active time of each peer department; determining the idle duration of each peer department based on the current time and the last active time of each peer department; and determining idle departments with an idle duration greater than a preset duration as idle departments.
[0082] For example, the last active time refers to the time when a token was last consumed by a peer department, or the time when a token was last allocated to a peer department. This time can be recorded in the traffic configuration information table.
[0083] Based on the time difference between the current time and the corresponding last active time, the idle time of each peer department is determined.
[0084] Next, the idle time of each peer department is compared with a preset time. When the idle time of a peer department exceeds the preset time, that peer department is considered idle in the current business scenario and is identified as an idle department. The preset time can be 2 minutes or other durations, which can be adjusted according to actual application needs. Based on this, idle departments can be quickly and accurately identified within the business scenario.
[0085] In some embodiments, extracting tokens from the remaining tokens in an idle department based on the borrowing quantity includes: when there are multiple idle departments, determining the corresponding borrowing priority for each idle department; extracting tokens according to the borrowing order corresponding to the borrowing priority, until the number of extracted tokens reaches the borrowing quantity, or there are no tokens available to extract from the idle department.
[0086] In some embodiments, if it is found that the token resources of the idle department are being used during the process of borrowing a token from the idle department, the borrowing can be abandoned immediately to ensure that the idle department's own business services can operate normally.
[0087] Specifically, borrowing priority can be determined based on multiple factors, such as the number of tokens allowed to be borrowed by each idle department, the idle time, the historical token borrowing frequency, or the importance of the department to the overall business operation. For example, idle departments with longer idle times or lower historical token consumption can be assigned higher borrowing priority, while departments with shorter idle times and higher business needs can be assigned lower borrowing priority.
[0088] Optionally, the number of tokens that can be borrowed by each idle department can be determined based on the number of departmental licenses allocated to the idle department in the current business scenario. For example, the number of tokens that can be borrowed may be less than or equal to the number of departmental licenses allocated to the idle department in the current business scenario. The method for determining the number of departmental licenses allocated to the idle department in the current business scenario can refer to the method for determining the number of departmental licenses allocated to the current business department, which will not be elaborated here.
[0089] In some embodiments, when borrowing tokens, tokens can be drawn sequentially starting from the highest priority available departments. If all tokens in an available department have been drawn during the borrowing process, that department is skipped, and the process continues to the next higher priority department.
[0090] Based on the embodiments of this application, the borrowing priority of each idle department ensures that the real-time load and actual needs of each department are fully considered during resource scheduling. This makes the borrowed resources more consistent with the actual usage of each department, thereby avoiding situations where some idle departments over-borrow or some departments are unable to obtain the required tokens in a timely manner. Simultaneously, the mechanism of extracting tokens sequentially according to borrowing priority effectively avoids competition between multiple idle departments, making resource allocation more orderly.
[0091] To more clearly explain the dynamic reuse method of tokens, Figure 3 This is a flowchart of another token dynamic reuse method according to an embodiment of this application.
[0092] Specifically, upon receiving the token request, in conjunction with Table 1 and Figure 3 As shown.
[0093] Step 1: Read the traffic configuration information table to obtain the following content.
[0094] Get the global:limit {left_permit:9000, last_access:1717020000, qps:9000}; Get scene:A1:marketing {left_permit:3000, last_access:1717020000,qps:3000}; Get scene:A1:operation {left_permit:1500, last_access:1717020000,qps:1500}; The initial value is can_acquire_permit = 500.
[0095] Step 2: Determine if the global token quota is sufficient.
[0096] Specifically, if global:limit.left_permit is less than or equal to 0, then failure is returned; Otherwise, update can_acquire_permit = min(500, global:limit.left_permit).
[0097] Step 3: Calculate the current scenario quota for the department.
[0098] That is, calculate the latest department license allocation quantity of the current department. Specifically, use the minimum value of the token distribution threshold and the current remaining usage quantity, and determine it as the department license allocation quantity. Optionally, when accessing the traffic configuration information table this time, the information of each business department in the current scenario can be directly read from the table, and the current remaining usage quantity of each business department can be calculated, thereby reducing the number of accesses to the traffic configuration information table.
[0099] Calculate in combination with formula (1): Current remaining usage quantity = left permit + (now() - last access)QPS / 1000.
[0100] Step 4: Determine whether the scenario quota of the current business department is satisfied.
[0101] Taking the current business department scene:A1:marketing as an example, if it is judged that: scene:A1:marketing.left_permit >= can_acquire_permit, then it can be satisfied and there is no need to borrow. Next, update the scenario quotas of the global and peer departments; Update scene:A1:marketing.left_permit -= can_acquire_permit; Update scene:A1:marketing.last_access = now(); Update global:limit.left_permit -= can_acquire_permit; Update global:limit.left_permit -= can_acquire_permit; Return the available quota can_acquire_permit.
[0102] Step 5: Otherwise, borrow the quota of the peer department.
[0103] If it is judged that: scene:A1:marketing.left_permit < can_acquire_permit, then it cannot be satisfied and borrowing is required; and update the global configuration global:limit.left_permit -= scene:A1:marketing.left_permit The required borrowing limit is updated to need_borrow_permit=can_acquire_permit - scene:A1:marketing.left_permit; Update the market configuration: scene:marketing:A1.left_permit = 0 and last_access = now(); Calculate the amount of space that can be borrowed: can_borrow_permit = min(need_borrow_permit, scene:A1:{$dept}.left_permit); Calculate global:limit.left_permit -= (can_borrow_permit); Calculate scene:A1:{$dept}.left_permit -= can_borrow_permit; Calculate need_borrow_permit -= can_borrow_permit; If need_borrow_permit = 0, exit the loop; otherwise, find another department in the same category and continue borrowing until the required number of borrow permits is met. Finally, update global:limit.left_permit,cene:A1:{$dept}.left_permit to return the available quota can_acquire_permit- need_borrow_permit.
[0104] According to the embodiments of this application, a dynamic resource reuse mechanism based on idle detection and priority sorting determines whether the last access time of the same level business scenario exceeds the threshold, and combines the sorting strategy to realize quota borrowing, so that the underutilized licensed resources can be safely and orderly transferred between multiple scenarios, thereby improving the overall resource utilization rate.
[0105] Furthermore, based on the embodiments of this application, idle resources are effectively utilized through dynamic license adjustment and resource reuse mechanisms, improving the overall system resource utilization rate. By borrowing tokens from peer departments, the system can better cope with sudden traffic surges, ensuring service stability and response speed. Automated dynamic adjustment and resource reuse reduce the need for manual intervention, simplifying operation and maintenance and improving efficiency. At the same time, priority support and flexible resource scheduling ensure that various business scenarios obtain resources on demand, improving user experience and business efficiency.
[0106] Corresponding to the method embodiments of this application, this application also provides a token dynamic reuse device. The token dynamic reuse device of this application embodiment can correspond to the execution subject of the token dynamic reuse method provided in the token dynamic reuse method of this application embodiment. For the specific details of the operation and / or function of each module / unit of the token dynamic reuse device, please refer to the description of the corresponding part in the method provided in the above-mentioned embodiments of this application. For the sake of brevity, it will not be repeated here.
[0107] The electronic device in this application embodiment may be a user terminal device, a server, other computing devices, or a cloud server. Figure 4 The diagram shows the hardware structure of an electronic device according to an embodiment of this application. The electronic device may include a processor 401 and a memory 402 storing computer program instructions. When the processor 401 executes the computer program instructions, it implements the process or function of any of the methods described above.
[0108] Specifically, processor 401 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Memory 402 may include a mass storage device for data or instructions. For example, memory 402 may be at least one of the following: a hard disk drive (HDD), read-only memory (ROM), random access memory (RAM), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, universal serial bus (USB) drive, or other physical / tangible memory storage device. Alternatively, memory 402 may include removable or non-removable (or fixed) media. Furthermore, memory 402 may be internal or external to the integrated gateway disaster recovery device. Memory 402 may be non-volatile solid-state memory. In other words, typically memory 402 includes a tangible (non-transitory) computer-readable storage medium (such as a memory device) encoded with computer-executable instructions, and when the software is executed (e.g., by one or more processors), it can perform the operations described in the methods of the embodiments of this application. The processor 401 implements the process or function of any of the methods described above by reading and executing computer program instructions stored in the memory 402.
[0109] In one example Figure 4The illustrated electronic device may also include a communication interface 403 and a bus 410. The processor 401, memory 402, and communication interface 403 are connected via bus 410 and communicate with each other. Communication interface 403 is primarily used to enable communication between modules, devices, units, and / or equipment in the embodiments of this application. Bus 410 may include hardware, software, or both, and can couple components of the online data traffic billing device together. For example, the bus may include at least one of the following: Accelerated Graphics Port (AGP) or other graphics bus, Enhanced Industry Standard Architecture (EISA) bus, Front Side Bus (FSB), HyperTransport (HT) Interconnect, Industry Standard Architecture (ISA) bus, Infinite Bandwidth Interconnect, Low Pin Count (LPC) bus, memory bus, Microchannel Architecture (MCA) bus, Peripheral Component Interconnect (PCI) bus, PCI-Express (PCI-X) bus, Serial Advanced Technology Attachment (SATA) bus, Video Electronics Standards Association Local (VLB) bus, or other suitable buses. Bus 410 may include one or more buses. Although specific buses are described or illustrated in the embodiments of this application, any suitable bus or interconnection method may be considered in the embodiments of this application.
[0110] In conjunction with the methods in the above embodiments, this application also provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the process or function of any of the methods in the above embodiments.
[0111] In addition, this application also provides a computer program product that stores computer program instructions, which, when executed by a processor, implement the process or function of any of the methods described above.
[0112] The flowcharts and / or block diagrams of methods, apparatuses, systems, and computer program products according to embodiments of this application have been exemplarily described above, and related aspects have been described. It should be understood that each block or combination thereof in the flowcharts and / or block diagrams may be implemented by computer program instructions, by dedicated hardware performing a specified function or action, or by a combination of dedicated hardware and computer instructions. For example, these computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to form a machine that enables the implementation of the function / action specified in each block or combination thereof in the flowcharts and / or block diagrams, executable via such processor. Such a processor may be a general-purpose processor, a dedicated processor, a special-purpose application processor, or a field-programmable logic circuit.
[0113] The functional blocks shown in the structural block diagrams of this application can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc.; when implemented in software, they are programs or code segments used to perform the required tasks. Programs or code segments can be stored in memory or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. Code segments can be downloaded via computer networks such as the Internet or intranets.
[0114] It should be noted that this application is not limited to the specific configurations and processes described above or shown in the figures. The above descriptions are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the described systems, devices, modules, or units can be referred to the corresponding processes in the method embodiments, and need not be repeated here. It should be understood that the scope of protection of this application is not limited thereto. Any person skilled in the art can conceive of various equivalent modifications or substitutions within the scope of the technology disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application.
Claims
1. A method for dynamic reuse of tokens, characterized in that, The methods include: Receive token requests, wherein the token request includes the number of token requests, the scenario identifier of the business scenario corresponding to the token requesting end, and the department identifier of the business department corresponding to the token requesting end; Get the total number of tokens remaining globally; If the number of remaining global tokens is greater than a first preset number, the target allocation number is determined based on the number of remaining global tokens and the number of token requests. Based on the scenario identifier and the department identifier, determine the number of department licenses allocated to the business department within the business scenario; If the number of departmental licenses allocated is less than the target number of allocations, the number of tokens to be borrowed is determined based on the number of departmental licenses allocated and the target number of allocations. as well as, Identify vacant departments among the peer departments of the business department within the stated business scenario; Based on the number of departmental permits allocated, tokens are extracted from the departmental tokens within the business scenario, and based on the number of borrowed tokens, tokens are extracted from the remaining tokens in the idle departments, and tokens are allocated to the token requesting end.
2. The method according to claim 1, characterized in that, The step of determining the target license allocation quantity based on the global remaining token quantity and the token request quantity includes: The minimum value between the global remaining token count and the token request count is determined as the target license allocation quantity.
3. The method according to claim 1, characterized in that, The step of determining the number of departmental licenses allocated to the business department within the business scenario based on the scenario identifier and the department identifier includes: Based on the department identifier and the scenario identifier, obtain the number of remaining tokens for the business department in the business scenario and the idle time of the business department in the traffic configuration information table; The number of licenses allocated to a department is determined based on the token distribution threshold, the number of remaining tokens in the department, and the idle time.
4. The method according to claim 3, characterized in that, The process of determining the number of departmental licenses to be allocated based on the token distribution threshold, the number of remaining tokens in the department, and the idle time includes: The current remaining usage of the business department is determined based on the token distribution rate corresponding to the token distribution threshold, the number of remaining tokens in the department, and the idle time. The minimum of the token distribution threshold and the current remaining usage quantity is determined as the number of departmental licenses to be allocated.
5. The method according to claim 4, characterized in that, The step of determining the current remaining usage of the business department based on the token distribution rate corresponding to the token distribution threshold, the number of remaining tokens in the department, and the idle time includes: The current token allocation amount for the business department is determined based on the product of the token distribution rate and the idle time. The current remaining usage of the business department is determined based on the sum of the current token allocation and the remaining token quantity of the department.
6. The method according to claim 1, characterized in that, The number of peer departments is at least one; determining the available department among the peer departments of the business department within the business scenario includes: Get the current time and the last active time of each of the aforementioned peer departments; Based on the current time and the last active time of each of the peer departments, determine the idle time of each of the peer departments; Idle sections whose idle duration is greater than a preset duration are defined as idle sections.
7. The method according to any one of claims 1-6, characterized in that, The step of extracting tokens from the remaining tokens in the idle department based on the borrowed amount includes: When there are multiple vacant departments, determine the borrowing priority for each vacant department; Tokens are extracted according to the borrowing priority and borrowing order until the number of extracted tokens reaches the borrowing quantity, or until there are no tokens available to be extracted from the idle department.
8. The method according to claim 1, characterized in that, The method further includes: When the number of departmental license allocations is greater than or equal to the target allocation number, the token is extracted from the departmental tokens within the business scenario by the business department according to the target allocation number, and the token is allocated to the token requesting end.
9. The method according to claim 1, characterized in that, The method further includes: If the number of remaining global tokens is less than or equal to the first preset number, the number of tokens allocated to the token requester is zero.
10. A computer program product, characterized in that, It includes computer program instructions that, when executed by a processor, implement the method as described in any one of claims 1-9.