Business processing method, apparatus, device, readable storage medium and program product

Abstract

The application relates to a service processing method, device and equipment, a readable storage medium and a program product. The method comprises the following steps: obtaining a service operation label determined based on a target request, service platform resource information and device state information of a target device; determining a to-be-scheduled service operation label satisfying a scheduling condition based on the service platform resource information and the device state information; constructing a target task chain based on a preset service dependency relationship, the device state information and the to-be-scheduled service operation label; performing task saturation optimization based on the target task chain to obtain a to-be-executed task set; and performing channel selection on each to-be-executed task in the to-be-executed task set based on message queue channel load information included in the service platform resource information, and performing asynchronous delivery based on the selected channel to perform service processing. The method can improve the processing efficiency of services in a high-concurrency service scenario.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a business processing method, apparatus, device, readable storage medium, and program product. Background Technology

[0002] With the continuous increase in the number of electric vehicles, charging service platforms are facing unprecedented challenges in terms of carrying capacity, real-time scheduling capabilities, and overall system stability. Large-scale operating platforms need to manage hundreds of thousands of charging piles and tens of millions of active users simultaneously. User operations, from reservation queuing and equipment control to payment verification, can increase exponentially during peak hours, which places higher demands on the asynchronous processing of the back-end scheduling system.

[0003] In related technologies, message queue technology and microservice architecture are commonly used to split different business modules into independent services to improve throughput. However, when facing high-concurrency business scenarios, problems such as channel congestion and task execution failures are still prone to occur, resulting in low business processing efficiency. Therefore, there is an urgent need for a business processing method that can improve business processing efficiency in high-concurrency business scenarios. Summary of the Invention

[0004] Therefore, it is necessary to provide a business processing method, device, equipment, readable storage medium, and program product that can improve the processing efficiency of business in high-concurrency business scenarios to address the above-mentioned technical problems.

[0005] Firstly, this application provides a business processing method, including:

[0006] Obtain the business operation tag, business platform resource information, and target device status information determined based on the target request;

[0007] Based on the business platform resource information and the device status information, determine the business operation tags that meet the scheduling conditions from the business operation tags;

[0008] Based on the preset business dependencies, the device status information, and the business operation tags to be scheduled, a target task chain is constructed; the target task chain includes at least one task node, and each task node corresponds to the tag binding information and device binding information of the business operation tags to be scheduled.

[0009] Based on the target task chain, task saturation optimization is performed to obtain a set of tasks to be executed.

[0010] Based on the message queue channel load information included in the business platform resource information, a channel is selected for each task in the set of tasks to be executed, and asynchronous delivery is performed based on the selected channel for business processing.

[0011] In one embodiment, obtaining the business operation tag, business platform resource information, and target device status information determined based on the target request includes:

[0012] Obtain the target request; perform intent matching on multiple predefined operation tags based on the target request, and determine the intent matching score corresponding to each of the multiple predefined operation tags; determine at least one business operation tag from the multiple predefined operation tags based on the intent matching scores corresponding to each of the multiple predefined operation tags; generate a status collection instruction based on the request time and request device object contained in the target request; and obtain business platform resource information and target device status information based on the status collection instruction.

[0013] In one embodiment, the service platform resource information includes thread pool information and message queue information; the step of determining the service operation tags to be scheduled that meet the scheduling conditions from the service operation tags based on the service platform resource information and the device status information includes:

[0014] Based on the device status information, determine the device failure rate; based on the thread pool information, determine the thread pool occupancy ratio of the thread pool corresponding to the service operation tag; based on the message queue information, determine the message queue occupancy ratio of the message queue corresponding to the service operation tag; based on the device failure rate, the thread pool occupancy ratio of the thread pool corresponding to the service operation tag, the message queue occupancy ratio of the message queue corresponding to the service operation tag, and the intent matching score of the service operation tag, determine the scheduling score of the service operation tag; based on the scheduling score of the service operation tag, determine the service operation tag to be scheduled that meets the scheduling conditions from at least one of the service operation tags.

[0015] In one embodiment, constructing the target task chain based on preset service dependencies, device status information, and the service operation tag to be scheduled includes:

[0016] Based on the preset business dependencies, the device status information, and the business operation tags to be scheduled, at least one candidate task chain is generated; for each candidate task chain, a stability score is determined based on the scheduling score of the business operation tags to be scheduled, the number of asymmetric dependencies, and the number of device resource conflicts in the candidate task chain; based on the stability scores of at least one candidate task chain, a target task chain is determined from the at least one candidate task chain.

[0017] In one embodiment, the step of optimizing task saturation based on the target task chain to obtain a set of tasks to be executed includes:

[0018] Based on each task node in the target task chain, task registration is performed to obtain an initial task set; the initial task set contains tasks corresponding to each task node; a saturation score is determined based on the number of dependent tasks and task weights corresponding to each task in the initial task set; the saturation score is negatively correlated with the number of dependent tasks; if the saturation score is lower than the saturation score threshold, the target task is deleted from the initial task set, and the process of determining the saturation score based on the number of dependent tasks and task weights corresponding to each task in the initial task set is repeated until the saturation score is not lower than the saturation score threshold, thus obtaining a task set to be executed.

[0019] In one embodiment, the message queue channel load information includes the number of queued tasks and the average waiting time; the step of selecting a channel for each task in the set of tasks to be executed based on the message queue channel load information included in the business platform resource information, and asynchronously delivering the tasks based on the selected channel for business processing, includes:

[0020] For each task in the set of tasks to be executed, a target message queue channel is determined from the message queue channels corresponding to the task to be executed, based on the number of queued tasks and the average waiting time of the message queue channel corresponding to the task to be executed, as well as the task priority of the task to be executed; and the task to be executed is processed asynchronously based on the target message queue channel.

[0021] Secondly, this application also provides a business processing apparatus, comprising:

[0022] The acquisition module is used to acquire the business operation tag, business platform resource information and target device status information determined based on the target request;

[0023] The filtering module is used to determine, based on the business platform resource information and the device status information, the business operation tags that meet the scheduling conditions from the business operation tags;

[0024] The task chain construction module is used to construct a target task chain based on preset business dependencies, the device status information, and the business operation tag to be scheduled; the target task chain includes at least one task node, and each task node corresponds to the tag binding information and device binding information of the business operation tag to be scheduled;

[0025] The optimization module is used to optimize the task saturation based on the target task chain to obtain a set of tasks to be executed;

[0026] The processing module is used to select a channel for each task to be executed in the set of tasks to be executed based on the message queue channel load information included in the business platform resource information, and to asynchronously deliver the task for business processing based on the selected channel.

