Method, device and equipment for processing e-commerce task request and storage medium

Abstract

This application relates to the field of cloud computing technology and provides a method, apparatus, device, and storage medium for processing e-commerce task requests. It includes: obtaining a task request to be executed and the interface to be requested for the task request; dividing the task request into multiple sub-task requests; allocating a corresponding server for each sub-task request; obtaining a token pool corresponding to the interface to be requested; when a token corresponding to the first sub-task request is obtained from the token pool, triggering the server corresponding to the first sub-task request to initiate a request to the interface to be requested; and obtaining the request result of the first sub-task request. In the above scheme, the task request to be executed is divided into multiple sub-task requests. When a token is obtained, the server corresponding to each sub-task request initiates a request to the interface to be requested separately. This avoids triggering the interface's rate limiting mechanism and enables fast and accurate retrieval of requested data from the interface.

Description

Technical Field

[0001] This application belongs to the field of cloud computing technology, and in particular relates to methods, apparatus, devices and storage media for processing e-commerce task requests. Background Technology

[0002] Since the business system targets internet client users, to prevent data from exceeding the system's maximum load and crashing under sudden high concurrency, the outer Application Programming Interface (API) design needs to control data requests. Besides common methods like adding hardware configurations, several mature solutions have emerged in API design, such as rate limiting. However, precisely because of rate limiting settings for APIs, the rate limiting mechanism is easily triggered, making it impossible to quickly and accurately obtain the requested data from the API. Summary of the Invention

[0003] In view of this, embodiments of this application provide a method, apparatus, device, and storage medium for processing e-commerce task requests, in order to solve the problem in the prior art where API rate limiting settings easily trigger rate limiting mechanisms, resulting in the inability to quickly and accurately obtain the requested data from the API.

[0004] A first aspect of this application provides a method for processing e-commerce task requests, the method comprising:

[0005] Obtain the task request to be executed and the interface to be requested for the task request, the task request including e-commerce task request;

[0006] The task request is divided into multiple sub-task requests;

[0007] Assign a corresponding server to each of the subtask requests;

[0008] Obtain the token pool corresponding to the interface to be requested. The token pool stores multiple tokens, which are used to represent the permission to access the interface to be requested. The number of tokens in the token pool is set according to the rate limiting requirements of the interface to be requested.

[0009] When the token corresponding to the first subtask request is obtained from the token pool, the server corresponding to the first subtask request is triggered to send a request to the interface to be requested. The first subtask request is any one of the multiple subtask requests.

[0010] Obtain the request result of the first subtask request.

[0011] Optionally, after obtaining the token pool corresponding to the interface to be requested, the method further includes:

[0012] If the token corresponding to the first subtask request is not obtained from the token pool, wait for a first preset time period and then try to obtain the token corresponding to the first subtask request again.

[0013] Optionally, after obtaining the request result of the first subtask request, the method further includes:

[0014] When the request result is detected as a request failure, the first subtask request is divided into multiple lower-level subtask requests;

[0015] Assign a corresponding server to each of the lower-level subtask requests;

[0016] When a token corresponding to the first lower-level subtask request is obtained from the token pool, the server corresponding to the first lower-level subtask request is triggered to send a request to the interface to be requested. The first lower-level subtask request is any one of the plurality of lower-level subtask requests.

[0017] Optionally, after obtaining the request result of the first subtask request, the method further includes:

[0018] When the request result is detected as a request failure, the task request is re-divided into multiple new task requests;

[0019] Reassign a corresponding server for each of the new task requests;

[0020] When a token corresponding to the first new task request is obtained from the token pool, the server corresponding to the first new task request is triggered to send a request to the interface to be requested. The first new task request is any one of the plurality of new task requests.

[0021] Optionally, after triggering the server corresponding to the first lower-level subtask request to initiate a request to the interface to be requested when the token corresponding to the first lower-level subtask request is obtained from the token pool, the method further includes:

[0022] Obtain the request result of the first lower-level subtask request;

[0023] When the request result of the first lower-level subtask request is detected as a request failure, and the first lower-level subtask request is the smallest unit of division, a dedicated server is allocated to the first lower-level subtask request. The dedicated server is used to initiate a request to the interface to be requested based on the first lower-level subtask request.

[0024] Optionally, dividing the task request into multiple sub-task requests includes:

[0025] Obtain the time span corresponding to the task request;

[0026] Based on the time span, the task request is divided into multiple sub-task requests in units of a second preset duration.

[0027] Optionally, dividing the task request into multiple sub-task requests includes:

[0028] Obtain the amount of request data corresponding to the task request;

[0029] Based on the requested data volume, the task request is divided into multiple sub-task requests, using a preset data volume as the unit.

[0030] A second aspect of this application provides an apparatus for processing e-commerce task requests, comprising:

[0031] The first acquisition unit is used to acquire the task request to be executed and the interface to be requested for the task request, wherein the task request includes an e-commerce task request.

[0032] The first partitioning unit is used to divide the task request into multiple sub-task requests;

[0033] The first allocation unit is used to allocate a corresponding server for each of the subtask requests;

[0034] The second acquisition unit is used to acquire the token pool corresponding to the interface to be requested. The token pool stores multiple tokens, which are used to represent the permission to access the interface to be requested. The number of tokens in the token pool is set according to the rate limiting requirements of the interface to be requested.

[0035] The first triggering unit is used to trigger the server corresponding to the first subtask request to send a request to the interface to be requested when the token corresponding to the first subtask request is obtained in the token pool. The first subtask request is any one of the plurality of subtask requests.

