E-commerce platform request management method based on token bucket algorithm and terminal

Abstract

The invention discloses an e-commerce platform request management method based on a token bucket algorithm and a terminal. The method comprises the following steps: receiving request information sent by a calling party based on a message queue; determining a request type and an e-commerce platform interface according to the request information; acquiring a token bucket state configured based on the current limiting strategy of the e-commerce platform interface; if the request type is a synchronization request, determining whether to call the e-commerce platform interface according to the token bucket state; and if the request type is an asynchronous request, determining whether to delay calling of the e-commerce platform interface according to the token bucket state. According to the method, the requests of multiple types of e-commerce platform interfaces can be uniformly managed, the development difficulty is reduced, and the data acquisition efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of system request management, and in particular to an e-commerce platform request management method and terminal based on a token bucket algorithm. Background Art

[0002] In order to obtain data from overseas e-commerce platforms, the system needs to connect to the interfaces of the corresponding platforms. However, the interface flow control management solutions of various e-commerce platforms lack unified standards, and the flow control strategies for different e-commerce platforms are different. When connecting to some e-commerce platform interfaces, flow control management is required based on the access frequency of the API (Application Programming Interface), and when connecting to other e-commerce platform interfaces, flow control management is required based on the number of concurrent requests. Some e-commerce platforms also need to allocate request quotas on a daily or monthly basis. Since the interface flow control management solutions of various platforms lack unified standards, it not only increases the difficulty and workload of developers connecting to multiple e-commerce platform interfaces, but also reduces the efficiency of data acquisition. Summary of the invention

[0003] The technical problem to be solved by the present invention is to provide an e-commerce platform request management method and terminal based on a token bucket algorithm, which can uniformly manage requests from multiple types of e-commerce platform interfaces, reduce development difficulty, and improve data acquisition efficiency.

[0004] In order to solve the above technical problems, a technical solution adopted by the present invention is: The e-commerce platform request management method based on the token bucket algorithm includes: Receive request information sent by the caller based on the message queue; Determine the request type and the e-commerce platform interface according to the request information; Obtain the token bucket status based on the current limiting strategy configuration of the e-commerce platform interface; If the request type is a synchronous request, determining whether to call the e-commerce platform interface according to the token bucket status; If the request type is an asynchronous request, it is determined whether to delay calling the e-commerce platform interface according to the token bucket status.

[0005] In order to solve the above technical problems, another technical solution adopted by the present invention is: An e-commerce platform request management terminal based on a token bucket algorithm includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, each step in the above-mentioned e-commerce platform request management method based on a token bucket algorithm is implemented.

[0006] The beneficial effects of the present invention are: receiving the request information sent by the caller through the message queue, after determining the request type and the e-commerce platform interface according to the request information, obtaining the token bucket state configured by the current limiting strategy based on the currently requested e-commerce platform interface. When the request type is a synchronous request, it is determined whether to directly call the e-commerce platform interface according to the token bucket state. When the request type is an asynchronous request, it is determined whether to delay calling the e-commerce platform interface according to the token bucket state. In the present invention, token buckets are configured based on the current limiting strategies of different e-commerce platform interfaces respectively, and the request information is received in combination with the message queue, so that the caller can obtain the corresponding token bucket state to efficiently connect the current limiting strategies of different e-commerce platform interfaces, that is, the developer does not need to confirm the calling status of the interface separately, but only needs to send the request information, and the program automatically implements the current limiting management of different e-commerce platforms according to the token bucket state, thereby providing a unified interface access method for developers, realizing unified management of requests for multiple types of e-commerce platform interfaces, reducing development difficulty, and improving data acquisition efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 A flowchart of an e-commerce platform request management method based on a token bucket algorithm provided in an embodiment of the present invention; Figure 2 Another flow chart of the e-commerce platform request management method based on the token bucket algorithm provided in an embodiment of the present invention; Figure 3 A flowchart of another e-commerce platform request management method based on a token bucket algorithm provided by an embodiment of the present invention; Figure 4 A flowchart of a token bucket reset method provided by an embodiment of the present invention; Figure 5 A schematic diagram of the structure of an e-commerce platform request management terminal based on a token bucket algorithm provided by an embodiment of the present invention; Description of labels: 100. E-commerce platform request management terminal based on token bucket algorithm; 101. memory; 102. processor. DETAILED DESCRIPTION