[0027] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0028] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0029] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0030] The aforementioned business processing methods, devices, equipment, readable storage media, and program products first filter out business operation tags that meet scheduling conditions based on business platform resource information and device status information. This eliminates business operation tags that do not match the current device status or cannot be supported by platform resources, effectively reducing the problem of invalid instructions occupying scheduling resources in high-concurrency scenarios. Then, a target task chain carrying business operation tags and device binding information is constructed by combining preset business dependencies. This transforms the scattered business operation tags to be scheduled into an ordered and device-adaptive combination of task nodes, effectively avoiding the problem of multiple services competing for device resources in disorderly manner in high-concurrency scenarios. Simultaneously, a task saturation assessment of the target task chain is used to form a list of tasks to be executed. The system generates a set of tasks to be executed, which is adapted to the current resource and device status. This effectively reduces device overload and platform processing lag caused by excessive task accumulation in high-concurrency scenarios. Finally, based on the message queue channel load information, the system dynamically selects a message queue channel for each task to be executed and delivers the message asynchronously, ensuring timely message delivery. The above method achieves deep adaptation and dynamic collaboration between business scheduling and platform resources, device status, and message channels. It effectively solves the problems of low scheduling accuracy, unbalanced resource allocation, task accumulation and blocking, and channel delivery bottlenecks in high-concurrency scenarios, which lead to low business processing efficiency. This significantly improves business processing efficiency in high-concurrency scenarios while ensuring the stability and controllable scheduling of business processing. Attached Figure Description

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

[0032] Figure 1 This is an application environment diagram of a business processing method in one embodiment;

[0033] Figure 2 This is a flowchart illustrating a business processing method in one embodiment;

[0034] Figure 3 This is a flowchart illustrating step 201 in one embodiment;

[0035] Figure 4 This is a structural block diagram of a service processing device in one embodiment;

[0036] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

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

[0038] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0039] The business processing method provided in this application embodiment can be applied to, for example, Figure 1 The application environment shown is illustrated. Terminal 101 communicates with server 102 via a network. A data storage system can store the data that server 102 needs to process. The data storage system can be integrated onto server 102, or it can be located in the cloud or on other network servers. A business platform is deployed on server 102.

[0040] Users can initiate a target request through terminal 101. After receiving the target request, server 102 obtains the business operation tag, business platform resource information, and target device status information determined based on the target request. Based on the business platform resource information and device status information, it determines the business operation tags that meet the scheduling conditions from the business operation tags. Based on the preset business dependencies, device status information, and business operation tags to be scheduled, it constructs a target task chain. The target task chain includes at least one task node, and each task node corresponds to the tag binding information and device binding information of the business operation tags to be scheduled. Based on the target task chain, it performs task saturation evaluation to obtain a set of tasks to be executed. Based on the message queue channel load information included in the business platform resource information, it selects a channel for each task to be executed in the set of tasks to be executed and asynchronously delivers it for business processing based on the selected channel.

[0041] Terminal 101 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0042] In one exemplary embodiment, such as Figure 2 The diagram illustrates a business processing method, which is applied to... Figure 1 Taking a server as an example, the server can run a business platform, including the following steps 201 to 205. Among them:

[0043] Step 201: Obtain the business operation tag, business platform resource information and target device status information determined based on the target request.

[0044] Among them, the target request refers to the request used to initiate business needs; taking the charging service as an example, the target request can be a request to initiate the charging service, such as a charging reservation request, a charging payment request, a charging interruption request, etc.

[0045] In some embodiments, a business operation label refers to a label used to indicate the type of business operation; for example, a charging label indicates a charging business, a payment label indicates a payment business, and a reservation label indicates a reservation business.

[0046] The business operation tag determined by the target request refers to the operation tag associated with the business requested by the target request. Furthermore, the business operation tag determined by the target request can be one or more. For example, when the business requested by the target request is a composite business, that is, it needs to be implemented by multiple business operations, the business operation tag determined by the target request is multiple; when the business requested by the target request is a single business, the business operation tag determined by the target request is one.

[0047] In some embodiments, business platform resource information refers to information related to various software and hardware resources, service resources, data resources, and supporting management resources involved in the operation of the business platform; for example, business platform resource information may include the computing resource usage of the business platform, task queue queuing status, device detection information of associated devices, business execution feedback information, etc.

[0048] In some embodiments, the business platform resource information determined based on the target request may be obtained based on the request time of the target request, or based on the business requested by the target request, or based on the request time and the requested business, and the business platform resource information related to the business at the request time.

[0049] In some embodiments, device status information refers to information used to describe various aspects such as device operating status, communication connection status, and fault status.

[0050] In some embodiments, the target device refers to the device determined based on the target request; the target device can be a single device or a cluster of multiple devices; taking the business platform as a charging management platform as an example, the charging management platform can be associated with multiple charging stations, and each charging station can include multiple charging devices. If the target request is initiated based on the first charging station, then the target device determined by the target request is the charging device included in the first charging station, for example, by reserving the charging service of the first charging station through a client; if the target request is initiated based on the first device, then the target device determined by the target request is the first device, for example, by initiating a charging request by scanning the QR code of the first device through a client.

[0051] In some embodiments, the target device can be determined through a target request, and then the device status information of the target device can be collected through a status acquisition interface.

[0052] Step 202: Based on the business platform resource information and device status information, determine the business operation tags that meet the scheduling conditions from the business operation tags.

[0053] In some embodiments, the scheduling conditions are preset. For example, the execution device matching the service operation tag may be in a normal online and fault-free working state, or the priority of the service indicated by the service operation tag may be higher than that of the services waiting in the service platform.

[0054] In some embodiments, the platform scheduling result of the service operation tag may be determined first based on the service platform resource information; then the device scheduling result of the service operation tag may be determined based on the device status information; finally, the comprehensive scheduling result of the service operation tag may be obtained by combining the platform scheduling result and the device scheduling result, and the service operation tag to be scheduled that meets the scheduling conditions may be determined based on the comprehensive scheduling result.

[0055] The services indicated by the pending service operation tags are those that can be implemented based on the current status of the service platform resources and equipment.

[0056] Step 203: Based on the preset business dependency relationships, device status information and business operation tags to be scheduled, construct the target task chain; the task chain includes at least one task node, and each task node corresponds to the tag binding information and device binding information of the business operation tags to be scheduled.

[0057] Among them, the pre-defined business dependency relationship refers to the inherent business logic relationship between different businesses, such as execution sequence association, resource consumption association, or data interaction association. Execution sequence association means that different tasks have an execution order; resource consumption association means that different businesses need to rely on the same device or the same computing resource; data interaction association means that there is data flow between different businesses, such as the execution of subsequent businesses needing the output data of the previously executed business as input.

[0058] In some embodiments, the tasks corresponding to different service operation tags may have different requirements for device status. Therefore, different devices can be assigned to different service operation tags based on device status information.

[0059] In some embodiments, this can be achieved through node traversal and binding driven by business dependencies. That is, firstly, the execution order hierarchy of the business operation tags to be scheduled is sorted out based on the preset business dependencies, and then each business operation tag is traversed sequentially from the top to the bottom of the hierarchy. The execution device in an available state is matched for each tag in combination with the device status information. The tag binding information such as tag identifier and execution parameters are associated with the device binding information such as device number and device type and encapsulated into a task node. The task nodes are then linked together in hierarchical order to form a target task chain.