[0036] The third acquisition unit is used to acquire the request result of the first subtask request.

[0037] A third aspect of this application provides an apparatus for processing e-commerce task requests, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, implements the steps of the method for processing e-commerce task requests as described in the first aspect above.

[0038] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method for processing e-commerce task requests as described in the first aspect above.

[0039] A fifth aspect of this application provides a computer program product that, when run on a device, causes the device to perform the steps of the method for processing e-commerce task requests described in the first aspect.

[0040] The method, apparatus, device, and storage medium for processing e-commerce task requests provided in this application have the following beneficial effects:

[0041] The above scheme involves obtaining the task request to be executed and the interface to be requested; dividing the task request into multiple sub-task requests; assigning a corresponding server to each sub-task request; obtaining the token pool corresponding to the interface to be requested; when the token corresponding to the first sub-task request is obtained from the token pool, triggering the server corresponding to the first sub-task request to send a request to the interface to be requested; and obtaining the request result of the first sub-task request. In this scheme, the task request to be executed is divided into multiple sub-task requests, and each sub-task request's corresponding server sends a separate request to the interface to be requested, thus avoiding triggering the interface's rate limiting mechanism. Furthermore, by obtaining a token for each sub-task request from the token pool corresponding to the interface to be requested, a sub-task request can only be sent to the interface to be requested when a token is obtained; otherwise, it continues to wait. This avoids the situation where multiple requests are made simultaneously, effectively solving the problem of rate limiting mechanisms being triggered due to interface request frequency limitations, and enabling fast and accurate retrieval of requested data from the interface. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 This is a schematic flowchart of a method for processing e-commerce task requests provided in an exemplary embodiment of this application;

[0044] Figure 2 This is a schematic flowchart illustrating a method for processing e-commerce task requests provided in yet another exemplary embodiment of this application;

[0045] Figure 3 This is a schematic flowchart of a method for processing e-commerce task requests provided in another exemplary embodiment of this application;

[0046] Figure 4 This is a schematic diagram of an apparatus for processing e-commerce task requests according to an embodiment of this application;

[0047] Figure 5 This is a schematic diagram of a device for processing e-commerce task requests provided in another embodiment of this application. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0049] In the description of the embodiments of this application, unless otherwise stated, " / " means "or", for example, A / B can mean A or B; "and / or" in this document 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. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0050] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0051] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0052] Foundational artificial intelligence technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning / supervised learning.

[0053] Please see Figure 1 , Figure 1This is a schematic flowchart illustrating a method for processing e-commerce task requests provided in an exemplary embodiment of this application. The execution subject of the method for processing e-commerce task requests provided in this application is a device for processing e-commerce task requests, wherein the device includes, but is not limited to, mobile terminals such as smartphones, tablets, computers, personal digital assistants (PDAs), and desktop computers, and may also include various types of servers.

[0054] For example, a server can be a standalone server or a cloud service that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0055] In this embodiment, the execution subject is a server as an example for illustration.

[0056] like Figure 1 The method for processing e-commerce task requests shown may include: S101 to S106, as detailed below:

[0057] S101: Obtain the task request to be executed, and the interface to be requested for the task request.

[0058] For example, different task requests to be executed can be set according to different business needs. When the task request to be executed is executed, the corresponding business data can be obtained. For example, the task requests to be executed may include e-commerce task requests, financial task requests, etc. For example, e-commerce task requests may include: order information requests, logistics information requests, fund settlement data requests, etc.

[0059] For example, different task requests to be executed correspond to different pending request interfaces. Based on the current task request to be executed, the corresponding pending request interface is obtained. For instance, when the task request is to retrieve order information for a month's worth of sales, the corresponding pending request interface is the order interface; when the task request is to retrieve logistics information for fifteen days' worth of sales, the corresponding pending request interface is the logistics interface.

[0060] For example, let's take a cross-border e-commerce platform as an example. A user sells goods on a cross-border e-commerce platform, and the money earned from the sales is deposited into a bank card overseas. If the user wants to transfer the money from the overseas bank card to a bank card in China, regulatory authorities (such as customs) will verify whether the source of the funds is legal. Therefore, the user needs to provide relevant trade details to the regulatory authorities.

[0061] A domestic payment company that provides cross-border trade cash withdrawal services primarily serves these types of users. Based on their needs, it provides regulatory authorities with detailed trade information of users over a certain period of time. This trade information may include specific order information for the sold goods, logistics information, and platform fund settlement data.

[0062] Different task requests can be set up to meet different business needs. For example, to retrieve specific order information for goods sold within a certain time period, a "Retrieve Order Information" request can be set up; to retrieve logistics information for goods sold within a certain time period, a "Retrieve Logistics Information" request can be set up; and to retrieve financial settlement data for goods sold within a certain time period, a "Retrieve Financial Settlement Data" request can be set up. This is merely an example and is not intended to be limiting.

[0063] Cross-border e-commerce platforms provide various Application Programming Interfaces (APIs). For example, APIs may include order APIs, logistics APIs, and payment APIs. When a request for order information is sent to the order API, specific order information for goods sold within a certain time period can be obtained; when a request for logistics information is sent to the logistics API, logistics information for goods sold within a certain time period can be obtained; when a request for payment settlement data is sent to the payment API, payment settlement data for goods sold within a certain time period can be obtained. This is merely an illustrative example and is not intended to be limiting.

