Method, device and electronic device for allocating operation requests

Abstract

The present invention discloses a method, device and electronic device for allocating operation requests. The method includes: receiving multiple operation requests, wherein the multiple operation requests respectively carry corresponding target identifiers; determining the target data of the execution buffer in the target controller; determining the first request allocated to the execution buffer and the second request not allocated to the execution buffer from the multiple operation requests based on the target data; determining the waiting buffer corresponding to the second request based on the target identifiers respectively corresponding to the second requests; allocating the first request to the execution buffer to execute the corresponding operation, and allocating the second request to the waiting buffer to wait for the execution of the corresponding operation. The present invention solves the technical problem that during the asynchronous execution process, because multiple operation requests are not allocated, the execution order cannot be determined, resulting in data blocking and operation disorder.

Description

Technical Field

[0001] The present invention relates to the field of data processing, and in particular to a method, device and electronic device for allocating operation requests. Background Art

[0002] When facing multiple operation requests, asynchronous execution is of great significance for improving the responsiveness of the system. At present, when facing multiple operation requests, asynchronous execution is usually performed directly. However, this method has the problem that the execution order of multiple operation requests cannot be determined, which leads to data blocking and operation disorder during the operation.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The embodiments of the present invention provide a method, device and electronic device for allocating operation requests, so as to at least solve the technical problem that during the asynchronous execution process, due to the fact that multiple operation requests are not allocated and the execution order cannot be determined, the data blocking operation is disordered.

[0005] According to one aspect of an embodiment of the present invention, a method for allocating operation requests is provided, comprising: receiving multiple operation requests, wherein the multiple operation requests respectively carry corresponding target identifiers; determining target data of an execution buffer in a target controller, wherein the target data includes program running states corresponding to multiple predetermined identifiers, and the multiple predetermined identifiers include multiple target identifiers; based on the target data, determining a first request allocated to the execution buffer and a second request not allocated to the execution buffer from the multiple operation requests; based on the target identifiers respectively corresponding to the second requests, determining a waiting buffer corresponding to the second request; allocating the first request to the execution buffer to execute the corresponding operation, and allocating the second request to the waiting buffer to wait for the execution of the corresponding operation.

[0006] Optionally, based on the target data, determining a first request allocated to the execution buffer and a second request not allocated to the execution buffer from the multiple operation requests, including: determining a plurality of status results based on the target data, wherein the plurality of status results indicate whether any programs are running for the target identifiers corresponding to the multiple operation requests respectively, and the plurality of status results correspond one-to-one to the plurality of target identifiers; based on the plurality of status results, determining in sequence the first request allocated to the execution buffer and the second request not allocated to the execution buffer in the order in which the multiple operation requests are received.

[0007] Optionally, after allocating the first request to the execution buffer to execute the corresponding operation, it also includes: determining request status information corresponding to the first request, wherein the request status information includes the current execution result corresponding to the first request; sending the request status information to the conveying controller so that the conveying controller determines the execution result parameters based on the request status information; and receiving the execution result parameters fed back by the conveying controller.

[0008] Optionally, receiving the execution result parameters fed back by the conveying controller includes: when the request status information also includes an initial callback function corresponding to the first request, the conveying controller receives the request status information; receiving a target callback function fed back by the conveying controller, wherein the target callback function carries the execution result parameters, and the target callback function is determined by the conveying controller based on the current execution result, and the execution result parameters are stored in the initial callback function.

[0009] Optionally, after allocating the second request to the waiting buffer to wait for execution of the corresponding operation, it also includes: when there is a completed request that has been executed in the execution buffer, determining the execution data volume corresponding to the execution buffer and the first identifier corresponding to the completed request, wherein the execution data volume represents the number of requests being executed in the execution buffer; comparing the execution data volume with a first threshold to obtain a comparison result; when the comparison result is that the execution data volume is less than the first threshold, determining a request to be allocated from the waiting buffer, wherein the request to be allocated is a request corresponding to an identifier in the waiting buffer that is the same as the first identifier; and allocating the request to be allocated to the execution buffer to execute the corresponding operation.

[0010] Optionally, after allocating the first request to the execution buffer to execute the corresponding operation, it also includes: determining the pending request in the execution buffer; when the pending request includes multiple execution sub-steps, determining the count value corresponding to the pending request, wherein the count value represents the execution status of the corresponding execution sub-step of the pending request, when the corresponding execution sub-step starts to execute, the count value is increased by one, and when the corresponding execution sub-step is completed, the count value is reduced by one; when the count value is equal to the second threshold and the number of count changes is equal to the third threshold, the pending request is executed and the pending request is determined to be a completed request.

[0011] Optionally, after receiving multiple operation requests, it also includes: determining the amount of execution data corresponding to the execution buffer, wherein the execution data amount represents the number of requests being executed in the execution buffer; when the execution data amount is greater than a first threshold, allocating the multiple operation requests to the waiting buffer to wait for execution of corresponding operations.

[0012] According to one aspect of an embodiment of the present invention, there is provided an operation request allocation device, comprising: a receiving module, used to receive multiple operation requests, wherein the multiple operation requests respectively carry corresponding target identifiers; a first determination module, used to determine target data of an execution buffer in a target controller, wherein the target data includes program running states corresponding to multiple predetermined identifiers, and the multiple predetermined identifiers include multiple target identifiers; a second determination module, used to determine, from the multiple operation requests, a first request allocated to the execution buffer and a second request not allocated to the execution buffer based on the target data; a third determination module, used to determine a waiting buffer corresponding to the second request based on the target identifiers respectively corresponding to the second requests; and an allocation module, used to allocate the first request to the execution buffer to execute the corresponding operation, and allocate the second request to the waiting buffer to wait for the execution of the corresponding operation.