[0060] In other embodiments, it can also be implemented using a pre-trained neural network model, that is, by using historical data, including historical business dependencies, historical device status information, historical scheduled business operation tags and corresponding optimal task chain construction results, and through supervised learning, the model learns the mapping relationship between features in business scheduling and task chain construction results, thereby outputting the target task chain.

[0061] In some embodiments, multiple task chains can be constructed based on preset business dependencies, device status information, and scheduled business operation tags. In this case, the task chain with the highest stability can be selected as the target task chain based on the stability of the task chain. The stability of the task chain refers to the ability of the task chain to maintain continuous and orderly execution, resist interference, and avoid fault interruption during the execution process, according to preset business dependencies and device status.

[0062] In some embodiments, not all tasks need to be bound to a device. Therefore, the device binding information corresponding to a task node can be empty, that is, no device is bound.

[0063] Step 204: Optimize task saturation based on the target task chain to obtain a set of tasks to be executed.

[0064] Task saturation optimization refers to the process of quantitatively evaluating the resource consumption, dependency connections, and overall load distribution of each task in the target task chain during the execution of the target task chain, so as to optimize the rationality of the dependency relationship between tasks and the balance of resource allocation based on the evaluation results.

[0065] In some embodiments, task saturation can be evaluated using a preset saturation function. This involves substituting relevant information of the target task chain into the preset saturation function to obtain the task saturation evaluation result. Then, the tasks in the target task chain are optimized based on the task saturation evaluation result.

[0066] In some embodiments, optimizing tasks in the target task chain based on task saturation assessment results may involve deleting low-priority tasks from the target task chain or delaying the triggering of low-priority tasks in the target task chain.

[0067] The set of tasks to be executed includes at least one task to be executed based on the target task chain. It can be understood that the tasks in the set of tasks to be executed are tasks that can be implemented based on the current business platform resource information and device status information, and are highly compatible with the current business platform resource information and device status information. In this way, when executing the tasks in the set of tasks to be executed in high-concurrency scenarios, it can effectively reduce the low business processing efficiency caused by problems such as resource allocation imbalance and task backlog and blocking, and significantly improve the business processing efficiency in high-concurrency scenarios.

[0068] Step 205: Based on the message queue channel load information included in the business platform resource information, select a channel for each task to be executed in the set of tasks to be executed, and deliver the task asynchronously based on the selected channel for business processing.

[0069] Among them, message queue channel load information refers to information used to reflect the load status of message queue channels, such as message backlog, processing rate, channel occupancy, response latency, and available bandwidth.

[0070] Asynchronous delivery refers to a delivery method in which the task initiator sends the message to be processed to the message queue channel and can continue to perform subsequent operations without waiting for the receiver to provide immediate feedback on the processing result. The transmission and processing of messages are separated in time.

[0071] In some embodiments, different tasks correspond to different processing modules and require message delivery through different message queue channels; at the same time, each processing module can correspond to one or more message queue channels to adapt to the processing needs of different scales and types of tasks, thereby improving the flexibility and fault tolerance of module processing.

[0072] By leveraging the message queue channel load information included in the business platform resource information, dynamic channel selection is performed for each task in the set of tasks to be executed. The optimal delivery channel can be matched for different tasks based on the real-time load status of each channel, avoiding message backlog and processing delays caused by excessive load on some channels. At the same time, the resources of low-load channels are fully utilized to achieve balanced scheduling of message queue channel resources, improve the task processing efficiency and system stability of the entire business platform, and ensure that all types of tasks can be completed on time as expected.

[0073] In the above business processing method, firstly, business operation tags that meet the scheduling conditions are filtered out based on business platform resource information and device status information. Business operation tags that do not match the current device status or cannot be supported by platform resources are eliminated from the source, thereby reducing the generation of invalid scheduling instructions and effectively reducing the problem of invalid instructions occupying scheduling resources in high-concurrency scenarios. Then, a target task chain carrying business operation tags and device binding information is constructed by combining preset business dependencies. This transforms the scattered business operation tags to be scheduled into an ordered and device-adaptive combination of task nodes, effectively avoiding the problem of multiple services competing for device resources in disorderly manner in high-concurrency scenarios. Simultaneously, by evaluating the task saturation of the target task chain to form a set of tasks to be executed, it is possible to combine device... The current load status and remaining platform resource capacity are used to calculate and filter the task nodes in the task chain, forming a set of tasks to be executed that are adapted to the current resource and device status. This effectively reduces the problem of device overload and platform processing lag caused by excessive task accumulation in high-concurrency scenarios. Finally, based on the message queue channel load information, a message queue channel is dynamically selected for each task to be executed and asynchronous delivery is performed to ensure the timeliness of message delivery. The above method realizes deep adaptation and dynamic collaboration between business scheduling and platform resources, device status, and message channels. It effectively solves the problems of low scheduling accuracy, unbalanced resource allocation, task accumulation and blocking, and channel delivery bottlenecks in high-concurrency scenarios, which lead to low business processing efficiency and significantly improves business processing efficiency in high-concurrency scenarios.

[0074] In one exemplary embodiment, such as Figure 3 As shown, step 201 includes steps 301 to 305. Wherein:

[0075] Step 301: Obtain the target request.

[0076] In some embodiments, the target request may be initiated by a client installed on the terminal; furthermore, the client may initiate the target request in various forms, such as by invoking a structured request through an operation like clicking, or by generating an unstructured request through natural language expressions such as voice or text.

[0077] In some embodiments, a request identifier can be generated for the target request, thereby uniquely identifying the target request and enabling request tracking during the response process of the target request based on the request identifier.

[0078] For example, the identifier of the target request can be generated in the following way:

[0079] ;

[0080] in, A unique identifier for the target request; This represents a hash function that outputs a fixed-length identifier string. This represents a standardized sequence of expressions for the target request. If it is a structured request, it is a string concatenated with field values; if it is a natural language request, it is the raw text. The server timestamp for receiving the target request, and the request identifier. It can be used for request tracing during subsequent processing.

[0081] Step 302: Based on the target request, perform intent matching for multiple predefined operation tags and determine the intent matching score corresponding to each of the multiple predefined operation tags.

[0082] Among them, predefined operation tags are standardized business operation tags that are defined in advance; taking the charging service scenario as an example, predefined operation tags can include tags such as charging start, charging pause, charging termination, charging amount query, charging duration query, charging pile status view, charging order generation, charging fee settlement, charging pile reservation, and fault reporting.

[0083] In some embodiments, the target request can be vectorized first, that is, the target request can be uniformly represented as an operation intent vector that can be identified and scheduled by the business platform. Then, the operation intent vector is matched with multiple predefined operation tags to determine the intent matching score corresponding to each of the multiple predefined operation tags.

[0084] In some embodiments, based on the target request being a structured request, the business platform can directly convert key operation fields into a set of operation tags according to predefined field mapping rules. If a predefined operation tag is in the set of operation tags, it is considered that the predefined operation tag matches the target request, and its matching score is determined to be 1; otherwise, it is 0.

