Adaptive token request method, electronic device and computer program product

Abstract

The invention discloses an adaptive token request method, electronic equipment and a computer program product. The method comprises the steps that request results of a current service department for continuously requesting tokens for N times are obtained, the request results comprise successful requests or unsuccessful requests, and N is a positive integer; adjusting the request number of the current token based on the number of times of successfully requesting the token in the N continuous request results; and generating a token request based on the request number of the current token, and sending the token request to a token distribution end. According to the embodiment of the invention, the number of times of frequently initiating small-batch token applications to the token distribution end can be reduced, the processing pressure of the token distribution end is reduced, and the token distribution end can intensively schedule global resources in a more stable application mode.

Description

Technical Field

[0001] This application relates to the field of computer communication technology, and in particular to an adaptive token request method, electronic device, and computer program product. Background Technology

[0002] As businesses expand, they often set up multiple business nodes to handle different business scenarios and provide diversified services. For example, in a recruitment platform, there are various business scenarios such as push notifications, similar job recommendations, recommendations for multiple applications, and recommendations for popular job postings. Each business node needs to obtain resources from the enterprise operations platform to provide its services. For instance, the platform can provide tokens to each business node to control its traffic, API call quotas, message consumption, and computing resources.

[0003] Because different business nodes consume varying amounts of resources, ensuring the stability and availability of enterprise services requires balancing resource consumption across different business scenarios. Therefore, it's necessary to limit the resource consumption of each business node to prevent excessive resource consumption by some nodes. However, if service demand increases in a particular business scenario, the requesting party will frequently request tokens from the platform. Such frequent requests put pressure on the platform, increasing latency and creating performance bottlenecks. Furthermore, if the business requests consume a large amount of resources, token requests may be rejected by the platform under its limitations, impacting the service quality of the business scenario and consequently affecting user experience. To address these issues, it's necessary to provide an adaptive token request method to reduce platform load and improve the success rate of token requests. Summary of the Invention

[0004] In view of this, embodiments of this application provide an adaptive token request method, an electronic device, and a computer program product to solve at least one technical problem.

[0005] This application provides an adaptive token request method, including: obtaining the request results of N consecutive token requests from the current business department, where the request results include successful requests or unsuccessful requests, and N is a positive integer; adjusting the current token request quantity based on the number of successful token requests in the N consecutive request results; generating a token request based on the current token request quantity, and sending the token request to the token allocation end.

[0006] Optionally, in some embodiments of this application, obtaining the request results of the current business department's continuous N token requests includes: obtaining the number of tokens requested each time and the number of tokens actually obtained each time; for each token request, if the number of tokens requested is equal to the number of tokens actually obtained, the request result is a successful request; if the number of tokens requested is less than the number of tokens actually obtained, the request result is a failed request.

[0007] Optionally, in some embodiments of this application, adjusting the current token request quantity based on the number of times the token was successfully requested in N consecutive request results includes: if the N consecutive request results are all successful requests, determining the current token request quantity based on the number of tokens obtained in the previous request, wherein the current token request quantity is greater than the number of tokens obtained in the previous request.

[0008] Optionally, in some embodiments of this application, determining the current token request quantity based on the number of tokens obtained in the previous request includes: obtaining a token base and an influence factor on the number of tokens obtained; determining the token increase quantity based on the product of the token base and the influence factor; and using the sum of the token increase quantity and the number of tokens obtained in the previous request as the current token request quantity.

[0009] Optionally, in some embodiments of this application, obtaining the token influence factor includes: determining the number of times X in which the number of tokens obtained in the last request is greater than or equal to the token base if the number of tokens obtained in the last request is greater than or equal to the token base; determining the value of the token influence factor according to a preset number range corresponding to the number of times X, wherein the larger the value of the preset number range corresponding to the number of times X, the smaller the value of the token influence factor.

[0010] Optionally, in some embodiments of this application, adjusting the current token request quantity based on the number of successful token requests in N consecutive request results includes: if the most recent M requests are unsuccessful, obtaining the number of tokens obtained in each of the M requests, where M is less than N and M is a positive integer; calculating the average of the number of tokens obtained in the M requests to obtain the current token request quantity.