[0064] Optionally, one or more pre-set, different task requests to be executed can be stored in a database. When a trigger condition is met, the task request to be executed is retrieved from the database, and then step S102 is executed. The trigger condition can be set according to different business needs; for example, the trigger condition can be to execute a certain task request once a month, or once every fifteen days, etc.

[0065] Alternatively, one or more pre-defined pending task requests can be stored in a database. When a trigger condition is met, the pending task requests are retrieved from the database and placed into a pending task queue (e.g., a Redis task queue). The server then retrieves the pending task requests from the task queue. This is merely an illustrative example and is not intended to be limiting.

[0066] S102: Divide the task request into multiple sub-task requests.

[0067] For example, a complete task request is divided into multiple sub-task requests, and the data obtained by each sub-task request is the same as the data obtained by the task request alone. In other words, the data obtained by each sub-task request constitutes the data obtained by the task request to be executed alone.

[0068] For example, a task request can be divided into multiple sub-task requests based on time. Another example is dividing a task request into multiple sub-task requests based on data volume. The choice should be made based on the actual situation; there are no restrictions.

[0069] Optionally, in some possible implementations of this application, the above-mentioned S102 may include S1021-S1022 or S1023-S1024, wherein S1021-S1022 and S1023-S1024 are performed concurrently, and S1023-S1024 are not executed after S1021-S1022, as detailed below:

[0070] S1021: Get the time span corresponding to the task request.

[0071] For example, when the time span corresponding to the requested data is clearly specified in the task request to be executed, the task request is divided into multiple sub-task requests based on time. The time span refers to the time period corresponding to the data that the task request needs to request.

[0072] For example, a task request might be to retrieve order information for goods sold over a month, where one month represents the time span of the request. Another example is a task request to retrieve logistics information for goods sold over fifteen days, where fifteen days represents the time span. These are merely illustrative examples and are not intended to be limiting.

[0073] S1022: Based on the time span, the task request is divided into multiple sub-task requests in units of the second preset duration.

[0074] For example, the second preset duration can be set according to the rate limiting requirements of the interface to be requested. Different interfaces to be requested may have different rate limiting requirements, therefore, the second preset duration can be adjusted at any time. For example, the second preset duration can be five days, ten days, fifteen days, etc., which is only an example and is not limited thereto.

[0075] The time span is divided using the second preset duration as a unit, thereby realizing the division of task requests.

[0076] For example, if the task request is to retrieve order information for a month's worth of goods sold, and the second preset duration is fifteen days, this task request can be divided into two sub-task requests: one for retrieving order information for the first half of the month, and the other for retrieving order information for the second half of the month.

[0077] For example, if the task request is to obtain the logistics information of goods sold over 15 days, and the second preset duration is five days, this task request can be divided into three sub-task requests. The sub-task requests are to obtain the logistics information of goods sold from day 1 to day 5, the logistics information of goods sold from day 6 to day 10, and the logistics information of goods sold from day 11 to day 15.

[0078] Optionally, the time span of the task request can be divided unevenly. For example, if the task request is to retrieve order information for a month's worth of goods sold, with a second preset duration of ten and twenty days, the task request can be divided into two sub-task requests. The sub-task requests are to retrieve order information for goods sold from day one to day ten, and to retrieve order information for goods sold from day eleven to day thirty.

[0079] These are all illustrative examples and are not intended to be limiting.

[0080] Optionally, when there are multiple task requests, each task request can be divided in the above manner to obtain multiple sub-task requests corresponding to each task request.

[0081] In this embodiment, a complete task request is divided into multiple sub-task requests based on time. Each subsequent sub-task request requests data from the interface to be requested separately, thereby achieving load balancing of the request platform API, maximizing the use of existing network bandwidth and server memory performance, and ensuring efficient acquisition of requested data.

[0082] For example, directly requesting data from the interface to be requested through the task to be executed might result in excessively large returned data, data download timeouts, and ultimately, data retrieval failure. Furthermore, with the daily updated data constantly increasing, this puts excessive pressure on the server. However, dividing the task to be executed into multiple sub-task requests, with each sub-task requesting data from the interface to be requested separately, can avoid the above problems, shorten request time, and thus obtain the requested data quickly and accurately.

[0083] S1023: Get the amount of request data corresponding to the task request.

[0084] For example, when the amount of data requested is explicitly specified in the task request to be executed, the task request is divided into multiple sub-task requests based on the amount of data requested. The amount of data refers to the size of the data that the task request needs to request.

[0085] For example, a task request might be to retrieve X megabytes of business data, where X megabytes is the requested data volume. Another example is a task request to retrieve Y megabytes of business data, where Y megabytes is the requested data volume. These are merely illustrative examples and are not intended to be limiting. Both X and Y are numerical values.

[0086] S1024: Based on the amount of requested data, divide the task request into multiple sub-task requests using a preset data amount as the unit.

[0087] For example, the preset data volume can be set according to the rate limiting requirements of the interface to be requested. Different interfaces to be requested may have different rate limiting requirements, therefore, the preset data volume can be adjusted at any time. For example, the preset data volume can be x megabytes, y megabytes, etc., which is only an example and is not limited thereto.

[0088] The requested data volume is divided into units based on a preset data volume, thereby enabling the division of task requests.

[0089] For example, if a task request is to retrieve 500 MB of business data, with a preset data volume of 250 MB, this task request can be divided into two sub-task requests. Each sub-task request retrieves 250 MB of business data.

