A method and device for processing business requests

Abstract

The present invention discloses a method and apparatus for processing business requests, relating to the field of computer technology. A specific implementation of the method includes: obtaining at least one business request; generating at least one first task corresponding to each of the at least one business request, and storing the at least one first task in a distributed cache queue using at least one first thread; extracting the first task from the distributed cache queue using at least one second thread, and executing the extracted first task; and outputting the execution result of the first task. This implementation avoids the risk of cache breakdown under high concurrency requests, thereby improving system stability.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and device for processing a service request. Background Art

[0002] With the continuous increase in Internet users, how to alleviate the system pressure on the business platform caused by high-concurrency requests from multiple users has become the focus of ensuring system stability.

[0003] At present, cache is generally introduced to support high-concurrency requests from multiple users: when a user's business request is received, if the business data requested by the user does not exist in the cache, the corresponding business method is executed to request the business data from the underlying storage device, and the result data is stored in the cache. When a business request for the business data is received next time, the business data can be returned directly from the cache.

[0004] In the process of implementing the present invention, the inventors discovered that the prior art has at least the following problems:

[0005] When the cache does not contain the business data corresponding to the business request, the underlying storage device is directly accessed according to the business request. Under high concurrency requests, the cache is easily broken down, causing a large number of business requests to directly act on the underlying storage device, thereby reducing system stability. Summary of the Invention

[0006] In view of this, an embodiment of the present invention provides a business request processing method and device, which can generate a first task corresponding to a business request, and use a first thread to store the first task in a distributed cache queue, and then use a second thread to extract and execute the first task from the distributed cache queue to respond to the business request. This achieves asynchronous concurrent storage and execution of the first task corresponding to the business request, so that the number of concurrent requests can be controlled by controlling the number of concurrent second threads. In other words, the maximum number of first tasks that can be controlled to be executed simultaneously is the number of concurrently executed second threads, thereby avoiding the risk of cache breakdown under high concurrent requests and improving system stability.

[0007] To achieve the above objective, according to one aspect of an embodiment of the present invention, a service request processing method is provided.

[0008] A service request processing method according to an embodiment of the present invention includes: obtaining at least one service request;

[0009] Generating at least one first task corresponding to the at least one business request respectively, and storing the at least one first task in a distributed cache queue by using at least one first thread;

[0010] extracting the first task from the distributed cache queue using at least one second thread, and executing the extracted first task;

[0011] Output the execution result of the first task.

[0012] Optionally, storing the at least one first task in a distributed cache queue by using at least one first thread includes:

[0013] storing the at least one first task in a local queue;

[0014] The at least one first thread is used to extract the first task from the local queue, and the extracted first task is stored in the distributed cache queue.

[0015] Optionally, storing the extracted first task in the distributed cache queue includes:

[0016] Determine whether there is a second task identical to the first task in the distributed cache queue; if not, store the first task in the distributed cache queue.

[0017] Optionally, when there is a second task identical to the first task in the distributed cache queue,

[0018] Determine the difference between the current time and the storage time of the second task. When the difference is greater than the duration threshold, store the first task in the distributed cache queue; wherein the storage time of the second task is the time when the second task is stored in the distributed cache queue.

[0019] Optionally, the service request indicates a processing parameter; and the generating of at least one first task corresponding to at least one of the service requests includes:

[0020] Determining, according to the type of the service request, a target request processing process corresponding to the service request from different types of request processing processes;

[0021] The first task is generated according to the target request processing process and the processing parameters.

[0022] Optionally, the performing the first task includes:

[0023] The target request processing procedure is called according to the processing parameters to execute the first task.

[0024] Optionally, outputting the execution result of the first task includes:

[0025] The execution result is converted into a format that meets the parameter requirements of the requesting end that sends the service request, and the converted execution result is returned to the requesting end.

[0026] To achieve the above objective, according to another aspect of an embodiment of the present invention, a service request processing device is provided.

[0027] A service request processing device according to an embodiment of the present invention includes: a request acquisition module, a task management module, a task execution module, and a result output module; wherein,

[0028] The request acquisition module is used to obtain at least one service request;

[0029] The task management module is configured to respectively generate a first task corresponding to the at least one service request, and store the at least one first task in a distributed cache queue using at least one first thread;

[0030] The task execution module is configured to extract the first task from the distributed cache queue using at least one second thread and execute the extracted first task;

[0031] The result output module is used to output the execution result of the first task.

[0032] Optionally, the service request indicates processing parameters;