[0008] In order to explain the technical content, achieved objectives and effects of the present invention in detail, the following is an explanation in combination with the implementation modes and the accompanying drawings.

[0009] An embodiment of the present invention provides an e-commerce platform request management method based on a token bucket algorithm, comprising: Receive request information sent by the caller based on the message queue; Determine the request type and the e-commerce platform interface according to the request information; Obtain the token bucket status based on the current limiting strategy configuration of the e-commerce platform interface; If the request type is a synchronous request, determining whether to call the e-commerce platform interface according to the token bucket status; If the request type is an asynchronous request, it is determined whether to delay calling the e-commerce platform interface according to the token bucket status.

[0010] As can be seen from the above description, the beneficial effects of the present invention are: receiving the request information sent by the caller through the message queue, and after determining the request type and the e-commerce platform interface according to the request information, obtaining the token bucket state configured by the current limiting strategy based on the currently requested e-commerce platform interface. When the request type is a synchronous request, it is determined whether to directly call the e-commerce platform interface according to the token bucket state. When the request type is an asynchronous request, it is determined whether to delay calling the e-commerce platform interface according to the token bucket state. In the present invention, token buckets are configured based on the current limiting strategies of different e-commerce platform interfaces, and the request information is received in combination with the message queue, so that the caller can obtain the corresponding token bucket state to efficiently connect the current limiting strategies of different e-commerce platform interfaces, that is, the developer does not need to confirm the call of the interface separately, but only needs to send the request information, and the program automatically implements the current limiting management of different e-commerce platforms according to the token bucket state, thereby providing a unified interface access method for developers, realizing unified management of requests for multiple types of e-commerce platform interfaces, reducing development difficulty, and improving data acquisition efficiency.

[0011] Furthermore, receiving the request information sent by the caller based on the message queue includes: Get the queue information sent by the caller; The message queue of the caller is subscribed to according to the queue information to receive the request information sent by the caller.

[0012] From the above description, it can be seen that by subscribing to the message queue provided by the caller according to the queue information sent by the caller, the caller does not need to wait for a response after sending a request. At the same time, the system can receive and process messages based on the request management method, thereby improving the system's concurrent processing capabilities and response speed.

[0013] Further, determining whether to delay calling the e-commerce platform interface according to the token bucket state includes: If the number of tokens in the token bucket is greater than or equal to the preset number, directly call the e-commerce platform interface; If the number of tokens in the token bucket is less than the preset number, the token recovery time is calculated, and the delay time required for the caller to obtain the token from the token bucket is determined based on the token recovery time, and the e-commerce platform interface is called based on the delay time.

[0014] From the above description, it can be seen that when the request type is an asynchronous request and the number of tokens in the token bucket is less than the preset number, it means that the caller cannot currently obtain the token. At this time, it is necessary to calculate the time when the caller can get the token next time based on the token recovery time, and call the e-commerce platform interface after the delay time to avoid invalid waiting, improve the orderliness of the e-commerce platform interface calls, and thus improve data acquisition efficiency.

[0015] Further, determining whether to call the e-commerce platform interface according to the token bucket status includes: If the number of tokens in the token bucket is greater than or equal to a preset number, calling the e-commerce platform interface; If the number of tokens in the token bucket is less than a preset number, calling the e-commerce platform interface is not allowed, and detecting whether the request information contains a target parameter; If so, the token recovery time is calculated, and the waiting time required for the caller to obtain the token from the token bucket is determined according to the token recovery time, so that the caller sends the request information again based on the waiting time.

[0016] From the above description, it can be seen that when the request type is a synchronous request and the number of tokens in the token bucket is less than the preset number, it means that the caller cannot currently obtain the token and cannot delay waiting for the call and needs to leave directly. If the request information contains a target parameter, it means that the caller requests to obtain the next available call time, that is, the caller wants the queue to reserve a token, so it is necessary to calculate the waiting time that the next caller can get based on the token recovery time, so that the caller resends the request information after the waiting time to obtain the token. In this way, repeated calls of the same request information are reduced, and message accumulation caused by the caller retrying the call based on the same request information is avoided.