[0011] Optionally, in some embodiments of this application, generating a token request based on the current number of token requests further includes: obtaining the scenario identifier of the business scenario corresponding to the business activity to be processed and the department identifier of the current business department; and generating a token request based on the current number of token requests, the scenario identifier, and the department identifier.

[0012] This application provides an electronic device, which includes a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the steps of the method described above.

[0013] 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.

[0014] This application provides a computer program product, which includes computer program instructions that, when executed by a processor, implement the steps of the method described above.

[0015] In the embodiments of this application, the token requesting end obtains the results of N consecutive token requests each time it needs to request a token. Based on these consecutive request results, the number of tokens requested for the current request is dynamically generated. For example, if tokens are successfully obtained consecutively, the token requesting end can tentatively increase the number of requests for the current request. Conversely, if there are many consecutive failed requests, the load is proactively reduced to avoid request rejection. By automatically adjusting the number of token requests, excessive resource contention or insufficient request volume can be effectively reduced, improving the success rate of requests. Simultaneously, since the token requesting end can automatically adjust the number of requests based on historical request results, the number of frequent small-batch token requests to the token allocation end can be reduced, decreasing the processing pressure on the token allocation end. This allows the token allocation end to centrally schedule global resources in a more stable request mode. Especially in environments where multiple business departments share resources, this effectively improves the resource allocation efficiency and overall operating performance of the token allocation end, and reduces resource waste caused by invalid token requests. Attached Figure Description

[0016] 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.

[0017] Figure 1 This is a schematic diagram of the system architecture of an embodiment of this application.

[0018] Figure 2 This is a flowchart of the adaptive token request method according to an embodiment of this application.

[0019] Figure 3 This is a schematic diagram of an electronic device used to implement the embodiments of this application. Detailed Implementation

[0020] 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.

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] The token request terminal 102a can be any service device corresponding to any business department that needs to use rate-limited resources.

[0028] When providing services for a business scenario, token requester 102a needs to request a certain number of tokens from token distribution provider 104. After token distribution provider 104 provides the tokens, it can provide the services for that business scenario. A permission token represents the unit of operation authorization for a single request. Each request requires "acquiring one or more permissions" to execute. By controlling the number of tokens consumed by the token requester, the traffic rate can be controlled.

[0029] 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.

[0030] Optionally, a Redis table can be maintained at the token distribution end 104. A Redis table is an in-memory key-value store that supports various data structures; for example, a hash table is one type that allows mapping a key to a collection of multiple field-value pairs, suitable for storing object-type data. In this embodiment, it is used to store configuration information for various rate-limiting scenarios.

[0031] Based on the embodiments of this application, when the token requesting end needs to request a token, it obtains the request results of N consecutive token requests each time. Then, it dynamically generates the number of tokens requested this time based on the consecutive request results. Responding to the token request from the token requesting end, the token allocation end can centrally schedule global resources in a more stable request mode, reducing its processing pressure. Especially in environments where multiple business departments share resources, it can effectively improve the resource allocation efficiency and overall operating performance of the token allocation end, and reduce resource waste caused by invalid token requests.

[0032] Figure 2 A flowchart of an adaptive token request method according to an embodiment of this application is shown, the method including steps 201 to 203.

[0033] Step 201: Obtain the request results of the current business department's N consecutive token requests. The request results include successful requests or unsuccessful requests, where N is a positive integer.

[0034] Step 202: Adjust the current token request quantity based on the number of successful token requests in the results of N consecutive requests.

[0035] Step 203: Based on the current number of token requests, generate a token request and send the token request to the token distribution end.

[0036] The above steps will be described in detail below with reference to specific embodiments, as shown in the following figures.

[0037] First, regarding step 201, after each token request is sent to the token allocator, the token requesting end receives the token allocated by the token allocator. For each token request, by comparing the actual number of tokens received by the token requesting end with the number requested in the token request, the result of each token request can be quickly determined.