[0033] The task management module is used to determine a target request processing process corresponding to the business request from different types of request processing processes according to the type of the business request; and generate the first task according to the target request processing process and the processing parameters.

[0034] Optionally, the task management module is configured to determine whether there is a second task identical to the first task in the distributed cache queue; if not, store the first task in the distributed cache queue.

[0035] To achieve the above objective, according to another aspect of an embodiment of the present invention, an electronic device for processing a service request is provided.

[0036] An electronic device for processing business requests according to an embodiment of the present invention includes: one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement a business request processing method according to an embodiment of the present invention.

[0037] To achieve the above objective, according to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided.

[0038] A computer-readable storage medium according to an embodiment of the present invention stores a computer program, which, when executed by a processor, implements a service request processing method according to an embodiment of the present invention.

[0039] One embodiment of the above invention has the following advantages or beneficial effects: it is capable of generating a first task corresponding to a business request, storing the first task in a distributed cache queue using a first thread, and then extracting and executing the first task from the distributed cache queue using a second thread in response to the business request. This enables asynchronous concurrent storage and execution of the first task corresponding to the business request, thereby controlling the number of concurrent requests by controlling the number of concurrent second threads. In other words, the maximum number of first tasks that can be executed simultaneously can be controlled to be the same as the number of concurrently executed second threads, thereby avoiding the risk of cache breakdown under high concurrency requests and improving system stability.

[0040] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The accompanying drawings are provided for a better understanding of the present invention and are not intended to limit the present invention.

[0042] Figure 1 is a schematic diagram of the main steps of a service request processing method according to an embodiment of the present invention;

[0043] Figure 2 is a schematic diagram of the main steps of task storage in a method for processing a business request according to an embodiment of the present invention;

[0044] Figure 3 is a schematic diagram of the main steps of another service request processing method according to an embodiment of the present invention;

[0045] Figure 4 is a schematic diagram of main modules of a service request processing device according to an embodiment of the present invention;

[0046] Figure 5 is an exemplary system architecture diagram in which embodiments of the present invention may be applied;

[0047] Figure 6 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0048] The following description of exemplary embodiments of the present invention is made in conjunction with the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding. These details should be considered as merely exemplary. Therefore, it should be appreciated by those skilled in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0049] It should be pointed out that, in the absence of conflict, the embodiments of the present invention and the technical features therein may be combined with each other.

[0050] Figure 1 It is a schematic diagram of main steps of a service request processing method according to an embodiment of the present invention.

[0051] like Figure 1 As shown, a service request processing method according to an embodiment of the present invention mainly includes the following steps:

[0052] Step S101: Obtain at least one service request.

[0053] Step S102: generating at least one first task corresponding to the at least one service request, and storing the at least one first task in a distributed cache queue by using at least one first thread.

[0054] The service request processing method provided in the embodiment of the present invention can be implemented by a service request processing device, which may include multiple modules, such as a metadata module, a request acquisition module, a task management module, a task execution module, and a result output module.

[0055] Among them, the request acquisition module may include an interceptor. When the business request processing device obtains the business request sent by the user, the business request can be intercepted by the interceptor to intercept the execution of the request processing process corresponding to the business request, thereby avoiding the business request directly acting on the underlying storage device. It can be understood that in the scenario of high concurrency requests, the number of business requests intercepted by the interceptor is generally multiple. In one embodiment of the present invention, the aspect in aspect-oriented programming can be used to intercept the request processing process marked with a custom @AsyncTask annotation, and then generate the first task corresponding to the business request according to the intercepted request processing process.

[0056] Specifically, in one embodiment of the present invention, metadata information can be recorded in advance through a metadata module. The metadata information includes the definition information of the task type, the type information of the task result, and the task waiting information. The above three types of metadata information are respectively stored in different map data results. In the map corresponding to the task type definition information, the key is the first task identifier, and the value is the task type definition information. Among them, the task type definition information can be a custom java class, which includes the first task identifier, the request processing process corresponding to the task, the class corresponding to the task, and the call parameters corresponding to the task. In addition, in the map of the task result, the key is the first task identifier, and the value is the task return result type information; in the task waiting information, the key is the second task identifier, and the value is the lock object corresponding to the task. In the embodiment of the present invention, the lock object is the CountDownLatch object provided by java.

[0057] When generating the first task, the target request processing process corresponding to the business request can be determined from different types of request processing processes based on the processing parameters indicated by the business request and the type of the business request; and the first task can be generated based on the target request processing process and the processing parameters.