[0017] Furthermore, calling the e-commerce platform interface includes: Determine a request to assemble an adapter according to the request information; Encapsulating the request information into a first call request according to the request assembly adapter; The e-commerce platform interface is called based on the first call request to obtain platform data, and the platform data is returned to the caller.

[0018] From the above description, it can be seen that since different e-commerce platform interfaces are managed based on the token bucket strategy, the calling operation of each e-commerce platform interface is also unified. The request characteristics of each e-commerce platform interface are different, so it is necessary to first determine the request assembly adapter according to the request information, and then encapsulate the request information through the corresponding request assembly adapter, so as to encapsulate the request based on the assembly method corresponding to each e-commerce platform interface to ensure the accuracy of the call.

[0019] Furthermore, after obtaining the platform data, it also includes: Check whether it is necessary to obtain the platform data after turning the page; If so, determine the page turning information of the e-commerce platform interface, and according to the request assembly adapter, encapsulate the page turning information into a second call request, and call the e-commerce platform interface based on the second call request to obtain the platform data after the page is turned; Otherwise, the platform data is returned to the caller.

[0020] From the above description, it can be seen that for some platform data, it is necessary to determine whether there are more data pages that need to be obtained. If more data pages need to be obtained, since the page turning strategy of each e-commerce platform interface is different, it is necessary to re-encapsulate a call request according to the page turning information to obtain the next page of data. In this way, it is ensured that the caller can obtain complete platform data in one call process, improve the data acquisition efficiency, and avoid the caller from repeatedly calling the e-commerce platform interface based on the same request information.

[0021] Furthermore, before calling the e-commerce platform interface based on the delay time, it also includes: Detecting whether the delay time is greater than a preset threshold; If yes, then return warning information to the caller; Otherwise, calling the e-commerce platform interface based on the delay time; Calling the e-commerce platform interface based on the delay time includes: After waiting for the delay time, the request information is re-delivered to the message queue to call the e-commerce platform interface.

[0022] From the above description, we can know that if the delay time of the request reaches the preset threshold, it means that the token bucket state is wrong or there are too many messages accumulated. At this time, the caller will be notified in time to check whether there is an unreasonable call in time and intervene in recovery in time. The delayed request information will be automatically delivered to the message queue without the need for the caller to process it, optimizing the user experience.

[0023] Furthermore, it also includes: Collecting call data of the e-commerce platform interface according to the current limiting strategy of the e-commerce platform interface; Detecting whether the current limiting strategy has changed according to the call data; If a change in the current limiting strategy is detected, the cooling time required for reconfiguring the token bucket is calculated, so as to reconfigure the token bucket of the e-commerce platform interface within the cooling time, and update the delay time according to the cooling time.

[0024] As can be seen from the above description, by collecting the call data of the e-commerce platform interface, it is analyzed whether the current limiting strategy of the e-commerce platform interface has changed, and when the change occurs, the token bucket of the e-commerce platform interface is reconfigured so that the token bucket changes synchronously with the current limiting strategy of the e-commerce platform interface to maximize the utilization rate of system resources. Since the token cannot be obtained when the token bucket is reconfigured, it is necessary to determine the cooling time required for the token bucket reconfiguration, and update the delay time according to the cooling time to avoid invalid requests.

[0025] Further, after calculating the cooling time required for the token bucket reconfiguration, the method further includes: Stop the token bucket from receiving new request tasks, and detect whether there are unfinished request tasks in the token bucket; If yes, updating the cooling time according to the end time of the requested task; Otherwise, the delay time is updated according to the cooling time.

[0026] From the above description, it can be seen that if there are unfinished request tasks in the token bucket, it is necessary to wait for the request task to end before reconfiguration can begin. During this period, the token bucket needs to be prevented from receiving new request information. Therefore, the cooling time of the token bucket needs to include the execution time of the request task to ensure that the token bucket does not receive new request information during the cooling time.