[0085] In some embodiments, if the target request is an unstructured request (such as a natural language request), a model can be first built based on the text sequence of the target request, and the modeling results can be matched with multiple predefined operation tags for intent matching.

[0086] For example, a set of three-layer bidirectional gated recurrent networks can be used to model the input text sequence of the target request, embed it, perform max pooling, and then perform intent matching after linear transformation; the generation process of intent matching scores corresponding to multiple predefined operation labels is as follows:

[0087] .

[0088] in, Represents the operation intent vector. The total number of predefined operation labels; For gated recurrent networks at time steps Hidden state output, To input the word count of the sentence, To hide dimensions; This represents a max pooling operation along the time dimension, resulting in a... ; The label classification weight matrix; This represents the normalized activation function, used to map the score to... Interval, output vector The Middle Each component Indicates the first The score for matching the intent of a predefined action label with the target request.

[0089] Step 303: Based on the intent matching scores corresponding to each of the multiple predefined operation tags, determine at least one business operation tag from the multiple predefined operation tags.

[0090] In some embodiments, an intent matching score threshold can be preset, and predefined operation tags with intent matching scores higher than the preset intent matching score threshold can be identified as business operation tags.

[0091] Step 304: Generate a status acquisition instruction based on the request time and request device object contained in the target request.

[0092] The request time and request device object contained in the target request can be obtained by parsing the target request; the request device object is the target device determined by the target request.

[0093] In some embodiments, the generated status acquisition command can be one or more; when multiple status acquisition commands are generated, different status acquisition commands can be used to acquire different status data.

[0094] In some embodiments, the collection instruction may be based on the request time to generate business platform resource information, that is, to obtain the business platform resource information at the request time of the target request.

[0095] In some embodiments, a device status information acquisition instruction may be generated based on the request time and the requested device object contained in the target request, that is, to obtain the device status information of the requested device object at the request time of the target request.

[0096] Step 305: Based on the status acquisition command, obtain the resource information of the business platform and the device status information of the target device.

[0097] The business platform collects status information by responding to status collection commands, thereby obtaining business platform resource information and target device status information.

[0098] In some embodiments, business platform resource information may include thread pool information, message queue information, platform stability information, etc.

[0099] In some embodiments, the device status of the target device may include idle status, fault status, and communication status.

[0100] In the above embodiments, by matching the target request with multiple predefined operation tags and determining the business operation tag based on the intent matching score, the actual business needs of the target request are accurately matched. At the same time, a status collection instruction is generated based on the request time and the requesting device object of the target request to obtain relevant information. This can accurately collect associated information, avoid invalid collection, improve information collection efficiency, and provide a reliable foundation for subsequent processing.

[0101] In some embodiments, the service platform resource information includes thread pool information and message queue information; based on the service platform resource information and device status information, determining the service operation tags to be scheduled that meet the scheduling conditions from the service operation tags includes:

[0102] Based on equipment status information, determine the equipment failure rate.

[0103] If there is only one target device, the device failure rate is 1 if the device status information of the target device indicates a fault, otherwise it is 0. If there are multiple target devices, the device failure rate is the ratio between the number of target devices with faults and the total number of target devices.

[0104] Based on thread pool information, determine the thread pool occupancy ratio of the thread pool corresponding to the business operation tag.

[0105] The thread pool information reflects the usage of the business platform's concurrent processing capabilities. This information may include the number of threads currently in use, the total number of threads in the thread pool, and the percentage of threads in use.

[0106] In some embodiments, thread pool information includes information on all thread pools in the business platform. Different thread pools can be assigned to handle tasks indicated by different business operation tags. Therefore, for different business operation tags, it is necessary to determine the corresponding thread pool occupancy ratio based on the information of their corresponding thread pools.

[0107] The thread pool utilization rate is the ratio of the used thread pools to the total number of thread pools.

[0108] For example, the business platform includes 10 thread pools, 4 of which are used to handle payment business. Therefore, the thread pool corresponding to the "payment" business operation label is also 4.

[0109] Based on message queue information, determine the message queue occupancy ratio of the message queue corresponding to the business operation tag.

[0110] Among them, message queue information is used to reflect the load level of all message queues in the business platform.

[0111] Similar to thread pools, message queue information includes information about all message queues in the business platform. Different message queues can be assigned to receive tasks indicated by different business operation tags. Therefore, for different business operation tags, it is necessary to determine the corresponding message queue occupancy ratio based on the information of their respective message queues.

[0112] The message queue occupancy ratio is the ratio of the number of queued tasks to the capacity of the message queue.

[0113] The scheduling score of a business operation tag is determined based on the device failure rate, the thread pool occupancy ratio of the thread pool corresponding to the business operation tag, the message queue occupancy ratio of the message queue corresponding to the business operation tag, and the intent matching score of the business operation tag.

[0114] In some embodiments, the scheduling score for a service operation label can be calculated using the following scheduling scoring function:

[0115] .

[0116] in, Indicates the first The scheduling score for each business operation tag. Indicates the first The intent matching score for each business operation tag. Indicates the equipment failure rate. Representing the There are 1 target devices in a fault state, where m represents the total number of target devices. This indicates the thread pool occupancy rate of the thread pool corresponding to the business operation tag. This indicates the percentage of message queue occupancy corresponding to the business operation tag. The preset message queue load threshold (e.g., 0.7). , , These are preset control parameters that control the sensitivity of fault penalties, thread load impact, and superqueue penalties, respectively.

[0117] The above formula controls the scheduling score at three levels: firstly, a fusion score based on semantics and platform resources; secondly, a score based on semantics and platform resources. Secondly, a weighted discount on equipment failure rates, i.e. Thirdly, there is the mandatory penalty for queue congestion, namely... By using the aforementioned scheduling function, risk avoidance can be achieved before scheduling by applying a secondary penalty to the overflow portion of the queue.

[0118] Suppose the semantic score of the user's request to "start charging" is: Equipment failure rate The thread pool usage ratio is The message queue usage ratio is Platform settings parameters , , , Substituting the values, we get:

[0119] .

[0120] Based on the scheduling score of the service operation tag, determine the service operation tag to be scheduled from at least one service operation tag that meets the scheduling conditions.

[0121] In some embodiments, service operation tags that are below a preset scheduling score threshold can be deleted, while service operation tags that are not below the preset scheduling score threshold can be retained as service operation tags to be scheduled that meet the scheduling conditions.

[0122] In the above embodiments, the scheduling score is calculated by integrating the device failure rate, thread pool occupancy rate, message queue occupancy rate, and intent matching score of business operation tags, and the tags to be scheduled are filtered. The scheduling priority is comprehensively evaluated from multiple dimensions, adapting to the device's operating capabilities and platform resource carrying capacity, improving the rationality of business scheduling, ensuring the matching degree of scheduled business, thereby improving the overall business processing efficiency and effectively reducing the problem of invalid instructions occupying scheduling resources in high-concurrency scenarios.

