Parallel request processing method and apparatus, electronic device, and storage medium
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING QIYI CENTURY SCI & TECH CO LTD
- Filing Date
- 2023-12-27
- Publication Date
- 2026-07-03
AI Technical Summary
In a microservice distributed architecture, the same user request for data may require multiple calls to the underlying service, leading to excessive traffic and data inconsistency.
By calling a set of node services in parallel, the target node service is determined, data is obtained from the service and stored in the cache, and other node services extract data from the cache, generate feedback data and send it.
It reduces the wasted traffic when multiple node services request data simultaneously and solves the problem of data inconsistency with actual needs.
Smart Images
Figure CN117793205B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a parallel request processing method, apparatus, electronic device, and computer-readable storage medium. Background Technology
[0002] Microservice distributed architecture is a technique for developing a single application as a set of small services, each running in its own process, with lightweight communication mechanisms between services. These services are built around business capabilities and can be deployed independently through fully automated deployment mechanisms.
[0003] One drawback of microservice distributed architecture compared to monolithic architecture is that distributed architecture cannot share variables as easily as monolithic architecture. For underlying services, a single user request may be requested multiple times by different business services, causing the cost of the underlying services to skyrocket.
[0004] When a user opens the application, a single request may pass through multiple microservices, and each microservice may depend on the same underlying central service, such as a user profiling service or an IP resolution service. However, for the same user making the same request, the returned content is identical, such as the user profile and the user's country. But because of the distributed architecture, different services need to retrieve the same content, requiring multiple repeated requests, resulting in high traffic to the underlying central service.
[0005] To reduce traffic, one approach is to use caching to store user-requested data and avoid duplicate data retrieval. However, this method typically maps requests from different times to the same cache, leading to inconsistencies between the cached data and the actual data needed. For example, a user might be a non-member at time T1 and purchase a membership at time T2. Due to caching, the user becomes a member at time T3, but the data displayed to the user is the cached data from time T1 (i.e., the non-member content), resulting in a mismatch between the displayed data and the actual data. Summary of the Invention
[0006] In view of this, in order to solve some or all of the above-mentioned technical problems, embodiments of this application provide a parallel request processing method, apparatus, electronic device, and computer-readable storage medium.
[0007] In a first aspect, embodiments of this application provide a parallel request processing method, the method comprising: receiving a first data request sent by a target user terminal; based on the first data request, concurrently invoking a set of node services corresponding to the first data request; determining a target node service from the set of node services; obtaining requested data using the target node service and storing the requested data in a preset cache; extracting the requested data from the preset cache using other node services in the set of node services besides the target node service; processing the requested data using each node service in the set of node services, generating feedback data for each node service, and sending the feedback data to the target user terminal.
[0008] In one possible implementation, determining the target node service from the set of node services includes: obtaining the second data request generated by each node service in the set of node services; storing the second data requests in the obtained set of second data requests into a data queue in order of their generation time; and determining the node service corresponding to the first second data request in the data queue as the target node service.
[0009] In one possible implementation, obtaining the second data request generated by each node service in the node service set includes: determining the request identifier corresponding to the first data request; and obtaining the second data request generated by each node service in the node service set based on the request identifier.
[0010] In one possible implementation, after storing the second data requests in the acquired second data request set into the data queue in order of their generation time, the method further includes: determining whether the time elapsed between the current time and the generation time of the first second data request in the data queue exceeds a preset time; if it exceeds the preset time, clearing the data queue; and / or determining whether the number of second data requests in the current data queue exceeds a preset number; if it exceeds the preset number, clearing the data queue and establishing a new data queue corresponding to the request identifier.
[0011] In one possible implementation, after determining whether the time elapsed between the current time and the generation time of the second data request at the top of the data queue exceeds a preset time, the method further includes: if the preset time is exceeded, clearing the requested data from a preset cache; after determining whether the number of second data requests in the second data request set exceeds a preset number, the method further includes: if the preset number is exceeded, clearing the requested data from a preset cache.
[0012] In one possible implementation, the process of obtaining the requested data using the target node service and storing the requested data in a preset cache includes: obtaining the device identifier of the target user terminal; determining the target policy engine service corresponding to the device identifier from at least two preset policy engine services based on the device identifier; obtaining the requested data using the target policy engine service; and storing the requested data in the preset cache corresponding to the target policy engine service.
[0013] In one possible implementation, determining the target policy engine service corresponding to the device identifier from at least two preset policy engine services based on the device identifier includes: determining the hash value corresponding to the device identifier based on a hash routing algorithm; and determining the target policy engine service corresponding to the device identifier from at least two policy engine services based on the hash value.
[0014] Secondly, embodiments of this application provide a parallel request processing apparatus, comprising: a receiving module for receiving a first data request sent by a target user terminal; a calling module for concurrently calling a set of node services corresponding to the first data request based on the first data request; a first determining module for determining a target node service from the set of node services; an obtaining module for obtaining requested data using the target node service and storing the requested data in a preset cache; an extraction module for extracting the requested data from the preset cache using other node services in the set of node services besides the target node service; and a generating module for processing the requested data using each node service in the set of node services, generating feedback data for each node service, and sending the feedback data to the target user terminal.
[0015] Thirdly, embodiments of this application provide an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, wherein when the computer program is executed, it implements the method of any embodiment of the parallel request processing method of the first aspect of this application described above.
[0016] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of any embodiment of the parallel request processing method of the first aspect described above.
[0017] Fifthly, embodiments of this application provide a computer program that includes computer-readable code. When the computer-readable code is run on a device, it causes a processor in the device to implement the method of any embodiment of the parallel request processing method of the first aspect described above.
[0018] The parallel request processing method, apparatus, electronic device, and computer-readable storage medium provided in this application embodiment, by parallelly calling a set of node services corresponding to a first data request, determining a target node service from the set of node services, using the target node service to obtain the requested data and storing it in a preset cache, and other node services retrieving the requested data from the preset cache, and finally each node service processing the requested data, generating feedback data, and sending the feedback data to the target user terminal, realizes that when multiple node services corresponding to a certain data request are called in parallel, only one node service needs to call the requested data, and other node services can directly retrieve the requested data from the cache, thereby avoiding excessive traffic consumption caused by repeatedly executing the process of retrieving the requested data according to the request of each node service when multiple node services request data in parallel at the same time. Furthermore, since the cache in this application embodiment is for multiple node services that are called in parallel at the same time for the same data request, rather than the cache of the prior art set for different requests sent at different times, the problem of inconsistency between the requested data and the actual required data can be solved. Attached Figure Description
[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0021] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.
[0022] Figure 1 A flowchart illustrating a parallel request processing method provided in an embodiment of this application;
[0023] Figure 2 A schematic diagram illustrating an application scenario provided in an embodiment of this application;
[0024] Figure 3A This is a schematic diagram illustrating the data request transmission process according to an embodiment of this application;
[0025] Figure 3B This is a schematic diagram illustrating the acquisition of requested data based on a data queue, according to an embodiment of this application.
[0026] Figure 4 A flowchart illustrating another parallel request processing method provided in an embodiment of this application;
[0027] Figure 5 A flowchart illustrating another parallel request processing method provided in an embodiment of this application;
[0028] Figure 6 A flowchart illustrating another parallel request processing method provided in an embodiment of this application;
[0029] Figure 7 A flowchart illustrating another parallel request processing method provided in an embodiment of this application;
[0030] Figure 8 This is a schematic diagram of the structure of a parallel request processing device provided in an embodiment of this application;
[0031] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0032] Various exemplary embodiments of this application will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values of the components and steps set forth in these embodiments do not limit the scope of this application.
[0033] Those skilled in the art will understand that the terms "first" and "second" in the embodiments of this application are only used to distinguish different steps, devices or modules, and do not represent any specific technical meaning, nor do they indicate the logical order between them.
[0034] It should also be understood that in this embodiment, "multiple" can refer to two or more, and "at least one" can refer to one, two or more.
[0035] It should also be understood that any component, data or structure mentioned in the embodiments of this application can generally be understood as one or more unless explicitly defined or given contrary guidance in the context.
[0036] Furthermore, the term "and / or" in this application 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, or B existing alone. Additionally, the character " / " in this application generally indicates that the preceding and following related objects have an "or" relationship.
[0037] It should also be understood that the description of the various embodiments in this application emphasizes the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, they will not be described in detail.
[0038] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the scope of this application and its application or use.
[0039] Techniques, circuits, and devices known to a person skilled in the art may not be discussed in detail, but where appropriate, such techniques, circuits, and devices should be considered part of the specification.
[0040] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.
[0041] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. To facilitate understanding of the embodiments of this application, the application will be described in detail below with reference to the accompanying drawings and embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.
[0042] To address the issue of high data traffic consumption caused by parallel calls to different microservices in existing technologies, this application provides a parallel request processing method that avoids excessive traffic consumption caused by multiple nodes repeatedly requesting data and resolves the problem of inconsistency between the requested data and the actual required data.
[0043] Figure 1 This is a flowchart illustrating a parallel request processing method provided in an embodiment of this application. This method can be applied to one or more electronic devices such as servers, desktop computers, and laptops. This method is typically executed by a server, with the user's terminal device communicating with the server to respond to data requests sent by the terminal device, obtain feedback data corresponding to the data request, and send the feedback data back to the terminal device.
[0044] Furthermore, the execution subject of this method can be either hardware or software. When the execution subject is hardware, it can be one or more of the aforementioned electronic devices. For example, a single electronic device can execute this method, or multiple electronic devices can cooperate with each other to execute this method. When the execution subject is software, this method can be implemented as multiple software programs or software modules, or as a single software program or software module. No specific limitations are made here.
[0045] like Figure 1 As shown, the method specifically includes:
[0046] Step 101: Receive the first data request sent by the target user terminal.
[0047] In this embodiment, the target user terminal can be various types of electronic devices, such as smartphones, tablets, and laptops. Various types of applications can be installed on the target user terminal, such as browsers, video playback software, and real-time communication software. The first data request can be a request generated by the user operating the aforementioned applications using the target user terminal. For example, after the user opens a browser, a data request is generated, and the target user terminal sends this data request (i.e., the first data request) to the execution entity of this method (e.g., a server). This data request is used to request the display of content on the current page.
[0048] Step 102: Based on the first data request, call the set of node services corresponding to the first data request in parallel.
[0049] In this embodiment, when the execution entity receives the first data request, it can parse the first data request and determine the multiple node services corresponding to the current first data request. Each node service can be a microservice contained in the application currently running on the target user terminal.
[0050] As an example, such as Figure 2 As shown, this diagram illustrates the application scenario of this embodiment. When a user opens the application, multiple microservices need to be invoked to display the content of the current page. These microservices include page navigation service, page service, tab service, and services such as recommendations and marketing under the tabs. At least two of these microservices constitute a node service set. Since the above node service set is invoked for a single data request, it is necessary to invoke each node service in parallel at the same time. Each node service depends on the same underlying dependency service (e.g., user profile) to obtain the data fed back by each node service.
[0051] like Figure 3A As shown, this diagram illustrates the data request transmission process according to an embodiment of this application. The target user sends a first data request to the server (i.e., the execution entity of this embodiment). The aggregation layer service on the server can parse the first data request and concurrently call multiple node services at time T1, namely nodes 1-n as shown in the diagram. At time T2, nodes 1-n simultaneously call the strategy engine service on the server, which in turn calls the dependent services to obtain the requested data required by nodes 1-n. It should be noted that... Figure 3AAs shown, the aggregation layer service, node 1-node n, strategy engine service, and dependency service can be set on the same server or on different servers. That is, the same server can be used as the execution subject of this embodiment, and a server cluster consisting of multiple servers can also be used as the execution subject of this embodiment.
[0052] Step 103: Determine the target node service from the set of node services.
[0053] In this embodiment, the execution entity can determine the target node service from the set of node services in various ways. For example, a node service can be randomly selected as the target node service.
[0054] Step 104: Obtain the requested data using the target node service and store the requested data in the preset cache.
[0055] In this embodiment, the preset cache can be a storage area set locally on the execution entity. When the target node service executes, it can obtain the requested data and then store it in the preset cache. Figure 3A As shown, nodes 1 through n simultaneously invoke the strategy engine service at time T2. The strategy engine service can retrieve the requested data from the dependent services based on the request from the target node's service. Typically, the requested data can be stored in a preset cache as a key-value pair structure. For example, the identifier of the first data request can be used as the key, and the requested data can be used as the value and stored in the preset cache accordingly.
[0056] Step 105: Use other node services in the node service set besides the target node service to extract the requested data from the preset cache.
[0057] In this embodiment, the data requested by other node services in the node service set is the same as that requested by the target node service. Therefore, other node services only need to directly extract the requested data from the aforementioned preset cache. As shown in Figure 3, after other node services send a request to the strategy engine service, they wait for the strategy engine service to store the requested data in the cache. When the requested data is stored in the preset cache, other node services can directly extract the requested data from the preset service. The strategy engine service does not need to call the dependent service to obtain the requested data for each request sent by each node service.
[0058] Step 106: Use each node service in the node service set to process the requested data, generate feedback data for each node service, and send the feedback data to the target user.
[0059] In this embodiment, each node service can execute its respective function and generate corresponding feedback data. For example, such as Figure 2In the application scenario shown, microservices such as page navigation service, page service, and tab service can generate feedback data to be displayed to the target user based on the requested data (such as user profile data). Then, the aforementioned execution entity can send the feedback data of each node service to the target user and display the feedback data in the corresponding position on the target user's end.
[0060] The parallel request processing method provided in this application embodiment calls the set of node services corresponding to the first data request in parallel, determines the target node service from the set of node services, uses the target node service to obtain the requested data and stores it in a preset cache, other node services retrieve the requested data from the preset cache, and finally each node service processes the requested data, generates feedback data, and sends the feedback data to the target user terminal. This realizes that when multiple node services corresponding to a certain data request are called in parallel, only one node service needs to call the requested data, and other node services can directly retrieve the requested data from the cache. This avoids the excessive traffic consumption caused by repeatedly executing the process of obtaining the requested data according to the request of each node service when multiple node services request data in parallel at the same time. Furthermore, since the cache in this application embodiment is for multiple node services called in parallel at the same time for the same data request, rather than the cache of the prior art set for different requests sent at different times, the problem of inconsistency between the requested data and the actual required data can be solved.
[0061] In some optional implementations of this embodiment, such as Figure 4 As shown, step 103 includes:
[0062] Step 1031: Obtain the second data request generated by each node service in the node service set.
[0063] Specifically, each node service needs to obtain the requested data during execution, and obtaining the requested data depends on other services. Therefore, each node service can generate new data requests, which are called second data requests.
[0064] like Figure 3B As shown, it illustrates a schematic diagram of retrieving requested data based on a data queue. Figure 3B In the table, traceID3_1-traceID3_n represent the second data requests generated by each node service. traceID1:value and traceID2:value are data requests sent at other times and their corresponding requested data, which are stored in the cache.
[0065] Step 1032: Store the second data requests in the obtained second data request set into the data queue in order of their generation time.
[0066] like Figure 3B As shown, the policy engine service performs the function of operating the data queue. The second data request corresponding to traceID3_1 is located at the beginning of the data queue, and the second data request corresponding to traceID3_n is located at the end of the data queue.
[0067] Step 1033: Determine the node service corresponding to the second data request at the top of the data queue as the target node service.
[0068] like Figure 3B As shown, the second data request corresponding to traceID3_1 is located at the head of the data queue, and the node service corresponding to the second data request represented by traceID3_1 is the target node service. The strategy engine service calls the dependent service according to the second data request sent by the target node service to obtain the requested data. Other node services wait for the strategy engine service to obtain the requested data and store it in the preset cache before directly retrieving the requested data from the preset cache.
[0069] This embodiment sets up a data queue, which enables multiple node services to be called in parallel to obtain the requested data only based on the second data request located at the head of the data queue. Other node services only need to wait to obtain the requested data and then obtain it directly. This achieves the goal of obtaining the requested data by using the earliest generated second data request in the order of the second data request being generated, thereby improving the efficiency of obtaining the requested data.
[0070] In some optional implementations of this embodiment, such as Figure 5 As shown, step 1031 includes:
[0071] Step 10311: Determine the request identifier corresponding to the first data request.
[0072] The request identifier corresponding to the first data request can be preset or automatically generated. This request identifier uniquely represents the request sent by the target user. Optionally, a full-link tracing service can be set up, which generates a corresponding traceID for each request from the device. This traceID is the request identifier.
[0073] Step 10312: Based on the request identifier, obtain the second data request generated by each node service in the node service set.
[0074] Specifically, for the same request, when each node service calls the underlying service, it will generate a data request containing a request identifier (traceID). The aforementioned execution entity can identify all data requests containing this request identifier as the second data request generated by each node service in the node service set.
[0075] This embodiment obtains multiple second data requests corresponding to the first data request sent in the same instance based on the request identifier. This enables the identification of multiple data requests generated from the same data request, allowing for the rapid acquisition of multiple second data requests for the same requested data. This, in turn, helps to quickly and accurately generate the aforementioned data queue and improves the efficiency of obtaining the requested data.
[0076] In some optional implementations of this embodiment, after step 1032 above, the method may further include at least one of the following processing methods:
[0077] Method 1: Determine whether the elapsed time between the current time and the generation time of the second data request at the top of the data queue exceeds a preset time; if it exceeds the preset time, clear the data queue.
[0078] The preset duration can be set statistically based on the actual application scenario. For example, if the gateway logs show that the timestamps of the second data requests for the same traceID in the past are all within 100ms, then the preset duration can be set to 1 second. This means that for the same request, each node service can usually send a second data request within 1 second. After 1 second, it is determined that all node services have basically sent requests, and at this point, the previously established data queue can be cleared.
[0079] Optionally, if the time elapsed between the current time and the generation time of the second data request that is at the top of the data queue exceeds a preset time, and a new second data request containing the above request identifier is obtained again, a new data queue corresponding to the request identifier can be re-established, and the new second data request can be added to the top of the data queue to continue executing the subsequent steps.
[0080] Method 2: Determine whether the number of second data requests in the current data queue exceeds a preset number; if it exceeds the preset number, clear the data queue and create a new data queue corresponding to the request identifier.
[0081] Specifically, the preset quantity can be set according to the needs of the actual application scenario. For example, if the query per second (QPS) rate of the strategy engine service is 10,000, and the strategy engine service instances are set on 50 servers, with each server having a QPS rate of 200, then the preset quantity mentioned above can be set to 200 to accommodate the query capacity of each server. If the number of data requests issued in a single query exceeds the limit, causing the data queue to fill up, the original data queue will be cleared, a new data queue will be created, and the second data request exceeding the limit will be added to the new data queue to continue executing subsequent steps.
[0082] This embodiment achieves effective management of multiple data requests generated from the same request by setting timeout time and / or upper limit of data queue capacity. In the case of parallel data requests timeout or excessive number, it saves storage space consumed by data queue, thereby helping to improve the stability of system operation.
[0083] In some optional implementations of this embodiment, in the first method described above, if the time elapsed between the current time and the generation time of the second data request that is first in the data queue exceeds a preset time, the requested data will be cleared from the preset cache.
[0084] In the second method described above, if the number of second data requests in the current data queue exceeds the preset number, the requested data will be cleared from the preset cache.
[0085] Optionally, after the requested data is cleared from the preset cache, if a new second data request corresponding to the above request identifier is obtained, a new data queue can be re-established, and the node service corresponding to the second data request at the top of the new data queue can be determined as the target node service again, and the above step 104 can be continued.
[0086] This embodiment automatically clears the preset cache when parallel data requests time out or become too numerous, thus saving storage resources in a timely manner and helping to improve the stability of system operation.
[0087] In some optional implementations of this embodiment, such as Figure 6 As shown, step 104 includes:
[0088] Step 1041: Obtain the device identifier of the target user terminal.
[0089] The device identifier is used to uniquely identify the target user terminal.
[0090] Step 1042: Based on the device identifier, determine the target policy engine service corresponding to the device identifier from at least two preset policy engine services.
[0091] Specifically, current background services for applications are typically deployed across multiple servers, meaning multiple instances of the same service are deployed on different servers. This improves horizontal scalability and helps handle increased traffic as business grows. However, the same request from the same user might be sent to different service instances. If the requested data from the previous request is stored in the local cache of that service instance, subsequent requests to different service instances will not be able to retrieve the cached data. Therefore, it is necessary to map the data requested by the target user to the same service instance.
[0092] In this embodiment, the strategy engine service can be deployed on multiple servers, with one strategy engine service running on each server. These strategy engine services have the same function, that is, they can all obtain the requested data based on the data request generated by the node service.
[0093] The aforementioned execution entity can determine the target policy engine service from at least two policy engine services in various ways. For example, the policy engine service corresponding to the device identifier can be pre-configured, and data requests generated by each node service corresponding to the target user terminal can be mapped to the target policy engine service.
[0094] Step 1043: Use the target strategy engine service to obtain the requested data.
[0095] Specifically, the target strategy engine service will execute the corresponding function to obtain the requested data.
[0096] Step 1044: The requested data is stored in the preset cache corresponding to the target strategy engine service.
[0097] Specifically, the preset cache corresponding to the target policy engine service is set on the server where the target policy engine service is located.
[0098] This embodiment sets up multiple instances of dependent services in multiple different policy engine services, and maps the requests and requested data sent by the target user to the same policy engine service according to the device identifier. That is, the same server obtains and caches the requested data based on the data requests generated by each node service, thereby avoiding the increase in the number of requests and data transmissions caused by multiple policy engine services processing the same user's request, and thus reducing data transmission traffic.
[0099] In some optional implementations of this embodiment, such as Figure 7 As shown, step 1042 includes:
[0100] Step 10421: Determine the hash value corresponding to the device identifier based on the hash routing algorithm.
[0101] Step 10422: Based on the hash value, determine the target policy engine service corresponding to the device identifier from at least two policy engine services.
[0102] Specifically, the hash value can be a numerical value corresponding to a device identifier. Each policy engine service corresponds to a numerical value, and the hash value can be calculated to determine the policy engine service corresponding to the calculation result as the target policy engine service.
[0103] As an example, this embodiment can be implemented using a consistent hashing algorithm to solve the problem of unbalanced data processing volume among different strategy engine services.
[0104] This embodiment utilizes a hash routing algorithm to determine the target policy engine service for data requests generated by each node service. This facilitates the expansion of the policy engine service and resolves the data processing imbalance problem among the various policy engine services, thereby helping to improve the performance of user request processing.
[0105] Figure 8 This is a schematic diagram of a parallel request processing device provided in an embodiment of this application. Specifically, it includes: a receiving module 801, used to receive a first data request sent by a target user terminal; a calling module 802, used to concurrently call a set of node services corresponding to the first data request based on the first data request; a first determining module, used to determine a target node service from the set of node services; an obtaining module 803, used to obtain the requested data using the target node service and store the requested data in a preset cache; an extraction module 804, used to extract the requested data from the preset cache using other node services in the set besides the target node service; and a generating module 805, used to process the requested data using each node service in the set, generate feedback data for each node service, and send the feedback data to the target user terminal.
[0106] In some optional implementations of this embodiment, the first determining module includes: a first acquiring unit, used to acquire the second data request generated by each node service in the node service set; a first storage unit, used to store the second data requests in the acquired second data request set into a data queue in the order of their generation time; and a first determining unit, used to determine the node service corresponding to the first second data request in the data queue as the target node service.
[0107] In some optional implementations of this embodiment, the first acquisition unit includes: a determining subunit, used to determine the request identifier corresponding to the first data request; and an acquisition subunit, used to acquire the second data request generated by each node service in the node service set based on the request identifier.
[0108] In some optional implementations of this embodiment, the first determining module further includes: a second determining unit, used to determine whether the time elapsed between the current time and the generation time of the second data request at the top of the data queue exceeds a preset time; if it exceeds the preset time, the data queue is cleared; and / or, a third determining unit, used to determine whether the number of second data requests in the current data queue exceeds a preset number; if it exceeds the preset number, the data queue is cleared, and a new data queue corresponding to the request identifier is established.
[0109] In some optional implementations of this embodiment, the second determining unit is further configured to: if the preset time period is exceeded, clear the requested data from the preset cache; the third determining unit is further configured to: if the preset quantity is exceeded, clear the requested data from the preset cache.
[0110] In some optional implementations of this embodiment, the acquisition module includes: a second acquisition unit, used to acquire the device identifier of the target user terminal; a fourth determination unit, used to determine the target policy engine service corresponding to the device identifier from at least two preset policy engine services based on the device identifier; a third acquisition unit, used to acquire the requested data using the target policy engine service; and a second storage unit, used to store the requested data in a preset cache corresponding to the target policy engine service.
[0111] In some optional implementations of this embodiment, the fourth determining unit includes: a first determining subunit, used to determine the hash value corresponding to the device identifier based on a hash routing algorithm; and a second determining subunit, used to determine the target policy engine service corresponding to the device identifier from at least two policy engine services based on the hash value.
[0112] The parallel request processing device provided in this embodiment can be as follows: Figure 8 The parallel request processing device shown can execute all the steps of the above parallel request processing methods, thereby achieving the technical effects of the above parallel request processing methods. For details, please refer to the above descriptions. For the sake of brevity, it will not be elaborated here.
[0113] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 9 The illustrated electronic device 900 includes at least one processor 901, a memory 902, at least one network interface 904, and other user interfaces 903. The various components in the electronic device 900 are coupled together via a bus system 905. It is understood that the bus system 905 is used to implement communication between these components. In addition to a data bus, the bus system 905 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 9 The general labeled all buses as Bus System 905.
[0114] The user interface 903 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).
[0115] It is understood that the memory 902 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 902 described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0116] In some implementations, memory 902 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 9021 and application program 9022.
[0117] The operating system 9021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 9022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of this application embodiment can be included in the application program 9022.
[0118] In this embodiment, by calling the program or instructions stored in memory 902, specifically the program or instructions stored in application program 9022, processor 901 executes the method steps provided in each method embodiment, including, for example:
[0119] Receive a first data request sent by the target user; based on the first data request, call the set of node services corresponding to the first data request in parallel; determine the target node service from the set of node services; use the target node service to obtain the requested data and store the requested data in a preset cache; use other node services in the set of node services besides the target node service to extract the requested data from the preset cache; use each node service in the set of node services to process the requested data, generate feedback data for each node service, and send the feedback data to the target user.
[0120] The methods disclosed in the embodiments of this application can be applied to or implemented by processor 901. Processor 901 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware or by instructions in the form of software in processor 901. The processor 901 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or can be executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 902. Processor 901 reads the information in memory 902 and, in conjunction with its hardware, completes the steps of the above method.
[0121] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described above in this application, or combinations thereof.
[0122] For software implementation, the techniques described herein can be implemented by units that perform the functions described above. The software code can be stored in memory and executed by a processor. The memory can be implemented within the processor or external to the processor.
[0123] The electronic device provided in this embodiment may be as follows: Figure 9 The electronic device shown can execute all the steps of the parallel request processing methods described above, thereby achieving the technical effects of the parallel request processing methods described above. For details, please refer to the relevant descriptions above. For the sake of brevity, it will not be elaborated here.
[0124] This application also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; it may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and it may also include combinations of the above types of memory.
[0125] When one or more programs in the storage medium can be executed by one or more processors to implement the parallel request processing method described above that is executed on the electronic device side.
[0126] The processor described above is used to execute programs stored in memory to implement the following steps of a parallel request processing method executed on the electronic device side:
[0127] Receive a first data request sent by the target user; based on the first data request, call the set of node services corresponding to the first data request in parallel; determine the target node service from the set of node services; use the target node service to obtain the requested data and store the requested data in a preset cache; use other node services in the set of node services besides the target node service to extract the requested data from the preset cache; use each node service in the set of node services to process the requested data, generate feedback data for each node service, and send the feedback data to the target user.
[0128] Those skilled in the art will further 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, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. 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 circuits to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0129] The steps of the circuits or algorithms described in connection with the embodiments disclosed herein can be implemented in hardware, software modules executed by a processor, or a combination of both. The software modules can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art.
[0130] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also mean including the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The circuit steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of execution is explicitly indicated. It should also be understood that additional or alternative steps may be used.
[0131] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.
Claims
1. A method of parallel request processing, characterized by, The method includes: Receive the first data request sent by the target user; Based on the first data request, the node service set corresponding to the first data request is invoked in parallel. Determine the target node service from the set of node services; The requested data is obtained using the target node service, and the requested data is stored in a preset cache; The requested data is extracted from the preset cache using other node services in the node service set besides the target node service. The requested data is processed using each node service in the node service set to generate feedback data for each node service, and the feedback data is sent to the target user terminal.
2. The method of claim 1, wherein, Determining the target node service from the set of node services includes: Obtain the second data request generated by each node service in the node service set; The second data requests in the acquired second data request set are stored into the data queue in order of their generation time. The node service corresponding to the second data request at the top of the data queue is identified as the target node service.
3. The method of claim 2, wherein, The step of obtaining the second data request generated by each node service in the node service set includes: Determine the request identifier corresponding to the first data request; Based on the request identifier, obtain the second data request generated by each node service in the node service set.
4. The method of claim 3, wherein, After storing the second data requests from the acquired second data request set into the data queue in chronological order of their generation time, the method further includes: Determine whether the elapsed time between the current time and the generation time of the second data request at the top of the data queue exceeds a preset time; if it exceeds the preset time, clear the data queue; and / or, Determine whether the number of second data requests in the current data queue exceeds a preset number; if it exceeds the preset number, clear the data queue and create a new data queue corresponding to the request identifier.
5. The method according to claim 4, characterized in that, After determining whether the elapsed time between the current time and the generation time of the second data request at the top of the data queue exceeds a preset time, the method further includes: If the preset time period is exceeded, the requested data will be cleared from the preset cache; After determining whether the number of second data requests in the second data request set exceeds a preset number, the method further includes: If the number exceeds the preset limit, the requested data will be cleared from the preset cache.
6. The method according to any one of claims 1 to 5, characterized in that, The step of obtaining the requested data using the target node service and storing the requested data in a preset cache includes: Obtain the device identifier of the target user terminal; Based on the device identifier, determine the target policy engine service corresponding to the device identifier from at least two preset policy engine services; The requested data is obtained using the target strategy engine service; The requested data is stored in the preset cache corresponding to the target strategy engine service.
7. The method of claim 6, wherein, The step of determining the target policy engine service corresponding to the device identifier from at least two preset policy engine services based on the device identifier includes: The hash value corresponding to the device identifier is determined based on the hash routing algorithm; Based on the hash value, the target policy engine service corresponding to the device identifier is determined from the at least two policy engine services.
8. A parallel request processing apparatus characterized by comprising: The device includes: The receiving module is used to receive the first data request sent by the target user terminal; The calling module is used to call the set of node services corresponding to the first data request in parallel based on the first data request; The first determining module is used to determine the target node service from the set of node services; The acquisition module is used to acquire the requested data using the target node service and store the requested data in a preset cache. The extraction module is used to extract the requested data from the preset cache using other node services in the node service set besides the target node service; The generation module is used to process the requested data using each node service in the node service set, generate feedback data for each node service, and send the feedback data to the target user terminal.
9. An electronic device, comprising: include: Memory, used to store computer programs; A processor is configured to execute a computer program stored in the memory, wherein when the computer program is executed, it implements the parallel request processing method according to any one of claims 1-7.
10. A computer-readable storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by the processor, it implements the parallel request processing method according to any one of claims 1-7.