[0027] Another embodiment of the present invention provides an e-commerce platform request management terminal based on a token bucket algorithm, comprising a memory, a processor, and a computer program stored on the memory and running on the processor, wherein the processor implements each step of the above-mentioned e-commerce platform request management method based on the token bucket algorithm when executing the computer program.

[0028] As can be seen from the above description, the beneficial effects of the present invention are: receiving the request information sent by the caller through the message queue, and after determining the request type and the e-commerce platform interface according to the request information, obtaining the token bucket state configured by the current limiting strategy based on the currently requested e-commerce platform interface. When the request type is a synchronous request, it is determined whether to directly call the e-commerce platform interface according to the token bucket state. When the request type is an asynchronous request, it is determined whether to delay calling the e-commerce platform interface according to the token bucket state. In the present invention, token buckets are configured based on the current limiting strategies of different e-commerce platform interfaces, and the request information is received in combination with the message queue, so that the caller can obtain the corresponding token bucket state to efficiently connect the current limiting strategies of different e-commerce platform interfaces, that is, the developer does not need to confirm the call of the interface separately, but only needs to send the request information, and the program automatically implements the current limiting management of different e-commerce platforms according to the token bucket state, thereby providing a unified interface access method for developers, realizing unified management of requests for multiple types of e-commerce platform interfaces, reducing development difficulty, and improving data acquisition efficiency.

[0029] The e-commerce platform request management method and terminal based on the token bucket algorithm of the present invention can be applied to the request call and current limiting management of the e-commerce system, which is described below through specific implementation methods: Please refer to Figure 1 to Figure 2 , Embodiment 1 of the present invention is: The e-commerce platform request management terminal method based on the token bucket algorithm specifically includes: S1. Receive the request information sent by the caller based on the message queue.

[0030] Specifically, the step S1 includes: S11. Get the queue information sent by the caller.

[0031] S12. Subscribe to the message queue of the caller according to the queue information to receive the request information sent by the caller.

[0032] In some embodiments, the request information includes a message header and a message body. The message header includes the platform type and action type called, and the action type is used to specify which interface under the platform type. The message body includes the request address, request method, request parameters, corresponding authorization account information, and request type. The request address is the URL of the interface, and the URL is the Uniform Resource Locator, which is used to identify and locate resources on the Internet.

[0033] In some embodiments, before step S1, it also includes: creating a message queue of the current system, and sending the queue information of the message queue to the caller, so that the caller can subscribe to the message queue of the current system according to the queue information, thereby configuring the permissions of the message queue according to the subscription record of the caller, and after the caller successfully subscribes, the platform data requested by the caller can be returned to the caller based on the message queue of the current system.

[0034] In some embodiments, the message queue is specifically a RabbitMQ queue, which follows the FIFO (First In First Out) principle. It receives messages sent by producers and forwards the messages to consumers in a first-in-first-out order.

[0035] S2. Determine the request type and the e-commerce platform interface according to the request information.

[0036] In some embodiments, the e-commerce platform interface to be called is determined based on the message header in the request information, and the request type is determined based on the message body in the request message.

[0037] S3. Obtain the token bucket status configured based on the current limiting strategy of the e-commerce platform interface.

[0038] In some embodiments, if the current limiting strategy of the e-commerce platform interface is managed based on the access frequency of the API, the token bucket status can adjust the number of tokens and the token recovery rate by obtaining the access frequency of its API. If the current limiting strategy of the e-commerce platform interface is managed based on the number of concurrent requests, the token bucket status can adjust the number of tokens and the token recovery rate by obtaining the number of concurrent requests. If the current limiting strategy of the e-commerce platform interface is to allocate a request quota on a daily or monthly basis, the token bucket status can adjust the number of tokens and the token recovery rate according to the allocated quota.

[0039] S4. If the request type is a synchronous request, determine whether to call the e-commerce platform interface according to the token bucket status.

[0040] Specifically, step S4 includes: S41. If the number of tokens in the token bucket is greater than or equal to a preset number, calling the e-commerce platform interface.

[0041] S42: If the number of tokens in the token bucket is less than a preset number, calling the e-commerce platform interface is not allowed, and detecting whether the request information contains a target parameter.