[0123] In some embodiments, a target task chain is constructed based on preset service dependencies, device status information, and tags of services to be scheduled, including:

[0124] Based on preset business dependencies, device status information, and tags of business operations to be scheduled, at least one candidate task chain is generated.

[0125] Among them, the pre-defined business dependency relationship refers to the inherent business logic relationship between different businesses, such as execution sequence association, resource consumption association, or data interaction association. Execution sequence association means that different tasks have an execution order; resource consumption association means that different businesses need to rely on the same device or the same computing resource; data interaction association means that there is data flow between different businesses, such as the execution of subsequent businesses needing the output data of the previously executed business as input.

[0126] In some embodiments, the tasks corresponding to different scheduled service operation tags may have different requirements for device status. Therefore, different devices can be assigned to different scheduled service operation tags based on device status information.

[0127] In some embodiments, this can be achieved through node traversal and binding driven by business dependencies. That is, firstly, the execution order hierarchy of the business operation tags to be scheduled is sorted out based on the preset business dependencies, and then each business operation tag is traversed sequentially from the top to the bottom of the hierarchy. The execution device in the available state is matched for each tag in combination with the device status information. The tag binding information such as tag identifier and execution parameters are associated with the device binding information such as device number and device type and encapsulated into a task node. The task nodes are then linked together in hierarchical order to form a candidate task chain.

[0128] In other embodiments, this can also be achieved using a pre-trained neural network model. This involves using historical data, including historical business dependencies, historical device status information, historical scheduled business operation tags, and corresponding optimal task chain construction results. Through supervised learning, the model learns the mapping relationship between features in business scheduling and task chain construction results, thereby outputting candidate task chains.

[0129] For each candidate task chain, the stability score of the candidate task chain is determined based on the scheduling score of the scheduled business operation tags, the number of asymmetric dependencies, and the number of device resource conflicts in the candidate task chain.

[0130] Asymmetric dependencies refer to redundant dependencies or reverse connections between multiple nodes in a task chain. For example, a redundant dependency means that a task node depends on the same preceding node through multiple paths, or there are repeated dependencies that are unrelated to the business execution logic and can be derived from indirect dependencies. A reverse connection refers to a dependency that contradicts the business execution logic, such as a payment operation's reverse dependency on a control operation. Clearly, redundant dependencies increase the structural complexity of the task chain but have no actual execution necessity; reverse connections directly violate the preset business logic, leading to deadlocks or process loops in task scheduling.

[0131] Device resource conflict refers to different tasks being bound to the same device; obviously, device resource conflict can easily lead to competition for device resources.

[0132] In some embodiments, the stability score of each candidate task chain can be calculated using the following stability function:

[0133] .

[0134] in, This represents the stability score of the current candidate task chain; This represents the number of nodes in the candidate task chain, which is also the number of business operation tags to be scheduled. For nodes in the candidate task chain Scheduling score; Indicates the number of asymmetric dependencies in the candidate task chain; This indicates the number of resource conflicts in the candidate task chain, i.e., the number of times two or more nodes are bound to the same device; and To assign weights to penalty items on the platform, Control structure asymmetric penalty weights Control the intensity of penalties for conflicts with control equipment.

[0135] The target task chain is determined from at least one candidate task chain based on the stability score of at least one candidate task chain.

[0136] In some embodiments, the candidate task chain with the highest stability score may be selected as the target task chain.

[0137] In the above implementation, the graph theory properties of the structure graph itself (such as edge consistency and dependency directionality) and the rationality of resource allocation are introduced as evaluation dimensions through stability scores. In high-concurrency scenarios, task chain structures that may have competition conditions or logical loops can be effectively screened out, avoiding task conflicts in the subsequent task execution process.

[0138] In some embodiments, task saturation optimization is performed based on the target task chain to obtain a set of tasks to be executed, including:

[0139] Based on the task registration of each task node in the target task chain, an initial task set is obtained; the initial task set contains the tasks corresponding to each task node.

[0140] In some embodiments, task registration refers to encapsulating tasks for each task node in the target task chain to obtain a task structure corresponding to each task node.

[0141] In some embodiments, the task structure may include a task number, a target service module identifier (such as payment, control, or device communication), a set of dependent tasks, a task priority, a resource binding identifier, retry policy parameters, and a task timeout period.

[0142] Among them, the task number is used to uniquely identify the task; the dependent task set refers to the preceding tasks that need to be completed before the task can be executed, which can be determined by the target task chain; the target service module identifier is used to indicate the processing module of the task; the task priority is used to indicate the priority of the task; the resource binding identifier is used to indicate the resources required by the task; the retry policy parameter is used to determine the strategy for reprocessing in the event of task processing failure; and the task timeout is the preset maximum allowed time for the task.

[0143] The mapping relationship between business operation tags and processing modules, task priorities, resources, retry policy parameters and task timeout can be pre-defined, so that the target service module identifier, task priority, resource binding identifier, retry policy parameters and task timeout can be determined according to the business operation tag to be scheduled corresponding to the task node.

[0144] In some embodiments, for each task node, a task number can be generated based on the tag number of the scheduled service operation tag corresponding to the task node, the device number of the bound device, and the request identifier of the target request; for example, the task number can be obtained through hash fusion, i.e., the task number. ,in, Indicates task Unique number, The request identifier for the pre-constructed target request can be generated by hashing the request content and the received timestamp. The tag number is the tag number of the service operation tag to be scheduled. This is the device ID to which the task is bound. If the task does not require device binding, then assign a value of 0. Use a hash function to ensure the distribution and uniqueness of the serial numbers.

[0145] The saturation score is determined based on the number of dependent tasks and task weights corresponding to each task in the initial task set; the saturation score is negatively correlated with the number of dependent tasks.

[0146] In some embodiments, the saturation score can be calculated using the following saturation evaluation function:

[0147] .

[0148] in Represents the target task chain The structural saturation score, This represents the number of nodes in the target task chain, which is also the number of business operation tags to be scheduled. Indicates the first task in the initial task set The first task (i.e., the first task in the target task chain) The number of dependent tasks (of nodes), For the first The weight of each task represents its importance to the completion of the target task chain; the weight of each task can be set based on its historical execution time and failure rate. For example, task A, due to its high failure rate, is assigned a higher weight. Task B, because it does not disrupt the main process, is assigned a value. .

[0149] In the above saturation evaluation function, the inverse dependency number is used as a scalability factor to encourage reasonable concurrent structures and suppress meaningless task sequence chains.

[0150] If the saturation score is lower than the saturation score threshold, the target task is removed from the initial task set, and the process of determining the saturation score based on the number of dependent tasks and task weights corresponding to each task in the initial task set is returned until the saturation score is not lower than the saturation score threshold, thus obtaining the task set to be executed.

[0151] In some embodiments, the target task can be determined based on preset rules. For example, the target task can be the task with the lowest priority in the initial task set, or it can be the task with the lowest priority and whose corresponding scheduled business operation tag belongs to the non-critical business tag set. Specific rules can be set according to actual needs.