[0090] Optionally, the requested data volume of a task request can be divided unevenly. For example, if a task request is to retrieve 500 MB of business data, with preset data volumes of 200 MB and 300 MB, the task request can be divided into two sub-task requests: one to retrieve 200 MB of business data and the other to retrieve 300 MB of business data.

[0091] These are all illustrative examples and are not intended to be limiting.

[0092] Optionally, when there are multiple task requests, each task request can be divided in the above manner to obtain multiple sub-task requests corresponding to each task request.

[0093] In this embodiment, a complete task request is divided into multiple sub-task requests based on the amount of data. Each sub-task request then requests data from the interface to be requested separately, thereby achieving load balancing of the request platform API, maximizing the use of existing network bandwidth and server memory performance, and ensuring efficient acquisition of requested data.

[0094] For example, directly requesting data from the interface through the pending task request might result in excessively large returned data, data download timeouts, and ultimately data retrieval failure. Furthermore, with the daily data updates constantly increasing, this puts excessive pressure on the server. However, by explicitly dividing the pending task request into multiple sub-task requests based on the data volume, the amount of data retrieved for each sub-task request can be determined, avoiding the aforementioned problems, shortening request time, and thus quickly and accurately obtaining the complete requested data.

[0095] S103: Assign a corresponding server for each subtask request.

[0096] For example, each subtask request can be randomly assigned to a corresponding server, or each subtask request can be assigned a corresponding server sequentially according to a preset assignment order. This server is used to initiate requests to the interface to be requested.

[0097] For example, if a task request is to retrieve order information for a month's worth of goods sold, this task request can be divided into two sub-task requests: one for retrieving order information for the first half of the month and the other for retrieving order information for the second half of the month. A pre-defined task dispatcher can randomly assign a server to each of these two sub-task requests, or the servers can be assigned sequentially according to a pre-defined allocation order.

[0098] S104: Obtain the token pool corresponding to the interface to be requested. The token pool stores multiple tokens, which are used to represent the permission to access the interface to be requested. The number of tokens in the token pool is set according to the rate limiting requirements of the interface to be requested.

[0099] For example, each interface to be requested has a corresponding token pool, which pre-stores multiple tokens. Each token serves as a credential representing permission to access the interface to be requested. This can be understood as follows: only when any token from the token pool is obtained is one authorized to access the interface to be requested, or in other words, one is qualified to make a request to the interface; if no token is obtained from the token pool, one is not authorized to access the interface to be requested, or in other words, one is not qualified to make a request to the interface.

[0100] Each pending API has different rate limiting requirements, and the number of tokens in the token pool is set according to the rate limiting requirements of that API. Rate limiting requirements are used to limit the frequency and volume of requests to each pending API.

[0101] For example, cross-border e-commerce platforms set different rate limiting requirements for different users' stores. One rate limiting requirement might be that the requested interface is requested N times per second. Based on these rate limiting requirements, the number of tokens in the token pool for the requested interface, as well as the token replenishment rate, are set. That is, once all tokens in the token pool are obtained, it is replenished at a constant, pre-defined rate.

[0102] For example, the token bucket algorithm can be used to record the number of times each store's pending API calls are made in the task queue over a period of time, and the number of tokens that can be requested can be restored at a certain frequency, with the restoration speed of the tokens subject to rate limiting requirements (e.g., the documentation provided by the cross-border e-commerce platform).

[0103] S105: When the token corresponding to the first subtask request is obtained from the token pool, the server corresponding to the first subtask request is triggered to send a request to the interface to be requested. The first subtask request can be any one of multiple subtask requests.

[0104] For example, the token corresponding to the first subtask request is obtained from the token pool, where the first subtask request is any one of multiple subtask requests. The token can be obtained for each subtask request in the order it was divided into subtask requests, or it can be obtained randomly for each subtask request, ensuring that each subtask request ultimately has its corresponding token.

[0105] When the token corresponding to the first subtask request is obtained from the token pool, the server corresponding to that first subtask request can be triggered to send a request to the interface to be requested. That is, the server corresponding to the first subtask request sends the first subtask request to the interface to be requested.

[0106] For example, each pending interface will trigger a rate limiting mechanism according to its different rate limiting requirements. This can be understood as the server failing when the frequency of requests to the pending interface exceeds the value in the rate limiting requirements, or when the amount of data requested to the pending interface exceeds the amount of data in the rate limiting requirements. The pending interface will not be able to respond to each request normally.

[0107] Therefore, in order to avoid triggering the rate limiting mechanism and ensure that the interface to be requested can continuously and normally respond to each request, a complete task request to be executed is first divided into multiple sub-task requests. Then, before each sub-task request formally requests the interface to be requested, it needs to obtain a token from the token pool and use the token as a credential to send a request to the interface to be requested through its corresponding server.

[0108] For example, when there are multiple subtask requests, each subtask request can obtain a token from the token pool in turn.

[0109] For example, since the number of tokens in the token pool is limited and the tokens in the token pool have a certain refresh frequency, when obtaining the token corresponding to the subtask request, some subtask requests have the corresponding token, while others do not.

[0110] For example, the sub-task requests are requests to obtain logistics information for goods sold from day 1 to day 5, requests to obtain logistics information for goods sold from day 6 to day 10, and requests to obtain logistics information for goods sold from day 11 to day 15. The tokens corresponding to these three sub-task requests are obtained, resulting in one token for each of the first, second, and third sub-task requests.