[0013] According to one aspect of an embodiment of the present invention, there is provided an electronic device, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement any of the above-mentioned methods for allocating operation requests.

[0014] According to one aspect of an embodiment of the present invention, a computer-readable storage medium is provided. When instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute any of the above-mentioned methods for allocating operation requests.

[0015] In an embodiment of the present invention, multiple operation requests are received, wherein the multiple operation requests respectively carry corresponding target identifiers; target data of an execution buffer in a target controller is determined, wherein the target data includes program running states corresponding to multiple predetermined identifiers, and the multiple predetermined identifiers include multiple target identifiers; based on the target data, a first request assigned to the execution buffer and a second request not assigned to the execution buffer are determined from the multiple operation requests; based on the target identifiers respectively corresponding to the second requests, a waiting buffer corresponding to the second request is determined; the first request is assigned to the execution buffer to execute the corresponding operation, and the second request is assigned to the waiting buffer to wait for the execution of the corresponding operation. By determining the first request assigned to the execution buffer and the second request not assigned to the execution buffer from the multiple operation requests based on the target data, and determining the waiting buffer corresponding to the second request based on the target identifiers respectively corresponding to the second requests, the purpose of assigning multiple operation requests to the execution buffer and the waiting buffer is achieved. Since the target data can reflect whether the target indication corresponding to the operation request is currently executing a program, multiple operation requests can be classified according to the target data and allocated to an active buffer that can immediately execute the operation request or a waiting buffer that needs to wait. This can determine the execution order of multiple operation requests, thereby solving the technical problem of data blocking and operation disorder caused by the inability to determine the execution order during asynchronous execution due to the failure to allocate multiple operation requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0017] Figure 1 is a flow chart of a method for allocating operation requests according to an embodiment of the present invention;

[0018] Figure 2 It is a dirty read program diagram provided by an optional implementation mode of the present invention;

[0019] Figure 3 is a structural diagram of an asynchronous execution controller provided in an optional embodiment of the present invention;

[0020] Figure 4 is a flowchart of executing callback provided by an optional implementation manner of the present invention;

[0021] Figure 5 is an execution flow chart of an operation request provided by an optional implementation mode of the present invention;

[0022] Figure 6 It is an asynchronous state execution framework diagram provided by an optional implementation mode of the present invention;

[0023] Figure 7 4 is a structural block diagram of an apparatus for allocating operation requests according to an embodiment of the present invention. DETAILED DESCRIPTION

[0024] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0025] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0026] Example 1

[0027] According to an embodiment of the present invention, an embodiment of a method for allocating operation requests is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0028] Figure 1 is a flow chart of a method for allocating operation requests according to an embodiment of the present invention. Figure 1 As shown, the method comprises the following steps:

[0029] Step S102: receiving multiple operation requests, wherein each of the multiple operation requests carries a corresponding target identifier.

[0030] In step S102 provided in the present application, multiple operation requests are received.

[0031] Among them, operation requests are involved. Operation requests refer to requests sent by the client to the server or system to perform specific operations or tasks, such as data reading, writing, updating or deleting. Operation requests usually contain all the information required to perform the operation, including operation type, data, target identifier, etc.

[0032] Among them, the target identifier is involved. The target identifier refers to the identifier used to clearly specify the target or object of the requested operation in the operation request. It allows the system to route the request to the correct processing node or service to ensure that the request can be executed correctly.

[0033] In this step, multiple operation requests are received at the same time, and each operation request includes a target identifier. This is a basic step for subsequently allocating operation requests and executing multiple operation requests.

[0034] Step S104, determining target data of the execution buffer in the target controller, wherein the target data includes program running states corresponding to a plurality of predetermined identifiers, and the plurality of predetermined identifiers includes a plurality of target identifiers.

[0035] In step S104 provided in the present application, target data of the execution buffer in the target controller is determined.

[0036] Among them, the target controller is involved. The target controller refers to the controller responsible for supervising and scheduling operation requests. Its main responsibility is to ensure that requests are correctly allocated to the designated buffer for queuing and processing.

[0037] Among them, an execution buffer is involved, and the execution buffer refers to a data structure area used to temporarily store operation requests that can be executed.

[0038] Among them, target data is involved, and target data refers to specific data or information associated with the operation request, that is, the program running status related to the target identifiers corresponding to multiple operation requests.

[0039] Among them, a predetermined identifier is involved, and the predetermined identifier refers to multiple execution operation requests corresponding to multiple operations that can be processed by the target controller, and the target identifiers corresponding to the multiple execution operation requests.

[0040] The program running state is involved, and the program running state refers to whether a corresponding operation request is being executed in the execution buffer according to a predetermined identifier.

[0041] In this step, first, the target identifiers included in the multiple operation requests are determined and used as the predetermined identifier. Then, it is determined whether an operation request corresponding to the predetermined identifier is being executed in the execution buffer of the target controller.

[0042] Through this step, the predetermined identifier and the target data can be determined, and in the subsequent allocation step, the target data is used as a reference to more effectively schedule the received multiple operation requests.

[0043] Step S106 , determining, according to the target data, from the plurality of operation requests, a first request that is allocated to the execution buffer and a second request that is not allocated to the execution buffer.

[0044] In step S106 provided in the present application, a first request allocated to the execution buffer and a second request not allocated to the execution buffer are determined from a plurality of operation requests according to the target data.

[0045] Among them, a first request is involved, and the first request refers to an operation request for which no operation request is being executed for the corresponding target identifier, that is, the corresponding operation can be performed.