[0152] Since the saturation score is negatively correlated with the number of dependent tasks, a saturation score below the saturation score threshold indicates that there is a risk of excessive task concentration or unreasonable task dependence in the target task chain. However, the target task chain is already a relatively optimal task chain selected based on stability, so there is limited room for optimizing the structure of the target task chain. On this basis, saturation can be optimized by deleting the target task from the initial task set.

[0153] In the above embodiments, by first registering the task nodes of the target task chain to form an initial task set, and then calculating the saturation score by combining the number of task dependencies and task weights, and iteratively eliminating low-scoring target tasks based on the saturation score threshold, the saturation level of task execution can be quantified. This effectively filters out inefficient tasks with too many dependencies and low execution priority, avoids execution congestion and resource waste in the task chain due to redundant and low-value tasks, and ensures that the retained tasks to be executed have reasonable dependencies and high execution value, thereby improving the overall efficiency and resource utilization of task execution and ensuring that the task chain proceeds in an orderly and efficient manner.

[0154] In some embodiments, the message queue channel load information includes the number of queued tasks and the average waiting time; based on the message queue channel load information included in the business platform resource information, a channel is selected for each task to be executed in the set of tasks to be executed, and asynchronous delivery is performed based on the selected channel for business processing, including:

[0155] For each task in the set of tasks to be executed, the target message queue channel is determined from the message queue channels corresponding to the task to be executed, based on the number of queued tasks and the average waiting time of the message queue channel corresponding to the task to be executed, as well as the task priority of the task to be executed.

[0156] The number of queued tasks in a message queue channel refers to the number of tasks waiting in the queue in the message queue channel.

[0157] The average waiting time of a message queue channel refers to the average time from when a task is delivered to the message queue channel until it is processed. In some embodiments, the average waiting time can be calculated by averaging the delivery delay times of a certain number of tasks in the message queue channel.

[0158] In some embodiments, if there is only one message queue channel corresponding to the task to be executed, that channel can be identified as the target message queue channel.

[0159] In some embodiments, when there are multiple message queue channels corresponding to the task to be executed, the channel score corresponding to each of the multiple message queue channels corresponding to the task to be executed can be calculated based on the number of queued tasks and the average waiting time of the message queue channel corresponding to the task to be executed, as well as the task priority of the task to be executed, and then the target message queue channel can be selected according to the channel score.

[0160] In some embodiments, the target message queue channel can be selected using the following channel function:

[0161] .

[0162] in, Represented as a task The selected target message queue channel, For the task The corresponding set of message queue channels, For channel Current number of queued tasks For the task priority, For channel Average waiting time (in seconds). Score the saturation of the target task chain. and The scheduling weight parameters set for the platform are used to adjust the sensitivity to latency and structure scoring; Representative at Choose the channel that minimizes the expression. .

[0163] For example, a certain task has three channels. , , The queue lengths are 20, 15, and 25 seconds respectively, with average waiting times of 0.6 seconds, 0.8 seconds, and 0.3 seconds respectively. The task priority is... Saturation score of the target task chain Then, the delivery is performed by calculating the weights of the three channels and selecting the channel with the minimum weight.

[0164] Asynchronous delivery is performed based on the target message queue channel to process tasks to be executed.

[0165] In some embodiments, after the task to be executed is delivered to the corresponding target message queue channel, if the task to be executed has dependent tasks, the processing status of the dependent tasks can be detected. If all dependent tasks have been marked for processing, the task to be executed can then be dequeued from the target message queue channel for business processing.

[0166] In the above embodiments, by combining the number of queued tasks and the average waiting time of the message queue channel with the priority of the tasks to be executed to select the channel, the task and the optimal channel can be dynamically matched. This avoids delays caused by high-priority tasks due to excessive channel load and reduces the waste of resources by low-priority tasks occupying high-throughput channels, thereby improving the real-time performance of message delivery and the overall business processing efficiency of the system.

[0167] The following explanation will be based on specific scenarios. Taking the charging service scenario as an example, the charging platform is associated with multiple charging stations, and each charging station includes multiple charging pile devices. Users can initiate charging service requests for any charging station or charging pile device.

[0168] After a user sends a charging service request to a target site via their terminal, the server parses the request to determine the operation intent. It then uses intent matching to determine the matching score of each predefined operation tag. Following this, the charging platform obtains the platform resource status and the charging pile device status of the target site (i.e., the site determined by the charging service request) based on the request time. The platform resource status, including thread pool utilization, task queue percentage, and platform health score, is constructed into a three-dimensional resource vector. ,in This indicates the current usage rate of the thread pool. Indicates the current occupancy rate of the scheduling queue. To obtain a normalized system stability and health score, the status of all charging piles at the target site is collected, and a state matrix is ​​constructed. ,in This represents the number of charging piles at the site, with each row corresponding to the state vector of one pile, including... : Idle state (0 indicates non-idle, 1 indicates idle). : Fault status (0 indicates normal, 1 indicates fault). Communication status (0 indicates offline, 1 indicates online). Then, the scheduling score is calculated through the scheduling scoring function. Service operation tags that are lower than the preset scheduling score threshold are deleted, and service operation tags that are not lower than the preset scheduling score threshold are retained as service operation tags that meet the scheduling conditions.

[0169] Subsequently, since each predefined tag corresponds to a predefined operation template, including fields such as required input resources, logical dependency tag set, and whether device binding is required, device binding is performed for each tag based on device status information. Simultaneously, based on preset business dependencies, a target task chain with resource adaptability, dependency reachability, and concurrency stability is constructed. During the construction of the target task chain, a stability scoring function can be used to select the task chain with the highest stability score as the target task chain.

[0170] A unique task number is generated for each task node in the target task chain, and each task node is encapsulated into a task structure, forming a set of task structures, i.e., the initial task set, making it ready for processing by the asynchronous delivery system. In high-concurrency charging service scenarios, the task chain is not executed all at once, but rather as a sequence of asynchronous executions in a distributed system. Therefore, before entering the scheduling system, each node in the task chain must complete preparatory actions such as standardization, unique task number generation, dependency structure expansion, and resource service mapping. This stage is the connection layer between the logical construction of the task chain and physical scheduling. Insufficient preparation will lead to risks such as out-of-order execution of tasks in the queue, dependency misalignment, or resource routing failure.

[0171] After registering all task structures, to ensure the scheduling safety and distribution rationality of the entire task chain structure, the system introduces a saturation scoring function to measure the rationality of dependencies between tasks in the chain structure and the balance of resource distribution:

[0172] The saturation score determines whether optimization is needed. If the saturation score is below the platform's threshold, it indicates a risk of over-concentration or unreasonable dependencies. Low-priority, non-critical task nodes will be automatically removed, and the score will be re-evaluated to retain the optimal structure. Finally, the tasks to be executed are submitted to a suitable asynchronous message queue and executed concurrently by the corresponding microservice modules. In the high-concurrency charging service scenario addressed by this solution, each node in the task chain may correspond to a different business processing module, such as charging pile equipment control, payment system, reservation confirmation, and status query. Tasks also have sequential dependencies. Therefore, during the message queue scheduling phase, it is necessary to satisfy both the logical dependencies between tasks and the real-time load of each service module to avoid message backlog, channel congestion, or module overload.