[0111] When a token corresponding to a subtask request is obtained, the server corresponding to that subtask request initiates a request to the interface to be requested. For example, if the first subtask request has a corresponding token, the server corresponding to that subtask request will initiate a request to the logistics API to obtain the logistics information of the goods sold from day one to day five. If the second subtask request has a corresponding token, the server corresponding to that subtask request will initiate a request to the logistics API to obtain the logistics information of the goods sold from day six to day ten. If the third subtask request has a corresponding token, the server corresponding to that subtask request will initiate a request to the logistics API to obtain the logistics information of the goods sold from day eleven to day fifteen. This is merely an illustrative example and is not intended to be limiting.

[0112] Optionally, in some possible implementations of this application, the following may be included after S104:

[0113] If the token corresponding to the first subtask request is not obtained from the token pool, wait for the first preset time period and then try to obtain the token corresponding to the first subtask request again.

[0114] For example, since the number of tokens in the token pool is limited and the tokens in the token pool have a certain refresh frequency, when obtaining the token corresponding to the subtask request, some subtask requests have the corresponding token, while others do not.

[0115] If all the tokens in the token pool are currently available, the subtask request will not have a corresponding token. In this case, it can wait for the first preset duration before trying to acquire a token again. It is worth noting that the first preset duration is different from the second preset duration; the first preset duration matches the frequency at which the tokens in the token pool are refreshed.

[0116] For example, the sub-task requests are requests to obtain logistics information for goods sold from day 1 to day 5, requests to obtain logistics information for goods sold from day 6 to day 10, and requests to obtain logistics information for goods sold from day 11 to day 15. The tokens corresponding to these three sub-task requests are retrieved. The results show that the first and second sub-task requests have corresponding tokens, while the third sub-task request does not have a corresponding token.

[0117] After waiting for the first preset time, a token is retrieved from the token pool for the same subtask request again. For example, if the third subtask request does not have a corresponding token, after waiting for the first preset time, the token for the third subtask request is retrieved from the token pool again. After obtaining the token for the third subtask request, the server corresponding to that subtask request initiates a request to the logistics API to retrieve the logistics information of the sold goods from day 11 to day 15. This is only an illustrative example and is not intended to be limiting.

[0118] In the above embodiments, a token is obtained for each subtask request from the token pool corresponding to the interface to be requested. Only when a token is obtained is a subtask request initiated to the interface to be requested; otherwise, it continues to wait. This avoids the situation where multiple requests are made simultaneously, effectively solving the problem of rate limiting mechanisms being triggered due to interface request frequency limits. Furthermore, the requirement of a token to initiate a request further ensures the security of the request.

[0119] S106: Obtain the request result of the first subtask request.

[0120] For example, the request result for each first subtask request is obtained. The request result can include request success or request failure. Request success means that if the interface to be requested responds to a certain subtask request, it returns the data corresponding to that subtask request; request failure means that the interface to be requested does not respond to a certain subtask request, for example, it does not return any data, or it indicates that the request failed, etc.

[0121] When the subtask request results in a successful request, the returned data will be stored in the specified database.

[0122] In the above solution, the task request to be executed is divided into multiple sub-task requests. Each sub-task request's corresponding server sends a separate request to the interface to be requested, thus avoiding triggering the interface's rate limiting mechanism. Furthermore, a token is obtained for each sub-task request from the token pool corresponding to the interface to be requested. Only when a token is obtained can the sub-task request be sent to the interface to be requested; otherwise, it continues to wait. This avoids multiple requests simultaneously, effectively solving the problem of rate limiting mechanisms being triggered due to interface request frequency limitations, and enabling fast and accurate retrieval of requested data from the interface.

[0123] Please see Figure 2 , Figure 2 This is a schematic flowchart illustrating a method for processing e-commerce task requests provided in another exemplary embodiment of this application. This embodiment and... Figure 1 The difference in the corresponding embodiment is that after S206, it also includes S207 to S209. In this embodiment, S201 to S206 are the same as... Figure 1 S101 to S106 in the corresponding embodiments are exactly the same. Please refer to the relevant description of S101 to S106 in the previous embodiment for details, which will not be repeated here. S207 to S209 are as follows:

[0124] S207: When a request is detected to have failed, the first subtask request is divided into multiple lower-level subtask requests.

[0125] When the result of a first subtask request is found to be a failure, that first subtask request is divided into multiple lower-level subtask requests. The division method is similar to the division method for the task requests to be executed; it can be divided by time or by data volume, without limitation.

[0126] For example, a first subtask request might be to retrieve order information for goods sold in the first half of the month, with a preset duration of five days. This first subtask request is then divided into three lower-level subtask requests: requests to retrieve order information for goods sold from day one to day five, requests to retrieve order information for goods sold from day six to day ten, and requests to retrieve order information for goods sold from day eleven to day fifteen.

[0127] S208: Assign a corresponding server for each subordinate subtask request.

[0128] For example, each subordinate subtask request can be randomly assigned to a corresponding server, or each subordinate subtask request can be assigned a corresponding server sequentially according to a preset assignment order. This server is used to initiate requests to the interface to be requested.

[0129] Alternatively, the server corresponding to the first subtask request can still be used as the server corresponding to each subsequent subtask request.

[0130] S209: When the token corresponding to the first subordinate subtask request is obtained from the token pool, the server corresponding to the first subordinate subtask request is triggered to send a request to the interface to be requested. The first subordinate subtask request can be any one of multiple subordinate subtask requests.