[0058] The definition information of the task type recorded by the metadata module can be shown in Table 1 below:

[0059] Table 1

[0060] Key Value First task logo 1 Task Type Definition 1 First mission logo 2 Task Type Definition 2 …… …… First task identifier n Task Type Definition

[0061] For example, the task type corresponding to task type definition 1 is logistics distribution progress query, and the task type corresponding to task type definition 2 is after-sales claims progress query. Since task type definition 1 and task type definition 2 correspond to different task types, the types of request processing processes corresponding to them are also different. After obtaining the business request, the request acquisition module can determine the type corresponding to the business request, such as determining that the business request corresponds to the logistics distribution progress query type, and determine the target request processing process corresponding to the type of the business request according to Table 1 above, and then send the processing parameters indicated by the business request and information related to the target request processing process to the task management module, so that the task management module can generate a first task corresponding to the business request according to the processing parameters indicated by the business request and the target request processing process.

[0062] Of course, after determining that the business request corresponds to a logistics delivery progress query type, the request acquisition module may also send the business request type to the task management module. The task management module may then, based on the business request type (logistics delivery progress query type) and the task definition type recorded in Table 1 above, determine that the target request processing process corresponding to the business request is the request processing process included in Task Type Definition 1. The task management module then generates a first task based on the processing parameters indicated by the business request and the request processing process.

[0063] In addition, the request acquisition module may also directly forward the service request to the task management module, so that the task management module determines the type of the service request and the target request processing process corresponding to the type of the service request.

[0064] In this example, if the business request type is a logistics delivery progress query, the processing parameters indicated by the business request may include the order number of the order to be queried, the user information (username and mobile phone number) of the order to be queried, and / or the recipient's mobile phone number of the order to be queried. For example, if the processing parameter is the order number "0001" and the business request type is a logistics delivery progress query, then the first task represents querying the logistics delivery progress of order "0001."

[0065] When the task management module generates a first task based on the processing parameters indicated by the business request and the target request processing process, it also generates a second task identifier for the first task. It is worth noting that in this embodiment of the present invention, the first task identifier and the second task identifier represent different identification information. The first task identifier corresponds to the task type definition. That is, different task types correspond to different first task identifiers. For example, the first task identifiers corresponding to the logistics distribution progress query type and the after-sales claims progress query type are different. The second task identifier corresponds to the specific first task. For example, when generating two first tasks, even if the two first tasks belong to the same task type, such as the after-sales claims progress query type, if their processing parameters are different, the second task identifiers of the two first tasks will be different. Specifically, if the processing parameter of first task 1 is "User 1" and the processing parameter of second task 2 is "User 2", that is, first task 1 queries the after-sales claims progress of user 1, and first task 2 queries the after-sales claims progress of user 2, it is clear that even if the two first tasks both belong to the after-sales progress query type, their corresponding second task identifiers should be different.

[0066] In an embodiment of the present invention, a first task identifier can be generated based on the MD5 value of the string corresponding to the request processing process corresponding to the task and the path of the class corresponding to the task. In addition, a second task identifier of the first task can be generated based on the first task identifier, the MD5 value of the string corresponding to the processing parameter, and other symbols (such as underscores). For example, when the first task 2 represents the after-sales claim settlement progress of the querying user 2, if the first task identifier corresponding to the after-sales claim settlement progress type is MM, and the MD5 value of the processing parameter corresponding to the first task 2 is 101, the second task identifier of the first task 2 can be MM_101.

[0067] After generating a second task identifier for the first task, the task management module can return the second task identifier to the request acquisition module, causing the request acquisition module to register the second task identifier in the metadata module's task waiting information, thereby awaiting the processing result of the first task. During the waiting process, the request acquisition module can continue to intercept the execution of the request processing process corresponding to the business request through an interceptor, thereby avoiding system instability caused by a large number of business requests directly accessing the underlying storage device, which may be unable to withstand high concurrent access.

[0068] The task waiting information of the metadata module may be shown in the following Table 2. When the first task is subsequently executed, the first task may be executed according to the lock objects corresponding to the first tasks recorded in Table 2.

[0069] Table 2

[0070] Key Value Second task ID 1 Lock object 1 Second task mark 2 Lock object 2 …… …… Second task identifier n Lock object n

[0071] Of course, the task management module can also register the second task identifier in the task waiting information of the metadata module and notify the request acquisition module of the registration result to wait for the processing result of the first task.