[0046] Among them, the second request is involved, which refers to the operation request that the corresponding target identifier has an operation request being executed and the operation request that the corresponding target identifier already has a first request, that is, it is necessary to wait until the previous operation is processed before the corresponding operation can be executed.

[0047] In this step, multiple operation requests are divided into first requests and second requests according to target data. The first request can be assigned to the execution buffer for immediate processing, while the second request needs to wait and is not assigned to the execution buffer for the time being.

[0048] Through this step, the first request and the second request are determined, and the execution order or dependency relationship between the requests can be maintained while processing multiple requests in parallel, thereby avoiding data inconsistency or logical errors that may be caused by concurrent execution.

[0049] It should be noted that when processing requests, the system can monitor the status of the execution buffer in real time, such as resource usage, waiting queue length, etc., and adjust the request scheduling strategy based on these feedbacks to achieve more efficient resource management and request processing.

[0050] Step S108: determining a waiting buffer corresponding to the second request according to the target identifiers respectively corresponding to the second requests.

[0051] In step S108 provided in the present application, a waiting buffer area corresponding to the second request is determined according to the target identifiers respectively corresponding to the second requests.

[0052] Among them, a waiting buffer is involved, and the waiting buffer refers to a data structure area used to temporarily store operation requests that cannot be processed immediately.

[0053] In this step, the target identifiers corresponding to the second requests are determined, and the waiting buffers corresponding to the second requests are determined according to the target identifiers corresponding to the second requests, that is, second requests with different target identifiers will be allocated to different waiting buffers.

[0054] Through this step, different waiting buffers corresponding to the second request are determined, and each waiting buffer can manage the second request according to the target identifier, such as priority, dependency, time sensitivity, etc., which makes request scheduling more refined.

[0055] It should be noted that the status of the waiting buffer, such as queue length, average waiting time, etc., can be monitored in real time, and the request scheduling strategy can be adjusted based on these feedbacks to cope with sudden load or performance issues.

[0056] Step S110 , allocating the first request to an execution buffer to execute a corresponding operation, and allocating the second request to a waiting buffer to wait for execution of a corresponding operation.

[0057] In step S110 provided in the present application, the first request is allocated to the execution buffer to execute the corresponding operation, and the second request is allocated to the waiting buffer to wait for the execution of the corresponding operation.

[0058] Through this step, the first requests that can be executed immediately are allocated to the execution buffer, and these requests will be executed according to a predetermined order or priority. At the same time, the second requests that cannot be executed immediately are placed in the waiting buffer, waiting for the execution condition to be met and start execution.

[0059] Through the above steps S102-S110, it is possible to receive multiple operation requests, wherein the multiple operation requests respectively carry corresponding target identifiers; determine the target data of the execution buffer in the target controller, wherein the target data includes the program running status corresponding to the multiple predetermined identifiers, and the multiple predetermined identifiers include multiple target identifiers; determine the first request assigned to the execution buffer and the second request not assigned to the execution buffer from the multiple operation requests based on the target data; determine the waiting buffer corresponding to the second request based on the target identifiers respectively corresponding to the second request; assign the first request to the execution buffer to execute the corresponding operation, and assign the second request to the waiting buffer to wait for the execution of the corresponding operation. By determining the first request assigned to the execution buffer and the second request not assigned to the execution buffer from the multiple operation requests based on the target data, and determining the waiting buffer corresponding to the second request based on the target identifiers respectively corresponding to the second request, the purpose of assigning multiple operation requests to the execution buffer and the waiting buffer is achieved. Since the target data can reflect whether the target indication corresponding to the operation request is currently executing a program, multiple operation requests can be classified according to the target data and allocated to an active buffer that can immediately execute the operation request or a waiting buffer that needs to wait. This can determine the execution order of multiple operation requests, thereby solving the technical problem of data blocking and operation disorder caused by the inability to determine the execution order during asynchronous execution due to the failure to allocate multiple operation requests.

[0060] As an optional embodiment, based on target data, determining a first request allocated to an execution buffer and a second request not allocated to the execution buffer from multiple operation requests, including: determining multiple status results based on the target data, wherein the multiple status results indicate whether there are programs running for target identifiers corresponding to the multiple operation requests respectively, and the multiple status results correspond one-to-one to the multiple target identifiers; based on the multiple status results, determining in sequence the first request allocated to the execution buffer and the second request not allocated to the execution buffer in the order in which the multiple operation requests are received.

[0061] In this embodiment, specific steps of determining a first request allocated to an execution buffer and a second request not allocated to an execution buffer from a plurality of operation requests according to target data are described.

[0062] Among them, the status result is involved. The status result refers to the target identifiers corresponding to multiple operation requests respectively, and whether there are operation requests being executed in the active buffer.

[0063] In this step, first, based on the target data, the status results corresponding to multiple target identifiers are determined, and the status results describe whether there are other corresponding operation requests being executed for the target identifier. Then, based on the status results and the receiving order, the first request and the second request are determined. The operation request for which there are no other operation requests being executed for the corresponding target identifier is the first request, and the operation request for which there is an operation request being executed for the corresponding target identifier and the operation request for which the first request already exists for the corresponding target identifier are the second request.

[0064] Through this step, the status result corresponding to the target identifier is determined, and multiple operation requests are divided into a first request that can be executed immediately and a second request that needs to wait, ensuring that the operation requests can be executed in sequence and avoiding potential data conflicts or logical errors caused by concurrent operations.

[0065] As an optional embodiment, after allocating the first request to the execution buffer to execute the corresponding operation, it also includes: determining the request status information corresponding to the first request, wherein the request status information includes the current execution result corresponding to the first request; sending the request status information to the conveying controller so that the conveying controller determines the execution result parameters based on the request status information; and receiving the execution result parameters fed back by the conveying controller.