[0131] For example, the token corresponding to each first sub-task request is obtained from the token pool, where the first sub-task request is any one of multiple sub-task requests. The token can be obtained for each sub-task request in the order it was divided, or it can be obtained randomly, ensuring that each sub-task request ultimately has its corresponding token.

[0132] When the token corresponding to the first sub-task request is obtained from the token pool, the server corresponding to that first sub-task request can be triggered to initiate a request to the interface to be requested. That is, the server corresponding to the first sub-task request initiates the first sub-task request to the interface to be requested.

[0133] Because the number of tokens in the token pool is limited and the tokens in the token pool have a certain refresh frequency, when obtaining the token corresponding to the request of a subordinate subtask, some subordinate subtask requests have the corresponding token, while others do not.

[0134] If all tokens in the token pool are currently available, subsequent subtask requests will not have corresponding tokens. In this case, you can wait for the first preset duration before trying to acquire a token again. Please refer to the description in S105; it will not be repeated here.

[0135] In the above embodiments, if the initial sub-task requests are unreasonable, the sub-task requests can be divided again to ensure that complete request data can be obtained.

[0136] Optionally, in some possible implementations of this application, the following may be included after S209:

[0137] S210: Obtain the request result of the first subordinate subtask request.

[0138] For example, the request result for each first-level subtask request is obtained. The request result can include whether the request was successful or failed. A successful request means that if the interface to be requested responds to a subtask request, it returns the data corresponding to that subtask request; a failed request means that the interface to be requested does not respond to a subtask request, for example, it does not return any data, or it indicates that the request failed.

[0139] When the request result of the next subtask is successful, the returned data will be stored in the specified database.

[0140] S211: When the request result of the first lower-level subtask request is detected as a request failure, and the first lower-level subtask request is the smallest unit of division, a dedicated server is assigned to the first lower-level subtask request. The dedicated server is used to initiate a request to the interface to be requested based on the first lower-level subtask request.

[0141] For example, the smallest unit of division refers to the smallest unit set by the second preset duration, or the smallest unit set by the preset data volume. For example, the second preset duration is one day, the preset data volume is 50 MB, etc.

[0142] If the division is continuously refined, it will result in too many task requests, which is detrimental to obtaining business data. Therefore, a minimum division unit is preset. The minimum division unit can be adjusted according to the actual situation, and there is no limitation on it.

[0143] When the result of a request for a first-level subtask is found to be a request failure, and the first-level subtask request is detected as the smallest unit of division, a dedicated server is assigned to the first-level subtask request.

[0144] For example, if a first-level subtask request, which represents the smallest unit of division, still times out, a dedicated long-running thread pool can be used. A dedicated server can then initiate a request to the interface based on this first-level subtask request. This request can be understood as an asynchronous request. The returned data from the asynchronous request is automatically downloaded to a specified text file. Once the download is complete, a notification is generated to remind staff to process the request in the system. This is merely an illustrative example and is not intended to be limiting.

[0145] In the above implementation, a dedicated server is allocated to special lower-level subtask requests to ensure that each request can be responded to and to guarantee the integrity of the final request data.

[0146] Please see Figure 3 , Figure 3 This is a schematic flowchart illustrating a method for processing e-commerce task requests provided in another exemplary embodiment of this application. This embodiment and... Figure 1 The difference in the corresponding embodiment is that after S306, it also includes S307 to S309. In this embodiment, S301 to S306 are the same as... Figure 1 S101 to S106 in the corresponding embodiments are exactly the same. Please refer to the relevant description of S101 to S106 in the previous embodiment for details, which will not be repeated here. S307 to S309 are as follows:

[0147] S307: When a request is detected to have failed, the task request will be reclassified into multiple new task requests.

[0148] When the result of a first subtask request is a failure, the original pending task requests are re-divided into multiple new task requests. The division method is similar to the division of the pending task requests; it can be based on time or data volume. It is worth noting that the second preset duration or preset data volume should be appropriately reduced.

[0149] For example, if the initial preset duration is fifteen days, it can be adjusted to ten days, five days, etc., during subsequent divisions. Based on the time span corresponding to the task request to be executed, the task request is divided into multiple new task requests using the adjusted second preset duration as the unit.

[0150] For example, if the initial data size is set at 200 MB, subsequent partitions can adjust the preset data size to 150 MB, 100 MB, etc. Based on the request data size corresponding to the task request to be executed, the task request is divided into multiple new task requests using the adjusted preset data size as the unit.

[0151] S308: Reassign the corresponding server for each new task request.

[0152] For example, each new task request can be randomly reassigned to a corresponding server, or each new task request can be assigned a server sequentially according to a preset allocation order. This server is used to initiate a request to the interface to be requested.

[0153] S309: When the token corresponding to the first new task request is obtained from the token pool, the server corresponding to the first new task request is triggered to send a request to the interface to be requested. The first new task request can be any one of multiple new task requests.

[0154] For example, a token corresponding to each first new task request is obtained from the token pool, where the first new task request is any one of multiple new task requests. The token can be obtained for each new task request in the order it was divided, or it can be obtained randomly for each new task request, ensuring that each new task request ultimately has its corresponding token.

[0155] When a token corresponding to the first new task request is obtained from the token pool, the server corresponding to that first new task request can be triggered to initiate a request to the interface to be requested. In other words, the server corresponding to the first new task request initiates the first new task request to the interface to be requested.