[0072] In addition, the task management module can store the first task in the distributed cache queue, so that the task execution module can extract the first task from the distributed cache queue and execute it. Specifically, after the task management module generates at least one first task corresponding to at least one business request, the generated at least one first task can be stored in a local queue, such as a local blocking queue. It can be understood that in a high-concurrency scenario, the request acquisition module obtains multiple business requests, and accordingly, the task management module also generates multiple first tasks, then the task management module can store these multiple first tasks in the local blocking queue. Then, the task management module can use multiple first threads to extract the first task from the local blocking queue, and then store the extracted first task in the distributed cache queue.

[0073] When storing a first task in a distributed cache queue, it may be determined whether a second task identical to the first task exists in the distributed cache queue. If not, the first task is stored in the distributed cache queue.

[0074] If there is a second task that is the same as the first task in the distributed cache queue, the difference between the current time and the storage time of the second task is determined. When the difference is greater than the duration threshold, the first task is stored in the distributed cache queue; wherein, the storage time of the second task is the time when the second task is stored in the distributed cache queue.

[0075] For example, the task management module can start multiple first threads to asynchronously obtain task data in the blocking queue from the head of the local blocking queue, and then query the cache based on the second task identifier in the task data to see if the first task corresponding to the second task identifier has been placed in the distributed cache queue. If so, it means that the second task identical to the first task already exists in the distributed cache queue. In this case, the difference between the current time and the time when the second task is stored in the distributed cache queue can be determined. When the difference is greater than the duration threshold, it means that the second task in the distributed cache queue has been stored in the distributed cache queue for a long time and its corresponding task data is older. In order to ensure that the first task in the distributed cache queue has the latest task data, the extracted first task can be placed in the distributed cache queue. In this case, the process of placing the first task can be: writing the current time into the cache associated with the second task identical to the first task in the distributed cache queue, without placing the target request processing process corresponding to the first task and the class corresponding to the first task into the distributed cache queue again.

[0076] It can be understood that when the difference between the current time and the storage time of the second task is not greater than the duration threshold, it means that the task data corresponding to the second task is newer, that is, there is no need to repeatedly put the first task into the distributed cache queue. In addition, when there is no second task identical to the first task in the distributed cache queue, the task management module can use the first thread to put the first task into the distributed cache queue. In this case, the process of putting the first task can be: storing the task data related to the first task in the distributed cache queue, and the task data includes the second task identifier and task status information, etc., but may not include the target task processing process and the class corresponding to the first task, etc. Thus, the task anti-duplicate technology is used to ensure that the same business request will not be executed repeatedly, thereby reducing the waste of computing resources and improving the processing efficiency of business requests.

[0077] According to the above embodiment, Figure 2 As shown, the specific implementation of step S102 may include the following steps:

[0078] Step S201: For each business request: according to the type of the business request, determine the target request processing process corresponding to the business request from different types of request processing processes, and generate the first task according to the target request processing process and the processing parameters.

[0079] Step S202: storing the first task corresponding to each of the service requests in a local queue.

[0080] Step S203: Utilize multiple first threads to extract first tasks from the local queue respectively.

[0081] Step S204: Determine whether there is a second task identical to the extracted first task in the distributed cache queue; if so, execute step S205; if not, execute step S207.

[0082] Step S205: Determine the difference between the current time and the storage time of the second task.

[0083] The storage time of the second task is the time when the second task is stored in the distributed cache queue.

[0084] Step S206: Determine whether the difference is greater than the duration threshold. If yes, execute step S207; if not, end the current process.

[0085] Step S207: storing the first task in the distributed cache queue.

[0086] According to the above embodiment, task anti-duplication technology can be used to ensure that the same business request will not be executed repeatedly, thereby reducing the waste of computing resources and improving the processing efficiency of business requests.

[0087] Step S103: Utilize at least one second thread to extract the first task from the distributed cache queue, and execute the extracted first task.

[0088] It is understandable that the first thread used to store the first task in the distributed cache queue and the second thread that extracts and executes the first task from the distributed cache queue can be implemented through different instances. By respectively configuring the number of threads in the thread pool corresponding to different instances, the number of first threads and second threads can be controlled respectively. For example, when the number of configured first instances is 5, the first instance is used to store the first task in the local queue in the distributed cache queue, and there are 5 threads in the thread pool corresponding to each first instance, then the number of first threads is 25. When the number of configured second instances is 10, the second instance is used to extract and execute the first task from the distributed cache queue, and there are 4 threads in the thread pool corresponding to each second instance, then the number of second threads is 40. By configuring different instances to perform the storage and execution of the first task respectively, asynchronous concurrent execution of the first task can be achieved, which is beneficial to improving the processing efficiency of business requests.