[0038] For example, to obtain the request results of the current business department making N consecutive token requests, specifically: obtain the number of tokens requested each time and the number of tokens actually obtained in each request; for each token request, if the number of tokens requested is equal to the number of tokens actually obtained, the request result is a successful request; if the number of tokens requested is less than the number of tokens actually obtained, the request result is a failed request.

[0039] Next, steps 202 and 203 are involved. Before initiating a new token request on the token requesting end, the result data of the previous N consecutive token requests are obtained first, where N is a positive integer and can be set according to business needs.

[0040] By determining the results of N consecutive token requests, it can be ascertained whether the token allocation end has sufficient token resources. Therefore, the number of requests can be dynamically adjusted based on historical success rates. For example, if there are consecutive successes, or if the current consecutive request results show a high success rate, indicating sufficient token resources at the token allocation end, then the number of requests for this token can be appropriately increased.

[0041] If failures occur frequently, or if the rate of consecutive failures is high, it indicates that the token resources on the token allocation end are insufficient, or that the token resources available for consumption in the current business scenario are insufficient. Therefore, it is necessary to reduce the number of token requests to reduce the resource consumption pressure on the token allocation end.

[0042] After determining the current number of token requests, the token requesting end generates the current token request based on the determined number of token requests and sends the token request to the token distribution end for processing.

[0043] For example, a Redis table is maintained on the token allocation end to record configuration information for each token requester, including the number of tokens requested each time, the number of available tokens, the number of tokens used, and the number of globally available tokens. By dynamically adjusting the number of tokens requested in subsequent requests based on the number of successfully requested tokens, the number of accesses to the token allocation end is reduced during peak business periods due to high token demand, thus improving the operational stability of the token allocation end. Simultaneously, when the number of allocable tokens on the token allocation end is insufficient, excessive requests are avoided, reducing the operational pressure on the token allocation end and ensuring the overall stability of the token allocation end's operation.

[0044] In some embodiments of this application, generating a token request based on the current number of token requests further includes: obtaining the scenario identifier of the business scenario corresponding to the business activity to be processed and the department identifier of the current business department; and generating a token request based on the current number of token requests, the scenario identifier, and the department identifier.

[0045] For example, the business activity to be processed could be content recommendation within a specific business scenario by a specific business department.

[0046] Specifically, a recruitment platform can have multiple business departments, such as Marketing, Operations, and Advertising. Simultaneously, the platform can handle 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 relevant scenario based on its business needs and request tokens from the token distribution center to recommend content.

[0047] Therefore, by packaging the scene identifier and department identifier together into the token request, the token distribution end can easily analyze whether it can distribute the requested number of tokens to the token requesting end.

[0048] In some embodiments of this application, adjusting the current token request quantity based on the request results of N consecutive token requests includes: if the N consecutive request results are all successful requests, determining the current token request quantity based on the token quantity obtained in the previous request, wherein the current token request quantity is greater than the token quantity obtained in the previous request.

[0049] Specifically, if N consecutive requests are successful, actively increasing the number of token requests reduces the processing pressure on the token distribution end by repeatedly making small token requests. This allows the token requesting end to obtain enough tokens in fewer interactions, thereby improving the efficiency of token requests and reducing the operational pressure on the token distribution end.

[0050] In some embodiments, the current number of token requests is determined based on the number of tokens obtained in the previous request. Specifically, the following steps can be referenced: obtaining the token base and the influence factor of the number of tokens obtained; determining the token increase amount based on the product of the token base and the influence factor; and using the sum of the token increase amount and the number of tokens obtained in the previous request as the current number of token requests.

[0051] For example, if the token base is 300, the influence factor is 1 / 4, and the number of tokens obtained in the last request was 225, then if N consecutive requests are successful, the token increase is determined to be 75. In the (N+1)th request, the request quantity will be 225 + 75 = 300. The token base and influence factor can be preset values.