[0156] Because the number of tokens in the token pool is limited and the tokens in the token pool have a certain refresh frequency, when obtaining the token corresponding to a new task request, some new task requests have the corresponding token, while others do not.

[0157] If all tokens in the token pool are currently available, new task requests will not have corresponding tokens. In this case, you can wait for the first preset time period before trying to obtain a token again. Please refer to the description in S105, which will not be repeated here.

[0158] In this implementation, the original pending task requests are re-divided in a more reasonable way to ensure load balancing of the request platform API, maximize the use of existing network bandwidth and server memory performance, and ensure efficient acquisition of request data.

[0159] Optionally, in one possible implementation, the method for processing e-commerce task requests provided in this application can also be applied to the medical field. For example, when it is necessary to obtain medical data from a certain interface, the above-mentioned method for processing e-commerce task requests can be used to avoid requesting too much medical data at once, which could lead to request timeout.

[0160] Please see Figure 4 , Figure 4 This is a schematic diagram of an apparatus for processing e-commerce task requests according to an embodiment of this application. The apparatus 4 includes units for performing... Figures 1-3 The steps in the corresponding embodiments. Please refer to the details. Figures 1-3 The relevant descriptions in their respective embodiments are shown below. For ease of explanation, only the parts relevant to this embodiment are shown. See also... Figure 4 ,include:

[0161] The first acquisition unit 410 is used to acquire a task request to be executed and a request interface of the task request, wherein the task request includes an e-commerce task request.

[0162] The first partitioning unit 420 is used to divide the task request into multiple sub-task requests;

[0163] The first allocation unit 430 is used to allocate a corresponding server for each of the subtask requests;

[0164] The second acquisition unit 440 is used to acquire the token pool corresponding to the interface to be requested. The token pool stores multiple tokens, which are used to represent the permission to access the interface to be requested. The number of tokens in the token pool is set according to the rate limiting requirements of the interface to be requested.

[0165] The first triggering unit 450 is used to trigger the server corresponding to the first subtask request to send a request to the interface to be requested when the token corresponding to the first subtask request is obtained in the token pool. The first subtask request is any one of the plurality of subtask requests.

[0166] The third acquisition unit 460 is used to acquire the request result of the first subtask request.

[0167] Optionally, the device further includes:

[0168] The fourth acquisition unit is used to wait for a first preset time period and then acquire the token corresponding to the first subtask request again when the token corresponding to the first subtask request is not acquired in the token pool.

[0169] Optionally, the device further includes:

[0170] The second division unit is used to divide the first subtask request into multiple lower-level subtask requests when the request result is detected as a request failure.

[0171] The second allocation unit is used to allocate a corresponding server for each of the lower-level subtask requests;

[0172] The second triggering unit is used to trigger the server corresponding to the first lower-level subtask request to send a request to the interface to be requested when the token corresponding to the first lower-level subtask request is obtained from the token pool. The first lower-level subtask request is any one of the plurality of lower-level subtask requests.

[0173] Optionally, the device further includes:

[0174] The third division unit is used to re-divide the task request into multiple new task requests when the request result is detected as a request failure.

[0175] The third allocation unit is used to reallocate a corresponding server for each new task request;

[0176] The third triggering unit is used to trigger the server corresponding to the first new task request to send a request to the interface to be requested when the token corresponding to the first new task request is obtained from the token pool. The first new task request is any one of the plurality of new task requests.

[0177] Optionally, the device further includes:

[0178] The fifth acquisition unit is used to acquire the request result of the first lower-level subtask request;

[0179] The fourth allocation unit is used to allocate a dedicated server to the first lower-level subtask request when the request result of the first lower-level subtask request is detected as a request failure and the first lower-level subtask request is the smallest unit of division. The dedicated server is used to initiate a request to the interface to be requested based on the first lower-level subtask request.

[0180] Optionally, the first partitioning unit 420 is specifically used for:

[0181] Obtain the time span corresponding to the task request;

[0182] Based on the time span, the task request is divided into multiple sub-task requests in units of a second preset duration.

[0183] Optionally, the first partitioning unit 420 is further configured to:

[0184] Obtain the amount of request data corresponding to the task request;

[0185] Based on the requested data volume, the task request is divided into multiple sub-task requests, using a preset data volume as the unit.

[0186] Please see Figure 5 , Figure 5 This is a schematic diagram of a device for processing e-commerce task requests according to another embodiment of this application. Figure 5 As shown, the device 5 in this embodiment includes: a processor 50, a memory 51, and a computer program 52 stored in the memory 51 and executable on the processor 50. When the processor 50 executes the computer program 52, it implements the steps in the various method embodiments for processing e-commerce task requests described above, for example... Figure 1 S101 to S106 are shown. Alternatively, when the processor 50 executes the computer program 52, it implements the functions of each unit in the above embodiments, for example... Figure 4 The functions of units 410 to 460 are shown.

[0187] Exemplarily, the computer program 52 can be divided into one or more units, which are stored in the memory 51 and executed by the processor 50 to complete this application. The one or more units can be a series of computer instruction segments capable of performing specific functions, which describe the execution process of the computer program 52 in the device 5. For example, the computer program 52 can be divided into a first acquisition unit, a first partitioning unit, a first allocation unit, a second acquisition unit, a first triggering unit, and a third acquisition unit, with the specific functions of each unit as described above.

[0188] The device may include, but is not limited to, a processor 50 and a memory 51. Those skilled in the art will understand that... Figure 5 This is merely an example of device 5 and does not constitute a limitation on the device. It may include more or fewer components than shown, or combine certain components, or different components. For example, the device may also include input / output devices, network access devices, buses, etc.