[0066] In this embodiment, the specific steps of determining the execution result parameters after allocating the first request to the execution buffer to execute the corresponding operation are described.

[0067] Among them, request status information is involved. The request status information refers to the status and result data during the execution of the first request, such as the current execution result, progress, error information, etc., which is used for status transfer and synchronization between internal components of the system.

[0068] Among them, the current execution result is involved. The current execution result refers to the direct feedback result after the execution of the first request, which includes the output of the execution process, state changes, performance data and other information.

[0069] Among them, a conveying controller is involved. The conveying controller refers to a system component responsible for receiving request status information from the execution buffer and calculating or determining execution result parameters based on this information. The conveying controller can be an asynchronous execution queue to execute asynchronous steps.

[0070] Among them, the execution result parameters are involved. The execution result parameters refer to the quantitative indicators or parameters calculated by the conveying controller that describe the execution result of the first request. These parameters can be statistical results, calculated values ​​or any other form of output, which are used as the basis for subsequent operations or decisions.

[0071] In this step, after the execution buffer completes the operation of the first request, it will first generate request status information and send the current execution result of the first request to the conveying controller. Then, the conveying controller will determine the execution result parameters based on the received request status information. Finally, it will receive the execution result parameters fed back by the conveying controller for subsequent processing or decision-making.

[0072] Through this step, the request status information is sent to the relay controller, the execution result parameters are determined, and resource allocation is intelligently deployed and optimized to achieve simultaneous execution of multiple operation requests, thereby improving the overall operational efficiency, increasing the response speed of data processing, and further enhancing the flexibility of asynchronous processing.

[0073] It should be noted that there may be multiple levels of relay controllers, each of which is responsible for processing different types of request status information and execution result parameters, forming a hierarchical and modular processing flow to improve the flexibility and scalability of the system. The request status information may contain error codes or exception information. The relay controller can be designed with an error detection and repair mechanism. When an error is identified, the corresponding repair process is automatically triggered, such as retry, rollback, or notification of maintenance personnel, to ensure the stability and reliability of the service.

[0074] As an optional embodiment, receiving execution result parameters fed back by the conveying controller includes: when the request status information also includes an initial callback function corresponding to the first request, the conveying controller receives the request status information; receiving a target callback function fed back by the conveying controller, wherein the target callback function carries the execution result parameters, and the target callback function is determined by the conveying controller based on the current execution result, and the execution result parameters are stored in the initial callback function.

[0075] In this embodiment, the specific steps of receiving the execution result parameters fed back by the conveying controller are described.

[0076] Among them, the initial callback function is involved. The initial callback function refers to the function submitted together with the first request, which is called when the request is completed or reaches a certain state. It contains the logic that needs to be executed after the operation request succeeds or fails, such as data processing, error handling, notification, etc.

[0077] Among them, the target callback function is involved. The target callback function refers to the function generated and called by the conveying controller after the request status information is processed. It is based on the initial callback function and contains the execution result parameters added by the conveying controller. The target callback function is used to notify the request initiator of the execution results of the first request and process these results.

[0078] In this step, when the first request is executed in the execution buffer, the request status information is first generated and checked whether the initial callback function related to the first request is included. If the initial callback function exists, the conveying controller receives the request status information, analyzes the current execution result, and determines the execution result parameters. Secondly, the conveying controller injects the execution result parameters into a newly generated target callback function. The target callback function is created based on the initial callback function and contains the execution result parameters of the first request. Finally, the conveying controller calls or feeds back the target callback function so that the execution result parameters can be used for further processing or decision-making.

[0079] Through this step, the initial callback function is used to process the request in a non-blocking manner, making the processing and feedback of request status information more concise and efficient, improving concurrency and response speed. At the same time, it can ensure that the execution result parameters are correctly calculated and encapsulated in the target callback function, which helps to avoid errors and inconsistencies in the data processing process.

[0080] It should be noted that multi-level callbacks can be supported, that is, when the target callback function is executed, a new callback function may be triggered to form a callback chain. If the first request fails to execute, the relay controller can encapsulate the error information in the execution result parameter and notify the request initiator through the target callback function, so as to facilitate timely handling of abnormal situations.

[0081] As an optional embodiment, after allocating the second request to the waiting buffer to wait for execution of the corresponding operation, it also includes: in a case where there is a completed request that has been executed in the execution buffer, determining the execution data volume corresponding to the execution buffer and the first identifier corresponding to the completed request, wherein the execution data volume represents the number of requests being executed in the execution buffer; comparing the execution data volume with the first threshold to obtain a comparison result; when the comparison result is that the execution data volume is less than the first threshold, determining the request to be allocated from the waiting buffer, wherein the request to be allocated is the request corresponding to the identifier in the waiting buffer that is the same as the first identifier; and allocating the request to be allocated to the execution buffer to execute the corresponding operation.

[0082] In this embodiment, specific steps of allocating the second request to the execution buffer to execute the corresponding operation are described.

[0083] Among them, a completed request is involved, and the completed request refers to the first request that has been executed in the execution buffer and has generated an execution result.

[0084] Among them, the execution data volume is involved. The execution data volume refers to an indicator that measures the number of requests being executed in the execution buffer, which reflects the current load and resource usage.

[0085] Among them, the first identifier is involved, and the first identifier refers to the target identifier corresponding to the completed request.

[0086] Among them, the first threshold is involved, which refers to the threshold used to control the amount of execution data in the execution buffer. When the amount of execution data is less than the first threshold, the execution buffer has sufficient resources to process more operation requests, thereby selecting the second request from the waiting buffer and allocating it to the execution buffer.