[0089] In an embodiment of the present invention, the task execution module of the service request processing device may be used to start a second thread to execute the first task. For example, the second thread may be used to call the target request processing process according to the processing parameters to execute the first task.

[0090] Specifically, when extracting and executing the first task, the task execution module can start multiple second threads to obtain task data from the distributed cache queue, and the task data includes the second task identifier and processing parameters of the first task. Then, the task execution module can obtain the target request processing process in the task type definition information and the class corresponding to the first task from the metadata module based on the second task identifier in the task data, and then use Java reflection technology to complete the call of the target request processing process to execute the first task. At the end of the call, the execution result of the first task can be saved to the cache, and the result output module can be called to output the execution result of the first task. It can be understood that after the task execution module calls the request processing process to execute the first task, it can save the execution result to the cache by itself, or it can call the task management module and the result output module, so that the task management module saves the execution result to the cache, and the result output module outputs the execution result of the first task.

[0091] It is worth mentioning that when the distributed cache queue is located in a distributed cluster (such as Redis cache), the task execution module can extract the first task from the distributed cache queue in a multi-threaded asynchronous manner. In other words, the business request processing device can be located on any server in the distributed cluster, and one or more servers in the distributed cluster can also deploy the business request processing device. When deploying the business request processing device, the jar package corresponding to the business request processing device can be embedded in the target application of the server. When the target application is started, the task metadata information involved in the target application can be saved in the memory of the local map data structure, so that the metadata module stores the relevant metadata information.

[0092] After the task management module in the business request processing device uses one or more first threads to store the first task in the distributed cache queue, the task execution module in the business request processing device on any server in the distributed cluster can use one or more second threads to extract the first task from the distributed cache queue and execute the first task. In other words, each task execution module can use multi-threading to extract multiple first tasks from its own cache or the cache of other servers in the distributed cluster, and execute the extracted first tasks. In other words, the first task in the distributed cache queue of any server in the distributed cluster can be extracted and executed by its own task execution module, and can also be extracted and executed by the task execution modules on other servers in the distributed cluster. Therefore, extracting and executing the first task in the distributed cache queue by asynchronous multi-threading is conducive to improving the processing speed of business requests, and as the number of servers in the distributed cluster increases, the processing capacity of business requests can also be linearly enhanced, thereby improving the processing efficiency of business requests.

[0093] It is worth mentioning that, since the number of first threads and second threads can be controlled by configuring the number of threads in the thread pool corresponding to the instance, and the first task in the distributed cache queue is executed by the second thread, the number of concurrent requests can be controlled by controlling the number of second threads. For example, the number of second instances and / or the number of threads in the thread pool corresponding to each second instance can be determined according to the capacity of the underlying storage device, and the sum of the number of threads corresponding to each second instance (the number of second threads) is the maximum number of concurrent requests to be executed. Even if the business request processing device receives a large number of business requests at the same time, it can still ensure that the number of first tasks executed at the same time is less than or equal to the number of second threads. For example, when the number of configured second instances is 10, the second instance is used to extract and execute the first task from the distributed cache queue, and there are 4 threads in the thread pool corresponding to each second instance, then the number of second threads is 40. Even if 10,000 business requests are received at the same time, the number of concurrent requests for the underlying storage device to execute the first task at the same time is still 40. Therefore, through asynchronous operations, a large number of business requests under high concurrency are converted into a fixed number of requests to execute business logic, ensuring that the frequency of access to the underlying storage device will not change with the change of business request traffic, and thus protecting the access to the underlying storage device from being paralyzed due to the user's high concurrency requests. In other words, the frequency of access to the underlying storage device is guaranteed to be controllable and stable, thereby improving the stability of the system.

[0094] Step S104: outputting the execution result of the first task.

[0095] For example, if the first task is to query the logistics and delivery progress of order "0001", the execution result of the first task will describe the specific logistics links of order "0001". For example, if order "0001" is in the transit stage, the execution result of the first task may include the current transit station of order "0001", the transit station it is about to reach, the transit stations it has passed through, and the estimated delivery time. If order "0001" is in the delivery stage, the execution result of the first task may include the delivery person's name, contact information, and estimated delivery time period (e.g., 9:00-12:00).