[0052] Based on this, the gradual increase of the number of token requests can be controlled automatically, reducing the need for manual intervention to adjust the number of token requests. Automated dynamic adjustment and resource reuse reduce the need for manual intervention, simplify operation and maintenance, and further improve business efficiency.

[0053] In some optional embodiments, if a token request is sent to the token distribution terminal for the first time, the token request can be based on a pre-set initial token quantity, for example, the initial token quantity could be base / 2 = 150. After the number of request results reaches N, the token quantity is then adjusted.

[0054] It is understood that the specific numerical values ​​mentioned above are merely examples and not specific limitations on the embodiments of this application.

[0055] Based on the embodiments of this application, the number of subsequent request tokens can be dynamically adjusted according to the number of successful request tokens, which can effectively reduce the number of token requests, avoid frequent Redis operations on the token allocation end, thereby reducing the feedback latency of the token allocation end and improving the request experience of the token requesting end.

[0056] In some embodiments, in order to more accurately control the token adjustment quantity, the token influence factor can also be adjusted in combination with the request result. Specifically, if the result of N consecutive requests is a successful request, it is necessary to continue to increase the number of tokens requested in this request, and determine whether the number of tokens obtained in the previous request is greater than or equal to the token base. Optionally, if it is less than the token base, the token influence factor is not adjusted, and the number of tokens to be increased is determined based on the product of the token base and the influence factor.

[0057] If the number of tokens obtained in the previous request is greater than or equal to the token base, then it is necessary to re-obtain the token impact factor. For example, obtaining the token impact factor can refer to the following steps: If the number of tokens obtained in the previous request is greater than or equal to the token base, determine the number X of consecutive requests where the number of tokens obtained is greater than or equal to the token base; based on the preset range corresponding to the number X, determine the value of the token impact factor, where the larger the value of the preset range corresponding to the number X, the smaller the value of the token impact factor.

[0058] For example, the length of the preset number of iterations is 3, and the preset number of iterations can be multiple non-overlapping ranges such as [1,3], [4,6], [7,9], ..., [m,m+3]. Here, m is a positive integer.

[0059] Different preset number ranges correspond to different token influence factor values. For example, preset number ranges correspond to token influence factors of 1 / 8, 1 / 16, 1 / 32, and other values. The larger the preset number range value corresponding to the number of times X is, the smaller the token influence factor value.

[0060] The length of the preset number of times range can be adjusted. For example, the length of the preset number of times range can be 4, or it can be other values.

[0061] After the number of tokens obtained in the previous request exceeded the token base, the number of consecutive requests where the number of tokens obtained exceeded the token base (e.g., base=300) can be determined as X. For example, if the number of requests is 1, corresponding to a preset number range [1,3], the token influence factor is 1 / 8. Based on this, the token increase is calculated as 300*1 / 8, which, after rounding, becomes 37, representing the token increase for this request. The sum of the tokens obtained in the previous request and the token increase is then calculated to obtain the number of tokens requested in this request.

[0062] As the number of token requests increases, by reducing the number of tokens added each time, the consumption of token resources by the current token requesting terminal can be controlled, avoiding excessive token resource occupation and reducing resource competition between different token requesting terminals.

[0063] In some embodiments of this application, adjusting the current token request quantity based on the results of N consecutive token requests may further include the following steps: if the most recent M requests were unsuccessful, obtain the token quantity obtained in each of the M requests, where M is less than N and M is a positive integer; calculate the average of the token quantities obtained in the M requests to obtain the current token request quantity.

[0064] For example, taking M=2, if the number of tokens received in two consecutive requests is less than the number of requests, for example, the number of tokens received in the first request is m1 and the number of tokens received in the second request is m2, then the new n=(m1+m2) / 2, and the number of tokens requested in this request is dynamically reduced based on the number of tokens received from the token allocation terminal in the previous two requests.

[0065] Based on the embodiments of this application, by automatically adjusting the number of tokens requested each time, the occurrence of request rejection can be reduced, enabling the token requesting end to obtain the required tokens and successfully provide business services for the business scenario.