[0042] In some embodiments, when the caller's request type is a synchronous request, if the number of tokens in the token bucket is insufficient and the request information does not contain a target parameter, the corresponding information will be returned directly to inform the caller that the current tokens are insufficient and the corresponding e-commerce platform interface cannot be called. The caller then decides when to initiate the call request again.

[0043] S43. If the request information contains a target parameter, the token recovery time is calculated, and the waiting time required for the caller to obtain the token from the token bucket is determined according to the token recovery time, so that the caller sends the request information again based on the waiting time.

[0044] Specifically, tokens are generated in the token bucket at a fixed rate. When a request message is received, it is checked whether there are available tokens in the token bucket of the corresponding e-commerce interface platform. If there are tokens, the request message is allowed to be processed. If there are no tokens, the request message is rejected.

[0045] S5. If the request type is an asynchronous request, determine whether to delay calling the e-commerce platform interface according to the token bucket status.

[0046] Specifically, step S5 includes: S51. If the number of tokens in the token bucket is greater than or equal to a preset number, directly call the e-commerce platform interface.

[0047] S52. If the number of tokens in the token bucket is less than a preset number, calculate the token recovery time, determine the delay time required for the caller to obtain the token from the token bucket according to the token recovery time, and call the e-commerce platform interface based on the delay time.

[0048] In some embodiments, in step S43 and step S52, the waiting time or delay time required for the caller to obtain the token from the token bucket is determined as follows: when the remaining tokens in the token bucket are equal to 0, the token bucket records two data respectively, one is the recovery time of the next token, and the other is the caller queue waiting for the token in the current token bucket. The token recovery rate is a constant speed, such as restoring one token every 2 seconds. The token recovery mechanism starts when the number of tokens is less than the capacity of the token bucket, and stops when the number of tokens is equal to the capacity of the token bucket. The caller queue waiting for the token is the caller who has applied for the token but has not obtained the token, and these callers are arranged in order of precedence. According to the token recovery time and the caller queue waiting for the token, each caller in the caller queue is calculated to wait / delay for a token, that is, the waiting time in the synchronous request or the delay time in the asynchronous request. When the synchronous request reserves the target parameter, the caller will be added to the caller queue waiting for the token, otherwise it will not participate in the calculation of the waiting time / extension time.

[0049] Specifically, before calling the e-commerce platform interface based on the delay time, the method also includes: detecting whether the delay time is greater than a preset threshold; if so, returning a warning message to the caller; otherwise, calling the e-commerce platform interface based on the delay time.

[0050] Specifically, calling the e-commerce platform interface based on the delay time includes: waiting for the delay time and then re-delivering the request information to the message queue to call the e-commerce platform interface.

[0051] Specifically, calling the e-commerce platform interface in the method includes: S6. Determine a request assembly adapter according to the request information, encapsulate the request information into a first call request according to the request assembly adapter, call the e-commerce platform interface based on the first call request to obtain platform data, and return the platform data to the caller.

[0052] In some embodiments, the e-commerce platform interface is first determined based on the platform type and action type of the request information, the corresponding request assembly adapter is determined based on the e-commerce platform interface, and then the message body (i.e., the request address, request method, request parameters and corresponding authorized account information) is assembled into an HTTP request based on the request assembly adapter.

[0053] The existing token bucket algorithm generally uses a blocking request method to obtain a token. When the caller is waiting for a token, processing a queue, or performing other synchronous operations, if the blocking time is too long or the number of blocked requests is too large, it may cause a waste of system resources and affect other normal processing. If the caller chooses to leave without waiting and then retry the request, the corresponding system is required to process the retry request. Compared with the existing token bucket current limiting management strategy, the present invention first receives request information based on a message queue. For request information that has not applied for a token, the request information will be re-delivered back to the queue according to the delay time to wait for the next wave of processing; for request information that has applied for a token, the corresponding e-commerce platform interface will be called to obtain the platform data and then returned to the caller, thereby avoiding invalid waiting and reducing the waste of system resources.

[0054] Please refer to Figure 3 , Embodiment 2 of the present invention is: The e-commerce platform request management terminal method based on the token bucket algorithm is different from the first embodiment in that after obtaining the platform data, the method further includes the following steps: S61, detecting whether the platform data after turning the page is obtained.