[0087] The comparison result is involved, and the comparison result refers to the comparison result between the execution data volume and the first threshold value, which is used to determine whether the execution buffer has sufficient resources to execute more operation requests.

[0088] Among them, a pending allocation request is involved, and the pending allocation request refers to a second request that meets the execution condition in the waiting buffer, that is, a second request with the same target identifier as the first identifier.

[0089] In this step, when a completed request exits the execution buffer, first, the execution data volume of the execution buffer is determined. Secondly, the execution data volume is compared with the first threshold to check whether the execution buffer has sufficient resources and capacity to handle more requests. Afterwards, when the execution data volume is less than the first threshold, a second request with the same target identifier and the first identifier of the completed request is determined from the waiting buffer and used as a request to be allocated. Finally, the determined request to be allocated is allocated to the execution buffer to perform the corresponding operation.

[0090] Through this step, the waiting second request is promptly allocated to the execution buffer, which can reduce the waiting time for request processing, reduce the overall delay of the system, and improve the response speed of the system. At the same time, the determination of the first threshold controls the request concurrency of the execution buffer to avoid too many operation requests being executed simultaneously and insufficient computing resources.

[0091] As an optional embodiment, after allocating the first request to the execution buffer to execute the corresponding operation, it also includes: determining the pending request in the execution buffer; when the pending request includes multiple execution sub-steps, determining the count value corresponding to the pending request, wherein the count value represents the execution status of the corresponding execution sub-step of the pending request, when the corresponding execution sub-step starts to execute, the count value is increased by one, and when the corresponding execution sub-step is completed, the count value is reduced by one; when the count value is equal to the second threshold value and the number of count changes is equal to the third threshold value, the pending request is executed and the pending request is determined to be a completed request.

[0092] In this embodiment, the steps of determining a completed request are described.

[0093] Among them, pending requests are involved, and a pending request refers to the first request in the execution buffer that has not yet completed all necessary execution sub-steps.

[0094] Among them, execution sub-steps are involved, and execution sub-steps refer to multiple specific operations or steps that need to be completed in sequence during the process of processing the first request.

[0095] Among them, the count value is involved. The count value refers to the count value used to track the completion status of the execution sub-steps in the pending request. When the corresponding execution sub-step starts to execute, the count value is increased by one. When the corresponding execution sub-step is completed, the count value is reduced by one. When the pending request has completed all the execution sub-steps, its count value is zero.

[0096] The number of count changes is involved, and the number of count changes is the number of times the count value changes. The number of sub-steps executed can be determined by the number of count changes.

[0097] Among them, the second threshold is involved. The second threshold refers to a numerical value used to determine whether a sub-step has been completed. For example, it can be set to 0. Assuming that sub-step A starts with +1 and ends with -1, when the count value corresponding to sub-step A is determined to be 0, it can be determined that sub-step A has been completed.

[0098] Among them, the third threshold is involved. The third threshold refers to a value used to determine whether a request to be completed has completed all execution sub-steps. For example, the third threshold can be twice the number of sub-steps, so that it can determine whether all execution sub-steps have been completed. Because each corresponding sub-step starts and ends with two counts, two changes will be generated. Setting the third threshold to twice the number of sub-steps can accurately determine whether all execution sub-steps have been completed.

[0099] In this step, first, the pending requests in the execution buffer are determined, and then, during the execution process, the corresponding count value is determined. When the corresponding execution sub-step starts to execute, the count value is increased by one, and when the corresponding execution sub-step is completed, the count value is decreased by one. Finally, when the count value is equal to the second threshold, it means that all execution sub-steps in the request have been successfully completed, and at this time, the pending request is marked as a completed request.

[0100] Through this step, the execution status of each operation request is accurately tracked to ensure that the operation request will not be mistakenly marked as completed before all execution sub-steps are completed, resulting in data errors when other operation requests with the corresponding target identifier are executed, thereby ensuring that the order of execution of the operation requests is correct.

[0101] It should be noted that an exception handling mechanism can be designed so that when a sub-step fails to be executed, a sub-step can be automatically restarted or skipped without affecting the accuracy of the count value, thereby improving fault tolerance and recovery capabilities.

[0102] As an optional embodiment, after receiving multiple operation requests, it also includes: determining the execution data volume corresponding to the execution buffer, wherein the execution data volume represents the number of requests being executed in the execution buffer; when the execution data volume is greater than a first threshold, allocating multiple operation requests to a waiting buffer to wait for execution of corresponding operations.

[0103] In this embodiment, specific steps are described for allocating multiple operation requests to a waiting buffer to wait for execution of corresponding operations when the execution data volume is greater than a first threshold after receiving multiple operation requests.

[0104] In this step, the number of first requests currently being executed is first determined to evaluate the current state of the execution buffer. If the amount of execution data exceeds the first threshold, this means that the resources of the execution buffer are close to saturation. In order to ensure system performance and avoid potential resource bottlenecks, the multiple operation requests currently received are assigned to the waiting buffer. The requests in the waiting buffer are temporarily in a waiting state until the amount of execution data in the execution buffer drops below the threshold, and then requests are selected from the waiting buffer and assigned to the execution buffer for processing.

[0105] Through this step, the number of concurrent requests in the execution buffer can be reasonably controlled, which can effectively manage resources, avoid excessive consumption of resources in the execution buffer, and ensure that the system can maintain stable operation under high load.

[0106] Based on the above embodiments and optional embodiments, an optional implementation is provided, which is described in detail below.