[0173] Therefore, it is necessary to first obtain the asynchronous queue configuration status of each service module from the platform resource routing module, and then select the target message queue channel for delivery through the channel selection function. Once a task is dispatched and queued, the business platform will listen in the backend to see if all its dependent task list is completed. For example, it can query the cached task status table. Only when the status of all dependent tasks is marked as "complete" will the task be allowed to be dequeued from the message queue and dispatched to the target service module.

[0174] To prevent tasks from being blocked or wasting resources due to prolonged delays, the business platform can set a maximum task execution time limit. Timed-out tasks will be forcibly marked as "failed," and a failure handling mechanism will be activated. If a task is marked as retryable (pre-configured), it will automatically re-enqueue if the number of retries does not exceed the limit. If the maximum number of retries has been exceeded, the task and its subsequent dependent tasks will be marked as "terminated," and the entire task chain status will be set to "failed." The platform will also generate an exception task event log and send it to the user interface. After all tasks are completed, the platform will summarize the status of all tasks in the task chain structure and write data such as task number, corresponding device number, final execution status, total execution time, and number of failures to the platform's asynchronous execution log database. This data can be used for subsequent system optimization analysis, such as module time consumption evaluation, stub fault diagnosis, and queue configuration adjustment. Furthermore, users can query the task chain status through the front-end application, and the business platform can summarize the status of each task and return it to the user, achieving real-time progress feedback.

[0175] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0176] Based on the same inventive concept, this application also provides a business processing apparatus for implementing the business processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more business processing apparatus embodiments provided below can be found in the limitations of the business processing method described above, and will not be repeated here.

[0177] In one exemplary embodiment, such as Figure 4 As shown, a schematic diagram of a service processing device is provided. The service processing device 400 includes:

[0178] The acquisition module 401 is used to acquire the business operation tag, business platform resource information and target device status information determined based on the target request.

[0179] The filtering module 402 is used to determine the business operation tags that meet the scheduling conditions from the business operation tags based on the business platform resource information and device status information.

[0180] The task chain construction module 403 is used to construct a target task chain based on preset business dependencies, device status information and business operation tags to be scheduled. The task chain includes at least one task node, and each task node corresponds to the tag binding information and device binding information of the business operation tags to be scheduled.

[0181] The optimization module 404 is used to optimize the task saturation based on the target task chain to obtain a set of tasks to be executed.

[0182] The processing module 405 is used to select a channel for each task to be executed in the set of tasks to be executed based on the message queue channel load information included in the business platform resource information, and to asynchronously deliver the task for business processing based on the selected channel.

[0183] In one embodiment, the acquisition module 401 is specifically used to acquire a target request; perform intent matching on multiple predefined operation tags based on the target request to determine the intent matching score corresponding to each of the multiple predefined operation tags; determine at least one business operation tag from the multiple predefined operation tags based on the intent matching score corresponding to each of the multiple predefined operation tags; generate a status collection instruction based on the request time and request device object contained in the target request; and acquire business platform resource information and device status information of the target device based on the status collection instruction.

[0184] In one embodiment, the service platform resource information includes thread pool information and message queue information; the filtering module 402 is specifically used to determine the device failure rate based on the device status information; determine the thread pool occupancy ratio of the thread pool corresponding to the service operation tag based on the thread pool information; determine the message queue occupancy ratio of the message queue corresponding to the service operation tag based on the message queue information; determine the scheduling score of the service operation tag based on the device failure rate, the thread pool occupancy ratio of the thread pool corresponding to the service operation tag, the message queue occupancy ratio of the message queue corresponding to the service operation tag, and the intent matching score of the service operation tag; and determine the service operation tag to be scheduled from at least one service operation tag that meets the scheduling conditions based on the scheduling score of the service operation tag.

[0185] In one embodiment, the task chain construction module 403 is specifically used to generate at least one candidate task chain based on preset business dependencies, device status information, and business operation tags to be scheduled; for each candidate task chain, a stability score is determined based on the scheduling score of the business operation tags to be scheduled in the candidate task chain, the number of asymmetric dependencies, and the number of device resource conflicts; and a target task chain is determined from the at least one candidate task chain based on the stability score of the at least one candidate task chain.

[0186] In one embodiment, the optimization module 404 is specifically used to register tasks based on each task node in the target task chain to obtain an initial task set; the initial task set contains tasks corresponding to each task node; based on the number of dependent tasks and task weights corresponding to each task in the initial task set, a saturation score is determined; the saturation score is negatively correlated with the number of dependent tasks; if the saturation score is lower than the saturation score threshold, the target task is deleted from the initial task set, and the step of determining the saturation score based on the number of dependent tasks and task weights corresponding to each task in the initial task set is returned to be executed until the saturation score is not lower than the saturation score threshold, thus obtaining a task set to be executed.

[0187] In one embodiment, the message queue channel load information includes the number of queued tasks and the average waiting time; the processing module 405 is specifically used to determine the target message queue channel from the message queue channels corresponding to the task to be executed for each task in the set of tasks to be executed, based on the number of queued tasks and the average waiting time of the message queue channel corresponding to the task to be executed, as well as the task priority of the task to be executed; and to asynchronously deliver the task to be executed based on the target message queue channel.

[0188] Each module in the aforementioned business processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0189] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data related to business processing. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a business processing method.

[0190] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0191] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0192] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0193] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described above.