[0096] In an embodiment of the present invention, the output of the execution result can be achieved through the result output module. After the first task is executed, the result output module can notify the corresponding waiting thread in the request acquisition module, and the result output module can rely on the publish-subscribe function of the cache to realize the notification of the request acquisition module. For example, the request acquisition module pre-subscribes to the notification message of the result output module. When the result output module publishes the execution result, the execution result indicates the task type corresponding to the first task. The request acquisition module that has subscribed to the notification message corresponding to the task type can obtain the execution result. In addition, in order to facilitate the notification of the execution result, the notification message published by the result output module can add the identifier of the recipient (request acquisition module) before the subject.

[0097] In the prior art, caches are used to support high-concurrency requests from multiple users. When asynchronously processing service requests, the waiting thread does not know when the task corresponding to the service request will be executed. Therefore, it must continuously wait or poll to check whether the task has been completed. Continuous waiting will undoubtedly increase the response time of service requests, while continuous polling will increase the request pressure on the cache. Therefore, compared to the prior art, the embodiment of the present invention adopts a message subscription method, so that the result output module promptly notifies the request acquisition module of the execution result of the first task, improving the timeliness of obtaining the execution result of the first task.

[0098] In addition, in one embodiment of the present invention, the execution result may be converted into a format that meets the parameter requirements of the requesting end that sends the service request, and then the converted execution result is returned to the requesting end.

[0099] In the metadata module, the type information of the task result can be recorded in the form of Table 3 below.

[0100] Table 3

[0101]

[0102]

[0103] Among them, the task execution result information can be a custom Java class that contains the type information of the result returned by the request processing process corresponding to the corresponding first task identifier. In other words, the task execution result information indicates the type of the execution result of the corresponding task (such as the data format, etc.). After the task execution module executes the first task and obtains the execution result of the first task, the execution result can be stored in Table 3 of the metadata module according to the type. The task output module can convert the task execution result according to the result type recorded in the metadata module and the parameter requirements of the request end, and then return the converted execution result to the request end. Of course, the result output module can also notify the request acquisition module of the converted execution result, so that the request acquisition module notifies the request end of the execution result.

[0104] Alternatively, as described above, the result output module notifies the request acquisition module about the execution result of the first task through the subscription function. When the request acquisition module receives the subscription message from the result output module, it can obtain the execution result of the first task from the metadata module, and then convert the execution result according to the parameter requirements of the request end, and then return the converted execution result (that is, the execution result in a format that meets the parameter requirements of the request end) to the request end.

[0105] It is worth mentioning that when the result output module notifies the user of the execution result, the waiting thread of the request acquisition module ends. In addition, when the waiting time of the request acquisition module reaches a preset threshold, the waiting thread of the request acquisition module ends even if the result output module does not notify the user of the execution result. After the waiting time ends, the request acquisition module can obtain the execution result corresponding to the first task from the metadata module. If the first task is not successfully executed when the waiting time of the request acquisition module reaches the preset threshold, the request acquisition module can obtain the execution result indicating that the task execution failed. After obtaining the execution result, the request acquisition module can notify the metadata module to delete the task data related to the first task.

[0106] According to the above embodiment, Figure 3 As shown, a service request processing method provided by an embodiment of the present invention may include the following steps:

[0107] Step S301: Acquire multiple service requests.

[0108] Step S302: generating a plurality of first tasks corresponding to the plurality of service requests respectively, and storing the plurality of first tasks in a distributed cache queue by using a plurality of first threads.

[0109] Step S303: Utilize multiple second threads to extract the first task from the distributed cache queue, and execute the extracted first task.

[0110] Step S304: converting the execution result of the first task into a format that meets the parameter requirements of the requesting end that sends the service request, and returning the converted execution result to the requesting end.

[0111] According to a business request processing method according to an embodiment of the present invention, it can be seen that a first task corresponding to a business request can be generated, and the first task is stored in a distributed cache queue using a first thread, and then the first task is extracted from the distributed cache queue and executed using a second thread to respond to the business request. This achieves asynchronous concurrent storage and execution of the first task corresponding to the business request, so that the number of concurrent requests can be controlled by controlling the number of concurrent second threads. In other words, the maximum number of first tasks that can be executed simultaneously can be controlled to be the number of concurrently executed second threads, thereby avoiding the risk of cache breakdown under high concurrent requests and improving the stability of the system.

[0112] Figure 4 FIG. 4 is a schematic diagram of main modules of a service request processing device according to an embodiment of the present invention.

[0113] like Figure 4 As shown, the service request processing device 400 of the embodiment of the present invention includes: a request acquisition module 401, a task management module 402, a task execution module 403 and a result output module 404; wherein,