[0107] Asynchronous state application programming interfaces (APIs) can improve system responsiveness and concurrency, but out-of-order execution also brings a series of problems:

[0108] 1. Context maintenance and switching: Each input element can involve several state accesses. In asynchronous state execution, the entire process will be split into several stages defined by linked futures and callbacks. They will be executed sequentially in the task thread, but code snippets for different inputs will be mixed together. Each callback execution should have a context that records all necessary runtime information. This also helps track whether the input element is finally processed.

[0109] 2. Necessary order maintenance: A record may contain multiple status requests, and under the asynchronous status API, status requests for different records may be interspersed with each other, which may introduce some concurrency issues such as "dirty reads". Figure 2 is a dirty read program diagram provided by an optional implementation manner of the present invention, such as Figure 2 As shown, record A and record B have the same keyword (same as the target identifier above), and the initial state values ​​are both zero. During the execution process, two situations will occur. Situation 1: record A reads the value first, then record B reads the value, then record A is updated, record B is updated, and the results of records A and B are output. At this time, the data state value is 1. Situation 2: record A reads the value first, then record A is updated, then record B reads the value, record B is updated, and the results of records A and B are output. At this time, the data state value is 2.

[0110] Records with the same key operate on the same state entry, so the order in which their updates and reads are executed will affect the final state. The new runtime framework should ensure that the execution order of these same-key records is effectively equivalent to synchronous execution.

[0111] The optional implementation of the present invention mainly introduces an asynchronous execution controller to solve the above problems. The following are the specific steps of the optional implementation of the present invention.

[0112] S1. Receive user operation request.

[0113] S2. Allocate user operation requests.

[0114] S1 and S2 are mainly completed through asynchronous execution controller. Figure 3 is a structural diagram of an asynchronous execution controller provided by an optional embodiment of the present invention, such as Figure 3 As shown, as the most complex component, the asynchronous execution controller (AEC) receives status requests from users (same as the above-mentioned operation requests), allocates user operation requests, and allocates them to active buffers (same as the above-mentioned execution buffers) and blocking buffers (same as the above-mentioned waiting buffers) according to whether the same keywords (same as the above-mentioned target identifiers) have been executed, and executes these requests according to certain strategies.

[0115] The asynchronous execution controller includes a key accounting unit, which holds the keywords that the incoming status request is using, splits the incoming status request by keyword, pushes it into different buffers, keeps track of the operation request, and records it accordingly. At the same time, the key accounting unit delays subsequent requests until the processing of the previous request is completed, so as to strictly preserve the sequence of elements with the same keyword.

[0116] The asynchronous execution controller includes an active buffer: requests in this buffer can be executed when the buffer is full or times out.

[0117] The asynchronous execution controller also includes a blocking buffer: requests in it should wait until the records with the same key in the active buffer have finished executing, after which the requests queued in the blocking buffer will be moved into the active buffer.

[0118] In order to make full use of memory, the above two buffers also have the function of batch status access requests.

[0119] The pseudo code for when an incoming state request arrives at the AEC is as follows:

[0120] / / incoming state request

[0121] if(!request.getRecord().canProceed()){

[0122] / / apply for processing

[0123] while(inFlightRecords>=limit){

[0124] / / too many inflight records,yield for callback execution.

[0125] yield();

[0126] }

[0127] inFlightRecords++;

[0128] permitToProceed(request.getRecord());

[0129] }

[0130] if(keyAccountingUnit.availableKey(request.getKey())){

[0131] keyAccountingUnit.occupyKey(request.getKey);

[0132] put(activeBuffer,request);

[0133] }else{

[0134] put(blockingBuffer,request);

[0135] }

[0136] / / run if needed

[0137] AEC uses 'records' (Stream Record) to manage the amount of data in flight, tracking the data in flight (records) and blocking input if there is too much data in flight (back pressure). But when the callback of the status request triggers additional status requests, because all of these requests are associated with a single record that has been authorized by the AEC to proceed, the API can be called to pause the current operation, allowing the callback (message in the mailbox) to execute. Therefore, the callback will not be blocked and there is no potential stack overflow risk for recursive API calls.

[0138] S3. Start executing the user operation request and register the corresponding callback function.

[0139] The target thread (State Future) allows registering callbacks through its asynchronous Execute (Then) method, which is called once the result of the state access is ready. Executing these callbacks within the task thread prevents concurrency issues when interacting with internal variables, simplifies the execution order management of callbacks and input processing, and more precisely focuses on parallel state retrieval without involving other central processing unit (CPU) intensive parts of the user code through asynchronous state access semantics.

[0140] Figure 4 is a flowchart of executing callback provided by an optional implementation manner of the present invention, such as Figure 4 As shown, the framework will execute the hook after the status request is completed. This hook encapsulates the callback function provided by the Then() method as a mail and passes it to the Mailbox Executor (same as the above-mentioned conveyor controller), allowing the task thread to execute the callback function.

[0141] According to the existing implementation of the mailbox, callbacks have a higher priority than records. If callbacks for both new and old records exist in the mailbox, the callbacks are processed first.

[0142] To strictly guarantee the consistency of the results of synchronous and asynchronous operation modes, only one record with the same key can be processed at a time. The following record will be buffered and blocked until the previous record with the same key completes all its linked callbacks. For records with different keys, out-of-order execution is allowed.

[0143] The key accounting unit can maintain the order between two independently linked State Future statements. For synchronous interfaces, everything is executed in order and no extra work needs to be done. For asynchronous interfaces, record A should run with reads, updates, and outputs, while record B should stay in the blocking buffer. The core data structure here is to remember the ongoing record and its key.

[0144] The pseudo code for category status access is:

[0145] FinalMap<Key,Record> accounting;

[0146] Publicvoidbuffer(Record record,Key key,StateAccess access){

[0147] Record previous=accounting.putIfAbscent(key,record);

[0148] if(previous==null||previous==record){

[0149] collectToActive(key,access);

[0150] }else{

[0151] collectToBlocking(key,access);

[0152] }

[0153] }

[0154] S4. When executing user operation requests, a counting mechanism is adopted.

[0155] A challenge arises in determining when all processing logic associated with record A has been fully executed. To address this problem, an alternative embodiment of the present invention employs a reference counting mechanism to track ongoing operations (processing input or executing callbacks) associated with a single record. A record is considered to have completed processing if there are no remaining references from these operations. To ensure clear and proper tracking, four rules are established:

[0156] 1. For all keyed stream operators, the count is incremented by 1 before a process element is entered, and decremented by 1 after the process element is entered.

[0157] 2. When Then() is called, the count is incremented by 1.

[0158] 3. After the callback code block in Then() is executed, the count is reduced by 1.

[0159] 4. When the count decreases to 0, all operations on the record are considered completed.

[0160] Figure 5 is an execution flow chart of an operation request provided by an optional implementation mode of the present invention, such as Figure 5 As shown, 1 and 2, 3 and 4, 5 and 6 are corresponding increment and decrement pairs intended to track the pending single code blocks. When the count reaches 0 after 6, the operation of the B record in the blocking buffer will be moved to the active buffer.

[0161] To cover statements without callbacks, each status request itself is also protected by a pairwise reference count.

[0162] Statistics updates are completely managed by the framework and are transparent to the user.

[0163] According to the above design, AEC controls the execution of state requests and corresponding records. However, if the Stream Record in the keyed stream does not touch the state, AEC loses control of it. It disrupts the order of records with the same key and causes correctness issues in some cases.

[0164] To solve this problem, an optional embodiment of the present invention introduces a stricter mode to maintain the order in which process elements are called. Record sorting (default) is that records with the same keyword are processed strictly in the order of arrival; status sorting is that for records with the same key, status requests and subsequent callbacks are processed in the order of the first status request issued for each record, but the code before the first status request of each record can be processed out of order with requests from other records.

[0165] For a stricter record ordering mode, there are some changes before calling process Element.

[0166] To maximize the reuse of AEC's logic, in record sorting mode, an empty request (Empty) is sent to the AEC with process Element as its callback. Once the AEC deems it can be processed (put into the active buffer), it will only call the callback.

[0167] Therefore, the process element encapsulated into the Empty state request will follow the logic of the above AEC and start processing after all the previous same key records have completed execution, otherwise it will stay in the blocking buffer or calling the API if there are too many records in progress.

[0168] An optional implementation manner of the present invention further proposes an asynchronous state execution framework. Figure 6 is an asynchronous state execution framework diagram provided by an optional implementation mode of the present invention, such as Figure 6 As shown, the overall situation of the framework is as follows.

[0169] The user's original code in the process Element will be divided into several stages by future and callback, using the process Element as the entry point for input processing and dedicating a separate callback to each state access.

[0170] Therefore, the implementation will become much more complicated than before. The design of the optional implementation of the present invention is based on the following premises:

[0171] 1. All user code snippets (process Element, callbacks, counter onTimer, etc.) will be executed in a single task thread as before.

[0172] 2. The order of elements with the same partition key will be preserved, while out-of-order execution of elements with different keys is allowed.

[0173] 3. The completed status access results and their callbacks will be encapsulated in messages inserted into the mailbox. These messages will be processed with a higher priority than normal input processing.

[0174] 4. Control the total amount of data being processed and pause processing input when necessary.

[0175] Through the above optional implementation, at least the following beneficial effects can be achieved:

[0176] (1) Comparison with synchronous execution model. The optional implementation mode of the present invention is not inferior to synchronous execution in terms of virtual machine (JVM) memory usage and transactions per second (tps). Compared with asynchronous state storage, query and other time-consuming operations that interact with input and output (I / O), it is convenient, improves the throughput of large-scale batch job computing, better utilizes I / O bandwidth and improves throughput;

[0177] (2) Compared with the batch execution model, the optional implementation of the present invention determines the order of processing requests and improves the accuracy of the system;

[0178] (3) Separate the query of stream computing status data from the calculation, provide a more convenient status query method, and improve the responsiveness and concurrency of the stream computing system.

[0179] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should know that the present invention is not limited by the described action sequence, because according to the present invention, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present invention.

[0180] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods of various embodiments of the present invention.

[0181] Example 2

[0182] According to an embodiment of the present invention, a device for implementing the above-mentioned method for allocating operation requests is also provided. Figure 7 is a structural block diagram of an apparatus for distributing operation requests according to an embodiment of the present invention. Figure 7 As shown, the device includes: a receiving module 702, a first determining module 704, a second determining module 706, a third determining module 708 and an allocating module 710. The device is described in detail below.

[0183] A receiving module 702 is used to receive multiple operation requests, wherein the multiple operation requests respectively carry corresponding target identifiers; a first determination module 704 is connected to the above-mentioned receiving module 702, and is used to determine the target data of the execution buffer in the target controller, wherein the target data includes the program running status corresponding to multiple predetermined identifiers, and the multiple predetermined identifiers include multiple target identifiers; a second determination module 706 is connected to the above-mentioned first determination module 704, and is used to determine, from the multiple operation requests, a first request allocated to the execution buffer and a second request not allocated to the execution buffer based on the target data; a third determination module 708 is connected to the above-mentioned second determination module 706, and is used to determine the waiting buffer corresponding to the second request based on the target identifiers respectively corresponding to the second requests; an allocation module 710 is connected to the above-mentioned third determination module 708, and is used to allocate the first request to the execution buffer to execute the corresponding operation, and allocate the second request to the waiting buffer to wait for the execution of the corresponding operation.