[0066] Corresponding to the method embodiments of this application, this application also provides an adaptive token request device. The adaptive token request device of this application embodiment can correspond to the execution body of the adaptive token request method provided in the embodiments of this application. For specific details of the operation and / or function of each module / unit of the adaptive token request device, please refer to the description of the corresponding part in the method provided in the above embodiments of this application.

[0067] The electronic device in this application embodiment may be a user terminal device, a server, other computing devices, or a cloud server. Figure 3 The diagram shows the hardware structure of an electronic device according to an embodiment of this application. The electronic device may include a processor 301 and a memory 302 storing computer program instructions. When the processor 301 executes the computer program instructions, it implements the process or function of any of the methods described above.

[0068] Specifically, processor 301 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 302 may include a mass storage device for data or instructions. For example, memory 302 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 302 may include removable or non-removable (or fixed) media. Furthermore, memory 302 may be internal or external to the integrated gateway disaster recovery device. Memory 302 may be non-volatile solid-state memory. In other words, typically memory 302 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 301 implements the process or function of any of the methods described in the above embodiments by reading and executing computer program instructions stored in the memory 302.

[0069] In one example Figure 3 The illustrated electronic device may also include a communication interface 303 and a bus 310. The processor 301, memory 302, and communication interface 303 are connected via bus 310 and communicate with each other. The communication interface 303 is mainly used to realize communication between the various modules, devices, units, and / or equipment in the embodiments of this application. Bus 310 includes hardware, software, or both, and can couple the 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 310 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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. An adaptive token request method, characterized in that, The method includes: Obtain the request results of the current business department's N consecutive token requests, where the request results include successful requests or unsuccessful requests, and N is a positive integer; Adjust the current token request quantity based on the number of successful token requests out of N consecutive request results; Based on the current number of token requests, generate a token request and send the token request to the token distribution end.

2. The method according to claim 1, characterized in that, The step of obtaining the request results of the current business department's N consecutive token requests includes: Get the number of tokens requested for each request and the number of tokens actually obtained for each request; For each token request, if the number of tokens requested is equal to the number of tokens actually obtained, the request result is a successful request; If the number of tokens requested is less than the number of tokens actually obtained, the request result is a failed request.

3. The method according to claim 1, characterized in that, The adjustment of the current token request quantity based on the number of successful token requests out of N consecutive request results includes: If N consecutive requests are all successful, the number of requests for the current token is determined based on the number of tokens obtained in the previous request, wherein the number of requests for the current token is greater than the number of tokens obtained in the previous request.

4. The method according to claim 1, characterized in that, Determining the current token request quantity based on the token quantity obtained in the previous request includes: Influencing factors on the base number of tokens acquired and the number of tokens acquired; The number of tokens to be increased is determined based on the product of the token base and the influence factor. The sum of the token increment and the token quantity obtained in the previous request is used as the current token request quantity.

5. The method according to claim 4, characterized in that, Obtain token impact factors, including: If the number of tokens obtained in the last request is greater than or equal to the token base, determine the number X of consecutive requests where the number of tokens obtained is greater than or equal to the token base. The value of the token influence factor is determined based on the preset number range corresponding to the number of times X, wherein the larger the value of the preset number range corresponding to the number of times X, the smaller the value of the token influence factor.

6. The method according to claim 1, characterized in that, The adjustment of the current token request quantity based on the number of successful token requests out of N consecutive request results includes: In the case where the most recent M requests for tokens were unsuccessful, among the results of the N consecutive requests, the number of tokens obtained in each of the M requests is obtained, where M is less than N and M is a positive integer; Calculate the average number of tokens obtained from M requests to obtain the current number of token requests.

7. The method according to claim 1, characterized in that, The step of generating a token request based on the current number of token requests also includes: Obtain the scenario identifier of the business scenario corresponding to the business activity to be processed and the department identifier of the current business department; A token request is generated based on the current number of token requests, the scenario identifier, and the department identifier.

8. An electronic device, characterized in that, The electronic device includes a processor and a memory storing computer program instructions; when the electronic device executes the computer program instructions, it implements the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 7.

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 to 7.

Images