[0055] S62: If yes, determine the page turning information of the e-commerce platform interface, and assemble the adapter according to the request to encapsulate the page turning information into a second call request, and call the e-commerce platform interface based on the second call request to obtain the platform data after the page is turned.

[0056] S63. Otherwise, return the platform data to the caller.

[0057] Please refer to Figure 4 , Embodiment 3 of the present invention is: The e-commerce platform request management terminal method based on the token bucket algorithm is different from the embodiment 1 in that the method further includes the following steps: S101. Collect call data of the e-commerce platform interface according to the current limiting strategy of the e-commerce platform interface.

[0058] S102: Detect whether the current limiting strategy has changed according to the call data.

[0059] S103: If a change in the current limiting strategy is detected, the cooling time required for reconfiguring the token bucket is calculated to reconfigure the token bucket of the e-commerce platform interface within the cooling time, and the delay time is updated according to the cooling time.

[0060] In some embodiments, the e-commerce platform interface is managed by access frequency, and its access frequency is set according to the developer, authorized account and interface type. However, since the e-commerce platform interface does not have a specific frequency restriction description, the call data of the e-commerce platform interface can be sampled for a long time according to the three dimensions of interface type, interface type and developer, and interface type and authorized account. The total call volume and overclocked call volume of the e-commerce platform interface are analyzed according to the call data of different dimensions, so as to regularly update the token bucket configuration. Based on this, the call data of the e-commerce platform interface can be regularly analyzed, and the token bucket configuration can be updated to optimize the call frequency of the request.

[0061] In some embodiments, the token recovery rate of the token bucket is set according to a current limiting policy, so when the token recovery rate changes, a token bucket reset instruction may be generated.

[0062] In some embodiments, if it is detected that other parameters of the token bucket or too many queue request messages are accumulated, a token bucket reset instruction may also be generated.

[0063] like Figure 4As shown, in some embodiments, after receiving the token bucket reset instruction, the new configuration information of the token bucket is obtained, and the optimal cooling time required for the token bucket reconfiguration is calculated. If the token bucket is to be reset to the optimal state, that is, the token capacity is full, it is necessary to calculate the time required for the token bucket number to be restored to 0 to the maximum quota, and this time is the optimal cooling time.

[0064] After calculating the cooling time required for the token bucket reconfiguration, the method further includes: S104, stop the token bucket from receiving new request tasks, and detect whether there are unfinished request tasks in the token bucket.

[0065] S105: If yes, update the cooling time according to the end time of the requested task.

[0066] S106: Otherwise, update the delay time according to the cooling time.

[0067] After the delay time is updated according to the cooling time, the token bucket reset instruction is executed, and after the token bucket reset is completed, new request tasks are received.

[0068] Please refer to Figure 5 , Embodiment 4 of the present invention is: The e-commerce platform request management terminal 100 based on the token bucket algorithm includes a memory 101, a processor 102, and a computer program stored in the memory 101 and running on the processor 102. When the processor 102 executes the computer program, each step of the e-commerce platform request management method based on the token bucket algorithm of the above-mentioned embodiments 1 to 3 is implemented.

[0069] In summary, the present invention provides an e-commerce platform request management method and terminal based on a token bucket algorithm, which receives the caller's request information through a message queue, so that the caller's request information and the current limiting management strategy are processed asynchronously. In the case that the caller's request information cannot obtain a token, the next time a token can be applied for can be determined according to the token recovery rate configured by the current limiting strategy of the called platform interface, so that the request information is delayed for a specified time and then re-delivered to the message queue, avoiding the queue blocking problem caused by the token bucket current limiting, and reducing the repeated calls of the same request information. In addition, when the delay time reaches the threshold, the caller can be notified in time to check whether the call is unreasonable, thereby ensuring the rational use of the calling resources. In addition, since different types of current limiting strategies are configured with token buckets respectively and combined with the message queue to receive request information, the caller can obtain the corresponding token bucket status to efficiently connect to the current limiting strategies of different e-commerce platform interfaces. That is, developers do not need to confirm the call status of the interface separately, but only need to send request information. The program will automatically implement current limiting management of different e-commerce platforms according to the token bucket status, thereby providing developers with a unified interface access method, achieving unified management of requests for multiple types of e-commerce platform interfaces, reducing development difficulty, and improving data acquisition efficiency.