[0184] It should be noted here that the above-mentioned receiving module 702, first determination module 704, second determination module 706, third determination module 708 and allocation module 710 correspond to steps S102 to S110 in the allocation method for implementing the operation request, and the instances and application scenarios implemented by the multiple modules and corresponding steps are the same, but are not limited to the contents disclosed in the above-mentioned embodiment 1.

[0185] Example 3

[0186] According to another aspect of an embodiment of the present invention, there is provided an electronic device, comprising: a processor; and a memory for storing processor-executable instructions, wherein the processor is configured to execute the instructions to implement any of the above-mentioned methods for allocating operation requests.

[0187] Example 4

[0188] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided. When instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute any of the above-mentioned methods for allocating operation requests.

[0189] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0190] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0191] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0192] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0193] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0194] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0195] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for allocating operation requests, characterized in that: include: Receiving multiple operation requests, wherein the multiple operation requests respectively carry corresponding target identifiers; Determining target data of an execution buffer in a target controller, wherein the target data includes a program running state corresponding to a plurality of predetermined identifiers, and the plurality of predetermined identifiers includes a plurality of target identifiers; determining, according to the target data, from the plurality of operation requests, a first request allocated to the execution buffer and a second request not allocated to the execution buffer; Determining a waiting buffer corresponding to the second request according to the target identifiers respectively corresponding to the second request; The first request is allocated to the execution buffer to execute the corresponding operation, and the second request is allocated to the waiting buffer to wait for the execution of the corresponding operation.

2. The method according to claim 1, characterized in that Determining, according to the target data, from the plurality of operation requests, a first request allocated to the execution buffer and a second request not allocated to the execution buffer, comprising: Determine a plurality of status results according to the target data, wherein the plurality of status results indicate whether programs are running for the target identifiers respectively corresponding to the plurality of operation requests, and the plurality of status results correspond to the plurality of target identifiers one by one; According to the multiple status results, and in the order of receiving the multiple operation requests, the first request allocated to the execution buffer and the second request not allocated to the execution buffer are determined in sequence.

3. The method according to claim 1, characterized in that After allocating the first request to the execution buffer to execute the corresponding operation, the method further includes: Determine request status information corresponding to the first request, wherein the request status information includes a current execution result corresponding to the first request; Sending the request status information to a conveying controller so that the conveying controller determines an execution result parameter according to the request status information; Receive the execution result parameter fed back by the conveying controller.

4. The method according to claim 3, characterized in that Receiving the execution result parameter fed back by the conveying controller includes: In a case where the request status information also includes an initial callback function corresponding to the first request, the conveying controller receives the request status information; A target callback function is received from the conveying controller, wherein the target callback function carries the execution result parameter, and the target callback function is determined by the conveying controller according to the current execution result, and the execution result parameter is stored in the initial callback function.

5. The method according to claim 1, characterized in that: After allocating the second request to the waiting buffer to wait for the corresponding operation to be executed, the method further includes: In the case where there are completed requests that have been executed in the execution buffer, determining the execution data volume corresponding to the execution buffer and the first identifier corresponding to the completed request, wherein the execution data volume represents the number of requests being executed in the execution buffer; Comparing the execution data volume with a first threshold value to obtain a comparison result; When the comparison result shows that the amount of executed data is less than the first threshold, determining a request to be allocated from the waiting buffer, wherein the request to be allocated is a request corresponding to an identifier in the waiting buffer that is the same as the first identifier; The to-be-allocated request is allocated to the execution buffer to execute a corresponding operation.

6. The method according to claim 1, characterized in that After allocating the first request to the execution buffer to execute the corresponding operation, the method further includes: Determining pending requests in the execution buffer; In the case where the pending request includes multiple execution sub-steps, determining a count value corresponding to the pending request, wherein the count value indicates the execution status of the execution sub-step corresponding to the pending request, and when the corresponding execution sub-step starts to be executed, the count value is increased by one, and when the corresponding execution sub-step is completed, the count value is decreased by one; When the count value is equal to the second threshold value, and the count change times is equal to the third threshold value, the pending request is executed, and the pending request is determined to be a completed request.

7. The method according to any one of claims 1 to 6, characterized in that After receiving multiple operation requests, it also includes: Determining an execution data volume corresponding to the execution buffer, wherein the execution data volume represents the number of requests being executed in the execution buffer; When the execution data volume is greater than a first threshold, the multiple operation requests are allocated to the waiting buffer to wait for execution of corresponding operations.

8. An operation request allocation device, characterized in that: include: A receiving module, used for receiving a plurality of operation requests, wherein the plurality of operation requests respectively carry a corresponding target identifier; A first determination module, configured to determine target data of an execution buffer in a target controller, wherein the target data includes a program running state corresponding to a plurality of predetermined identifiers, and the plurality of predetermined identifiers includes a plurality of target identifiers; A second determining module is used to determine, according to the target data, from the multiple operation requests, a first request allocated to the execution buffer and a second request not allocated to the execution buffer; A third determining module, configured to determine a waiting buffer corresponding to the second request according to target identifiers respectively corresponding to the second request; The allocation module is used to allocate the first request to the execution buffer to execute the corresponding operation, and allocate the second request to the waiting buffer to wait for the execution of the corresponding operation.

9. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method for allocating operation requests according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the method for allocating operation requests as claimed in any one of claims 1 to 7.

Images