[0194] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0195] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0196] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0197] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A business processing method, characterized in that, The method includes: Obtain the business operation tag, business platform resource information, and target device status information determined based on the target request; Based on the business platform resource information and the device status information, determine the business operation tags that meet the scheduling conditions from the business operation tags; Based on the preset business dependencies, the device status information, and the business operation tags to be scheduled, a target task chain is constructed; the target task chain includes at least one task node, and each task node corresponds to the tag binding information and device binding information of the business operation tags to be scheduled. Based on the target task chain, task saturation optimization is performed to obtain a set of tasks to be executed. Based on the message queue channel load information included in the business platform resource information, a channel is selected for each task to be executed in the set of tasks to be executed, and asynchronous delivery is performed based on the selected channel for business processing. The acquisition of the business operation tag, business platform resource information, and target device status information determined based on the target request includes: Obtain the target request; Based on the target request, intent matching is performed on multiple predefined operation tags to determine the intent matching score corresponding to each of the multiple predefined operation tags; Based on the intent matching scores corresponding to each of the multiple predefined operation tags, at least one business operation tag is determined from the multiple predefined operation tags; Based on the request time and request device object contained in the target request, a status acquisition instruction is generated; Based on the status acquisition command, obtain the business platform resource information and the device status information of the target device; The business platform resource information includes thread pool information and message queue information; The step of determining the scheduled service operation tags that meet the scheduling conditions from the service operation tags based on the service platform resource information and the device status information includes: Based on the equipment status information, the equipment failure rate is determined; Based on the thread pool information, determine the thread pool occupancy ratio of the thread pool corresponding to the business operation tag; Based on the message queue information, determine the message queue occupancy ratio of the message queue corresponding to the business operation tag; Based on the device failure rate, the thread pool occupancy ratio of the thread pool corresponding to the service operation tag, the message queue occupancy ratio of the message queue corresponding to the service operation tag, and the intent matching score of the service operation tag, the scheduling score of the service operation tag is determined. Based on the scheduling score of the service operation tag, determine the service operation tag to be scheduled that meets the scheduling conditions from at least one of the service operation tags; The step of constructing a target task chain based on preset business dependencies, device status information, and the operation tag of the service to be scheduled includes: Based on the preset business dependencies, the device status information, and the business operation tags to be scheduled, at least one candidate task chain is generated. For each candidate task chain, the stability score of the candidate task chain is determined based on the scheduling score of the scheduled service operation tag, the number of asymmetric dependencies, and the number of device resource conflicts in the candidate task chain. Based on the stability score of at least one of the candidate task chains, a target task chain is determined from the at least one candidate task chain; The scheduling score for the service operation label is calculated using the following scheduling scoring function: ； in, Indicates the first The scheduling score for each business operation tag. Indicates the first The intent matching score for each business operation tag. Indicates the equipment failure rate. Representing the There are 1 target devices in a fault state, where m represents the total number of target devices. This indicates the thread pool occupancy rate of the thread pool corresponding to the business operation tag. This indicates the percentage of message queue occupancy corresponding to the business operation tag. The preset message queue load threshold, , , These are preset control parameters that control the sensitivity of fault penalties, thread load impact, and superqueue penalties, respectively.

2. The method according to claim 1, characterized in that, The task saturation optimization based on the target task chain yields a set of tasks to be executed, including: Based on each task node in the target task chain, task registration is performed to obtain an initial task set; the initial task set contains the tasks corresponding to each task node. A saturation score is determined based on the number of dependent tasks and task weights corresponding to each task in the initial task set; the saturation score is negatively correlated with the number of dependent tasks. If the saturation score is lower than the saturation score threshold, the target task is removed from the initial task set, and the process of determining the saturation score based on the number of dependent tasks and task weights corresponding to each task in the initial task set is repeated until the saturation score is not lower than the saturation score threshold, thus obtaining a set of tasks to be executed.

3. The method according to claim 1, characterized in that, The message queue channel load information includes the number of queued tasks and the average waiting time. The step of selecting a channel for each task in the set of tasks to be executed based on the message queue channel load information included in the business platform resource information, and asynchronously delivering the task for business processing based on the selected channel, includes: For each task in the set of tasks to be executed, a target message queue channel is determined from the message queue channels corresponding to the task to be executed, based on the number of queued tasks and the average waiting time of the message queue channel corresponding to the task to be executed, as well as the task priority of the task to be executed. The pending task is processed by asynchronous delivery based on the target message queue channel.

4. A business processing device, characterized in that, The device includes: The acquisition module is used to acquire business operation tags, business platform resource information, and target device status information determined based on the target request; specifically, it is used to acquire the target request; perform intent matching on multiple predefined operation tags based on the target request to determine the intent matching score corresponding to each of the multiple predefined operation tags; determine at least one business operation tag from the multiple predefined operation tags based on the intent matching scores corresponding to each of the multiple predefined operation tags; generate a status collection instruction based on the request time and request device object contained in the target request; and acquire the business platform resource information and target device status information based on the status collection instruction. A filtering module is used to determine, based on the business platform resource information and the device status information, business operation tags that meet scheduling conditions from the business operation tags to be scheduled; the business platform resource information includes thread pool information and message queue information; the filtering module is specifically used to determine the device failure rate based on the device status information; determine the thread pool occupancy ratio of the thread pool corresponding to the business operation tag based on the thread pool information; determine the message queue occupancy ratio of the message queue corresponding to the business operation tag based on the message queue information; determine the scheduling score of the business operation tag based on the device failure rate, the thread pool occupancy ratio of the thread pool corresponding to the business operation tag, the message queue occupancy ratio of the message queue corresponding to the business operation tag, and the intent matching score of the business operation tag; and determine, based on the scheduling score of the business operation tag, business operation tags that meet scheduling conditions to be scheduled from at least one of the business operation tags to be scheduled; wherein, the scheduling score of the business operation tag is calculated using the following scheduling scoring function: ； in, Indicates the first The scheduling score for each business operation tag. Indicates the first The intent matching score for each business operation tag. Indicates the equipment failure rate. Representing the There are 1 target devices in a fault state, where m represents the total number of target devices. This indicates the thread pool occupancy rate of the thread pool corresponding to the business operation tag. This indicates the percentage of message queue occupancy corresponding to the business operation tag. The preset message queue load threshold, , , The preset control parameters control the sensitivity of fault penalties, thread load impact, and super-queue penalties respectively. A task chain construction module is used to construct a target task chain based on preset business dependencies, device status information, and the business operation tag to be scheduled. The target task chain includes at least one task node, and each task node corresponds to the tag binding information and device binding information of the business operation tag to be scheduled. Specifically, it is used to generate at least one candidate task chain based on preset business dependencies, device status information, and the business operation tag to be scheduled. For each candidate task chain, a stability score is determined based on the scheduling score of the business operation tag to be scheduled, the number of asymmetric dependencies, and the number of device resource conflicts in the candidate task chain. Based on the stability score of at least one candidate task chain, a target task chain is determined from the at least one candidate task chain. The optimization module is used to optimize the task saturation based on the target task chain to obtain a set of tasks to be executed; The processing module is used to select a channel for each task to be executed in the set of tasks to be executed based on the message queue channel load information included in the business platform resource information, and to asynchronously deliver the task for business processing based on the selected channel.

5. The apparatus according to claim 4, characterized in that, The optimization module is specifically used to register tasks based on each task node in the target task chain to obtain an initial task set; the initial task set contains tasks corresponding to each task node; a saturation score is determined based on the number of dependent tasks and task weights corresponding to each task in the initial task set; the saturation score is negatively correlated with the number of dependent tasks; if the saturation score is lower than the saturation score threshold, the target task is deleted from the initial task set, and the process of determining the saturation score based on the number of dependent tasks and task weights corresponding to each task in the initial task set is returned, until the saturation score is not lower than the saturation score threshold, thus obtaining a set of tasks to be executed.

6. The apparatus according to claim 4, characterized in that, The message queue channel load information includes the number of queued tasks and the average waiting time; the processing module is specifically used to determine the target message queue channel from the message queue channels corresponding to the task to be executed for each task in the set of tasks to be executed, based on the number of queued tasks and the average waiting time of the message queue channel corresponding to the task to be executed, and the task priority of the task to be executed. The pending task is processed by asynchronous delivery based on the target message queue channel.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 3.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 3.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 3.

Images