[0070] The above descriptions are merely embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent transformations made using the contents of the present invention's specification and drawings, or directly or indirectly applied in related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for managing e-commerce platform requests based on a token bucket algorithm, characterized in that: include: Receive request information sent by the caller based on the message queue; Determine the request type and the e-commerce platform interface according to the request information; Obtain the token bucket status based on the current limiting strategy configuration of the e-commerce platform interface; If the request type is a synchronous request, determining whether to call the e-commerce platform interface according to the token bucket status; If the request type is an asynchronous request, it is determined whether to delay calling the e-commerce platform interface according to the token bucket status.

2. The method according to claim 1, characterized in that: The request information sent by the caller is received based on the message queue, including: Get the queue information sent by the caller; The message queue of the caller is subscribed to according to the queue information to receive the request information sent by the caller.

3. The method according to claim 1, characterized in that Determining whether to delay calling the e-commerce platform interface according to the token bucket status includes: If the number of tokens in the token bucket is greater than or equal to the preset number, directly call the e-commerce platform interface; If the number of tokens in the token bucket is less than the preset number, the token recovery time is calculated, and the delay time required for the caller to obtain the token from the token bucket is determined based on the token recovery time, and the e-commerce platform interface is called based on the delay time.

4. The method according to claim 1, characterized in that: Determining whether to call the e-commerce platform interface according to the token bucket status includes: If the number of tokens in the token bucket is greater than or equal to a preset number, calling the e-commerce platform interface; If the number of tokens in the token bucket is less than a preset number, calling the e-commerce platform interface is not allowed, and detecting whether the request information contains a target parameter; If so, the token recovery time is calculated, and the waiting time required for the caller to obtain the token from the token bucket is determined according to the token recovery time, so that the caller sends the request information again based on the waiting time.

5. The method according to claim 3 or 4, characterized in that: Calling the e-commerce platform interface includes: Determine a request to assemble an adapter according to the request information; Encapsulating the request information into a first call request according to the request assembly adapter; The e-commerce platform interface is called based on the first call request to obtain platform data, and the platform data is returned to the caller.

6. The method according to claim 5, characterized in that After obtaining platform data, it also includes: Check whether to obtain the platform data after turning the page; If so, determine the page turning information of the e-commerce platform interface, and according to the request assembly adapter, encapsulate the page turning information into a second call request, and call the e-commerce platform interface based on the second call request to obtain the platform data after the page is turned; Otherwise, the platform data is returned to the caller.

7. The method according to claim 3, characterized in that Before calling the e-commerce platform interface based on the delay time, the method further includes: Detecting whether the delay time is greater than a preset threshold; If yes, then return warning information to the caller; Otherwise, calling the e-commerce platform interface based on the delay time; Calling the e-commerce platform interface based on the delay time includes: After waiting for the delay time, the request information is re-delivered to the message queue to call the e-commerce platform interface.

8. The method according to claim 3, characterized in that Also includes: Collecting call data of the e-commerce platform interface according to the current limiting strategy of the e-commerce platform interface; Detecting whether the current limiting strategy has changed according to the call data; If a change in the current limiting strategy is detected, the cooling time required for reconfiguring the token bucket is calculated, so as to reconfigure the token bucket of the e-commerce platform interface within the cooling time, and update the delay time according to the cooling time.

9. The method according to claim 8, characterized in that After calculating the cooling time required for the token bucket reconfiguration, the method further includes: Stop the token bucket from receiving new request tasks, and detect whether there are unfinished request tasks in the token bucket; If yes, updating the cooling time according to the end time of the requested task; Otherwise, the delay time is updated according to the cooling time.

10. An e-commerce platform request management terminal based on a token bucket algorithm, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, each step of the e-commerce platform request management method based on the token bucket algorithm as described in any one of claims 1 to 9 is implemented.

Images