[0114] The request acquisition module 401 is used to acquire at least one service request;

[0115] The task management module 402 is configured to generate a first task corresponding to the at least one service request, and store the at least one first task in a distributed cache queue using at least one first thread;

[0116] The task execution module 403 is configured to extract the first task from the distributed cache queue using at least one second thread and execute the extracted first task;

[0117] The result output module 404 is configured to output the execution result of the first task.

[0118] In one embodiment of the present invention, the task management module 402 is used to store the at least one first task in a local queue; extract the first task from the local queue using the at least one first thread, and store the extracted first task in the distributed cache queue.

[0119] In one embodiment of the present invention, the task management module 402 is configured to determine whether a second task identical to the first task exists in the distributed cache queue, and if not, store the first task in the distributed cache queue.

[0120] In one embodiment of the present invention, the task management module 402 is used to determine the difference between the current time and the storage time of the second task, and when the difference is greater than the duration threshold, the first task is stored in the distributed cache queue; wherein, the storage time of the second task is the time when the second task is stored in the distributed cache queue.

[0121] In one embodiment of the present invention, the business request indicates processing parameters; the task management module 402 is used to determine the target request processing process corresponding to the business request from different types of request processing processes based on the type of the business request; and generate the first task based on the target request processing process and the processing parameters.

[0122] In one embodiment of the present invention, the task execution module 403 is configured to call the target request processing procedure according to the processing parameters to execute the first task.

[0123] In one embodiment of the present invention, the result output module 404 is used to convert the execution result into a format that meets the parameter requirements of the requesting end that sends the service request, and return the converted execution result to the requesting end.

[0124] It can be seen from the business request processing device according to the embodiment of the present invention that it is possible to generate a first task corresponding to a business request, store the first task in a distributed cache queue using a first thread, and then extract and execute the first task from the distributed cache queue using a second thread to respond to the business request. This achieves asynchronous concurrent storage and execution of the first task corresponding to the business request, thereby enabling the number of concurrent requests to be controlled by controlling the number of concurrent second threads. In other words, the maximum number of first tasks that can be executed simultaneously can be controlled to be the number of concurrently executed second threads, thereby avoiding the risk of cache breakdown under high concurrent requests and improving the stability of the system.

[0125] Figure 5 An exemplary system architecture 500 is shown to which the service request processing method or service request processing apparatus according to the embodiment of the present invention can be applied.

[0126] like Figure 5 As shown, system architecture 500 may include terminal devices 501, 502, 503, a network 504, and a server 505. Network 504 is used to provide a medium for communication links between terminal devices 501, 502, 503 and server 505. Network 504 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0127] Users can use terminal devices 501, 502, and 503 to interact with server 505 via network 504 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 501, 502, and 503, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0128] The terminal devices 501 , 502 , and 503 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0129] Server 505 may be a server that provides various services, such as a backend management server that supports shopping websites browsed by users using terminal devices 501, 502, and 503. The backend management server may analyze and process received data such as product information query requests, and feed back the processing results (e.g., target push information, product information) to the terminal device.

[0130] It should be noted that the service request processing method provided in the embodiment of the present invention is generally executed by the server 505 , and accordingly, the service request processing device is generally provided in the server 505 .

[0131] It should be understood that Figure 5 The number of terminal devices, networks and servers in the embodiment is merely illustrative. Any number of terminal devices, networks and servers may be provided as required.

[0132] Reference below Figure 6 , which shows a schematic structural diagram of a computer system 600 of a terminal device suitable for implementing an embodiment of the present invention. Figure 6 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0133] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage unit 608 into a random access memory (RAM) 603. Various programs and data required for the operation of the system 600 are also stored in the RAM 603. The CPU 601, ROM 602, and RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0134] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, and the like; an output section 607 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 608 including a hard disk; and a communication section 609 including a network interface card such as a LAN card or a modem. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 610 as needed, so that computer programs read therefrom can be installed into the storage section 608 as needed.

[0135] In particular, according to the embodiments disclosed in the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from a removable medium 611. When the computer program is executed by the central processing unit (CPU) 601, the above-mentioned functions defined in the system of the present invention are performed.

[0136] It should be noted that the computer-readable medium described in the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media can include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. This propagated data signal can take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, optical fiber cable, RF, or any suitable combination thereof.