[0189] The processor 50 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0190] The memory 51 can be an internal storage unit of the device, such as a hard drive or RAM. The memory 51 can also be an external storage terminal of the device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 51 can include both internal and external storage units. The memory 51 is used to store computer instructions and other programs and data required by the terminal. The memory 51 can also be used to temporarily store data that has been output or will be output.

[0191] This application also provides a computer storage medium, which can be non-volatile or volatile, storing a computer program that, when executed by a processor, implements the steps in the above-described methods for processing e-commerce task requests.

[0192] This application also provides a computer program product that, when run on a device, causes the device to perform the steps in the above-described method embodiments for processing e-commerce task requests.

[0193] This application also provides a chip or integrated circuit, which includes a processor for calling and running a computer program from a memory, causing a device equipped with the chip or integrated circuit to perform the steps in the above-described method embodiments for processing e-commerce task requests.

[0194] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0195] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0196] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0197] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for processing an e-commerce task request, characterized in that, include: Obtain the task request to be executed and the interface to be requested for the task request, the task request including e-commerce task request; The e-commerce task requests include order information requests, logistics information requests, and fund settlement data requests; Dividing the task request into multiple sub-task requests includes: obtaining the time span corresponding to the task request; and dividing the task request into multiple sub-task requests based on the time span, using a second preset duration as a unit. Assign a corresponding server to each of the subtask requests; Obtain the token pool corresponding to the interface to be requested. The token pool stores multiple tokens, which are used to represent the permission to access the interface to be requested. The number of tokens in the token pool is set according to the rate limiting requirements of the interface to be requested. When the token corresponding to the first subtask request is obtained from the token pool, the server corresponding to the first subtask request is triggered to send a request to the interface to be requested. The first subtask request is any one of the multiple subtask requests. Obtain the request result of the first subtask request; When the request result is detected as a request failure, the first subtask request is divided into multiple lower-level subtask requests; Assign a corresponding server to each of the lower-level subtask requests; When a token corresponding to the first lower-level subtask request is obtained from the token pool, the server corresponding to the first lower-level subtask request is triggered to send a request to the interface to be requested. The first lower-level subtask request is any one of the plurality of lower-level subtask requests. Obtain the request result of the first lower-level subtask request; When the request result of the first lower-level subtask request is detected as a request failure, and the first lower-level subtask request is the smallest unit of division, a dedicated server is allocated to the first lower-level subtask request. The dedicated server is used to initiate a request to the interface to be requested based on the first lower-level subtask request.

2. The method of claim 1, wherein, After obtaining the token pool corresponding to the interface to be requested, the method further includes: If the token corresponding to the first subtask request is not obtained from the token pool, wait for a first preset time period and then try to obtain the token corresponding to the first subtask request again.

3. The method of claim 1, wherein, After obtaining the request result of the first subtask request, the method further includes: When the request result is detected as a request failure, the task request is re-divided into multiple new task requests; Reassign a corresponding server for each of the new task requests; When a token corresponding to the first new task request is obtained from the token pool, the server corresponding to the first new task request is triggered to send a request to the interface to be requested. The first new task request is any one of the plurality of new task requests.

4. The method according to any one of claims 1 to 3, characterized in that, The step of dividing the task request into multiple sub-task requests includes: Obtain the amount of request data corresponding to the task request; Based on the requested data volume, the task request is divided into multiple sub-task requests, using a preset data volume as the unit.

5. An apparatus for processing an e-commerce task request, the apparatus comprising: include: The first acquisition unit is used to acquire the task request to be executed and the interface to be requested for the task request, wherein the task request includes an e-commerce task request. The e-commerce task requests include order information requests, logistics information requests, and fund settlement data requests; The first division unit is used to divide the task request into multiple sub-task requests, including: obtaining the time span corresponding to the task request; and dividing the task request into multiple sub-task requests based on the time span, using a second preset duration as the unit. The first allocation unit is used to allocate a corresponding server for each of the subtask requests; The second acquisition unit is used to acquire the token pool corresponding to the interface to be requested. The token pool stores multiple tokens, which are used to represent the permission to access the interface to be requested. The number of tokens in the token pool is set according to the rate limiting requirements of the interface to be requested. The first triggering unit is used to trigger the server corresponding to the first subtask request to send a request to the interface to be requested when the token corresponding to the first subtask request is obtained in the token pool. The first subtask request is any one of the plurality of subtask requests. The third acquisition unit is used to acquire the request result of the first subtask request; The device further includes: The second division unit is used to divide the first subtask request into multiple lower-level subtask requests when the request result is detected as a request failure. The second allocation unit is used to allocate a corresponding server for each of the lower-level subtask requests; The second triggering unit is used to trigger the server corresponding to the first lower-level subtask request to send a request to the interface to be requested when the token corresponding to the first lower-level subtask request is obtained in the token pool. The first lower-level subtask request is any one of the plurality of lower-level subtask requests. The fifth acquisition unit is used to acquire the request result of the first lower-level subtask request; The fourth allocation unit is used to allocate a dedicated server to the first lower-level subtask request when the request result of the first lower-level subtask request is detected as a request failure and the first lower-level subtask request is the smallest unit of division. The dedicated server is used to initiate a request to the interface to be requested based on the first lower-level subtask request.

6. An apparatus for processing an e-commerce task request, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 4.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 4.

Images