[0137] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0138] The modules described in the embodiments of the present invention may be implemented in software or hardware. The modules described may also be provided in a processor. For example, they may be described as follows: a processor including a request acquisition module, a task management module, a task execution module, and a result output module. The names of these modules do not, in some cases, limit the modules themselves. For example, the request acquisition module may also be described as a "module for acquiring service requests."

[0139] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiment, or may exist independently and not be incorporated into the device. The computer-readable medium carries one or more programs, and when the one or more programs are executed by the device, the device is caused to: obtain at least one service request; generate at least one first task corresponding to the at least one service request, and store the at least one first task in a distributed cache queue using at least one first thread; extract the first task from the distributed cache queue using at least one second thread and execute the extracted first task; and output the execution result of the first task.

[0140] According to the technical solution of an embodiment of the present invention, it is possible to generate a first task corresponding to a business request, store the first task in a distributed cache queue using a first thread, and then extract and execute the first task from the distributed cache queue using a second thread to respond to the business request. This achieves asynchronous concurrent storage and execution of the first task corresponding to the business request, thereby controlling the number of concurrent requests by controlling the number of concurrent second threads. In other words, the maximum number of first tasks that can be executed simultaneously can be controlled to be the number of concurrently executed second threads, thereby avoiding the risk of cache breakdown under high concurrent requests and improving system stability.

[0141] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A method for processing a business request, characterized in that: include: Get at least one business request; Generating at least one first task corresponding to the at least one business request respectively, and storing the at least one first task in a distributed cache queue by using at least one first thread; Extracting the first task from the distributed cache queue using at least one second thread, and executing the extracted first task; wherein the maximum number of first tasks executed simultaneously is controlled to be the number of concurrently executed second threads; Outputting the execution result of the first task; The storing the at least one first task into the distributed cache queue by using at least one first thread includes: storing the at least one first task in a local queue; extracting the first task from the local queue using the at least one first thread, and storing the extracted first task in the distributed cache queue; The step of storing the extracted first task in the distributed cache queue includes: Determine whether there is a second task identical to the first task in the distributed cache queue, and if not, store the first task in the distributed cache queue; When there is a second task that is the same as the first task in the distributed cache queue, determine the difference between the current time and the storage time of the second task. When the difference is greater than the duration threshold, store the first task in the distributed cache queue; wherein the storage time of the second task is the time when the second task is stored in the distributed cache queue.

2. The method according to claim 1, characterized in that The business request indicates a processing parameter; and the generating of at least one first task corresponding to at least one of the business requests comprises: Determining, according to the type of the service request, a target request processing process corresponding to the service request from different types of request processing processes; The first task is generated according to the target request processing process and the processing parameters.

3. The method according to claim 2, characterized in that The performing of the first task includes: The target request processing procedure is called according to the processing parameters to execute the first task.

4. The method according to claim 1, wherein Outputting the execution result of the first task includes: The execution result is converted into a format that meets the parameter requirements of the requesting end that sends the service request, and the converted execution result is returned to the requesting end.

5. A service request processing device, characterized in that: include: Request acquisition module, task management module, task execution module and result output module; among them, The request acquisition module is used to obtain at least one service request; The task management module is configured to respectively generate a first task corresponding to the at least one service request, and store the at least one first task in a distributed cache queue using at least one first thread; The task execution module is configured to extract the first task from the distributed cache queue using at least one second thread and execute the extracted first task; wherein the maximum number of first tasks executed simultaneously is controlled to be the number of concurrently executed second threads; The result output module is used to output the execution result of the first task; The task execution module is also used to: storing the at least one first task in a local queue; extracting the first task from the local queue using the at least one first thread, and storing the extracted first task in the distributed cache queue; The step of storing the extracted first task in the distributed cache queue includes: Determine whether there is a second task identical to the first task in the distributed cache queue, and if not, store the first task in the distributed cache queue; When there is a second task that is the same as the first task in the distributed cache queue, determine the difference between the current time and the storage time of the second task. When the difference is greater than the duration threshold, store the first task in the distributed cache queue; wherein the storage time of the second task is the time when the second task is stored in the distributed cache queue.

6. The device according to claim 5, characterized in that The service request indicates processing parameters; The task management module is configured to determine, based on the type of the service request, a target request processing process corresponding to the service request from different types of request processing processes; And according to the target request processing process and the processing parameters, the first task is generated.

7. The device according to claim 5, characterized in that The task management module is configured to determine whether a second task identical to the first task exists in the distributed cache queue, and if not, store the first task in the distributed cache queue.

8. An electronic device for processing a service request, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 4.

9. A computer-readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 4 is implemented.

Images