Concurrent processing method, system and equipment for requests with sequence requirements and medium

Abstract

The invention relates to the technical field of concurrent processing, in particular to a concurrent processing method and system for requests with sequence requirements, equipment and a medium. The method comprises the following steps: receiving a plurality of request tasks with a sequence requirement, grouping the tasks according to a preset condition to form a plurality of request task groups, then adding all the request task groups into a to-be-processed pool, creating a unique group identifier, recording final modification time, forming a group list, and sending the request task groups to the to-be-processed pool. Whether idle slots exist in the concurrent slots or not is continuously checked, when the idle slots are found, the target request task group with the earliest modification time is selected from the group list, the first request task is taken out to serve as the target request task, meanwhile, the target request tasks distributed to the different concurrent slots are processed, and efficient concurrency is achieved; when a certain target request task is executed, releasing the concurrence slot occupied by the target request task; the contradiction between sequence requirements and concurrent processing is solved, balanced utilization of system resources is realized, and the processing efficiency is improved.

Description

Technical Field

[0001] The present application relates to the technical field of concurrent processing, and in particular to a concurrent processing method, system, device and medium for requests with sequential requirements. Background Art

[0002] In modern communication systems, processing a large number of request tasks with sequential requirements is a common challenge. These tasks may include complex processes such as user activation and account opening, call bill risk control, etc., which require efficient concurrency while ensuring the processing order to improve system response speed, reduce user waiting time, and handle potential risk events in a timely manner.

[0003] Existing processing systems usually use simple queue management or basic parallel processing techniques, such as using a first-in-first-out queue to store tasks to be processed, or using a fixed number of processing units to process multiple tasks simultaneously.

[0004] Existing technologies have difficulty in achieving efficient resource utilization while ensuring the correctness of task processing when processing complex tasks. In particular, when facing dynamically changing task flows, it is difficult for the system to adjust the processing strategy in a timely manner, resulting in unbalanced resource allocation and low processing efficiency; at the same time, for tasks that run for a long time, it is easy to cause unbalanced resource occupancy, affecting the overall performance of the system. This situation needs to be further improved. Summary of the invention

[0005] In order to solve the existing problems of unbalanced resource allocation and low processing efficiency, the present application provides a concurrent processing method, system, device and medium for requests with sequential requirements, which adopts the following technical solutions: In a first aspect, the present application provides a method for concurrently processing requests with sequence requirements, comprising the following steps: receiving a plurality of request tasks with sequence requirements, and grouping the request tasks according to preset conditions to obtain a plurality of request task groups; Adding the request task group to a pending pool; Create a group identifier for each of the request task groups, and record the last modification time to obtain a group list; Obtaining a target request task, and assigning the target request task to a pre-set concurrent slot; concurrently processing the target request tasks assigned to the concurrent slots; When the target request task is executed, releasing the slot occupied by the target request task; When obtaining a target request task and assigning the target request task to a pre-set concurrent slot, the following operations are repeatedly performed: Check if there is an idle slot in the concurrent slot; If there is a free slot, selecting the target request task group with the earliest modification time from the group list; In the to-be-processed pool, taking out the first request task in the target request task group as the target request task; Allocating the target request task to an idle slot; The to-be-processed pool and the group list are updated according to the group identifier corresponding to the target request task group, including updating the modification time of the group list.

[0006] By adopting the above technical solution, the traditional method often finds it difficult to achieve efficient concurrency while ensuring the order of task processing, resulting in poor system performance and inability to meet the growing business needs; for example, in the user call bill risk control scenario, it is necessary to quickly process a large number of call bills to prevent risks, and to ensure that the call bills of the same user are processed in chronological order to accurately evaluate user behavior; this application realizes the organic combination of sequential execution within a group and concurrent processing between groups by grouping request tasks and introducing concurrent slots; specifically, it includes receiving multiple request tasks with sequential requirements, and intelligently grouping these tasks according to preset conditions to form multiple request task groups, and then adding all request task groups to a unified In the pending pool, a unique group identifier is created for each request task group, and the last modification time is recorded to form a dynamically maintained group list. The pre-set concurrent slots are continuously checked for free slots. When a free slot is found, the target request task group with the earliest modification time is selected from the group list, and the first request task is taken out as the target request task. The system processes the target request tasks assigned to different concurrent slots at the same time to achieve efficient concurrency. When a target request task is executed, the concurrent slot it occupies is immediately released. This not only efficiently solves the contradiction between sequential requirements and concurrent processing, but also achieves balanced utilization of system resources through a dynamic update mechanism, greatly improving processing efficiency.

[0007] Optionally, the request tasks are grouped according to preset conditions to obtain multiple request task groups, which specifically includes the following steps: Get the task attributes of each requested task; classifying the requested tasks according to the task attributes; Grouping request tasks with the same task attributes into the same request task group; Allocate a unique group identifier to each of the request task groups; The creation time of each of the request task groups is recorded as the initial last modification time.

[0008] By adopting the above technical solution, traditional methods often adopt extensive classification strategies or completely ignore the correlation between tasks, resulting in the system being unable to process different types of tasks in a targeted manner, affecting the overall processing efficiency and accuracy; for example, in the user call bill risk control scenario, the system needs to process call bills of different users and different communication types at the same time, and consider the user's credit rating and historical behavior. Simply processing all call bills in chronological order cannot ensure that the call bills of the same user are analyzed in the correct order, thereby affecting the timeliness and accuracy of risk control; the present application first obtains the task attributes of each call bill request task, such as user ID, communication type and other key information. According to the extracted task attributes, the system uses a preset classification algorithm to classify the call bill request tasks, and automatically classifies the call bill request tasks with the same task attributes into the same request task group, ensuring that the call bills of the same user are centrally managed and arranged in chronological order, and then assigns a unique group identifier to each formed request task group and records the creation time of each request task group; the refined classification of call bill request tasks is realized, so that the system can ensure the processing order of the call bills of the same user, greatly improving the efficiency and accuracy of risk control.

[0009] Optionally, the method further comprises the following steps: Record the usage status of each concurrent slot in the preset slot mapping table; When the target request task is allocated to a free slot, the state of the corresponding slot is updated to occupied in the slot mapping table, and the task identifier and group identifier corresponding to the request task occupying the corresponding slot are recorded.

[0010] By adopting the above-mentioned technical scheme, it is difficult for traditional concurrent systems to accurately grasp the system resource usage status and task execution status in real time, resulting in inefficient resource utilization and inability to respond to the processing needs of high-priority tasks in a timely manner. For example, in the user call bill risk control scenario, the system may not be able to quickly locate and adjust the high-risk user call bill tasks being processed, thereby delaying the timeliness of risk control; the present application presets a slot mapping table to record the detailed usage status of each concurrent slot. When the target request task is assigned to an idle slot, the system immediately updates the status of the corresponding slot in the slot mapping table to occupied, and records the task identifier and group identifier corresponding to the request task occupying the slot, establishes a clear association between the slot and the task, and can quickly locate and adjust the execution status of a specific task, thereby realizing task priority adjustment in emergency situations.

[0011] Optionally, the method further comprises the following steps: When the target request task is assigned to a concurrent slot, the target request task is added to a preset processing pool; The slot identifier, group identifier and task identifier of the target request task are recorded in the processing pool.

[0012] By adopting the above technical solution, traditional systems often lack a unified management mechanism for tasks being processed, which makes it difficult for the system to quickly respond to abnormal situations, adjust task priorities or achieve accurate load balancing; when the target request task is assigned to a concurrent slot, the present application adds the target request task to a preset processing pool, and then records the slot identifier, group identifier and task identifier of the target request task; comprehensive and real-time management of tasks being processed is achieved, which greatly improves the system's task management capabilities and response speed. The system can quickly locate and adjust tasks of specific users or specific types, and better achieve task priority adjustments in emergency situations.

[0013] Optionally, the method further comprises the following steps: Based on the group identifier of the request task group, acquiring historical processing data of the request task group, the historical processing data including processing frequency, abnormality rate and user complaint rate; Based on the historical processing data and the preset grouping monitoring level, determining the monitoring level of the requested task group, wherein the monitoring level includes routine monitoring, key monitoring and emergency processing; According to the monitoring level, adjusting the processing priority factor corresponding to the request task group; When acquiring the target request task, a comprehensive priority is calculated based on the modification time corresponding to the target request task group and the priority factor, and the target request task is acquired based on the comprehensive priority.

[0014] By adopting the above technical solutions, traditional systems often adopt static priority strategies or simple first-in-first-out principles, and are unable to flexibly adjust the processing order according to the historical performance and real-time status of the tasks, resulting in the system being unable to effectively respond to complex and changing business needs; for example, in the user call risk control scenario, some user groups may require faster processing due to recent abnormal behavior, but the existing system may not be able to identify and adjust the priority of these tasks in a timely manner, thereby affecting the timeliness and effectiveness of risk control; this application obtains the historical processing data of the group based on the group identifier of the request task group, including key indicators such as processing frequency, exception rate and user complaint rate, among which the processing frequency reflects the activity level and system load of a certain type of task or a certain user group, the exception rate indicates the proportion of abnormal situations occurring during the processing, and the user complaint rate indicates the proportion of abnormal situations occurring during the processing. The complaint rate directly reflects the user's satisfaction with the service quality and possible problems. The three indicators complement each other and jointly construct a complete task importance evaluation system from the three key dimensions of system load, system health and user experience; based on the acquired historical data and the preset grouping monitoring level standard, the system determines the monitoring level of the request task group and divides it into one of the three levels: regular monitoring, key monitoring or emergency processing; based on the determined monitoring level, the system adjusts the processing priority factor corresponding to the request task group accordingly, and then when obtaining the target request task, the system comprehensively considers the modification time and priority factor of the task group, calculates a comprehensive priority indicator, and thus obtains the target request task; it can more accurately judge the importance and urgency of the task, and thus make more reasonable resource allocation decisions.

[0015] Optionally, the method further comprises the following steps: When the request task group is determined to be at a regular monitoring level, obtaining the request frequency of the request task group, and if the request frequency is greater than or equal to a preset regular frequency threshold, raising the monitoring level of the request task group to a key monitoring level; When the request task group is determined to be at the key monitoring level, the current abnormality rate of the request task group is calculated, and the current abnormality rate is compared with the historical abnormality rate of the request task group. When the current abnormality rate exceeds the historical abnormality rate and the difference reaches a preset first abnormality rate growth threshold, a risk warning mechanism is triggered; When the current abnormality rate exceeds the historical abnormality rate, and the difference reaches a preset second abnormality rate growth threshold, shortening the processing timeout of the request task group to a preset key monitoring timeout, and increasing the secondary verification frequency of the processing result, wherein the second abnormality rate threshold is greater than the first abnormality rate threshold; When the request task group is judged to be at an emergency processing level, the currently idle concurrent slot is immediately allocated, and the processing timeout of the request task group is set to the preset minimum processing time; when the processing time exceeds a preset percentage of the preset minimum processing time, an alarm mechanism is automatically triggered.

[0016] By adopting the above technical solutions, traditional systems often adopt static monitoring strategies, which are unable to adjust processing priorities and resource allocation in time according to real-time situations, resulting in slow response when facing sudden abnormalities or high-risk situations, affecting the security of the system and user experience; this application dynamically upgrades the task group of the conventional monitoring level to the key monitoring level according to the request frequency. For the task group of the key monitoring level, by comparing the current abnormality rate with the historical abnormality rate, a risk warning is triggered when the abnormality rate increases significantly, and early risk identification is achieved. When the abnormality rate further increases, the processing timeout time is automatically shortened, and the result verification frequency is increased to improve the processing quality and accuracy; for the emergency level task group, the system immediately allocates resources, sets the shortest processing time, and automatically triggers an alarm when the timeout expires to ensure that the problem is handled immediately; it greatly improves the system's response speed and sensitivity to abnormal situations, and can detect and handle problems in time before they expand. In addition, by dynamically adjusting the monitoring level and processing strategy, optimal allocation of resources is achieved, and overall processing efficiency is improved.

[0017] In a second aspect, the present application provides a concurrent processing system for requests with sequential requirements, comprising: A request task grouping module is used to receive multiple request tasks with sequence requirements and group the request tasks according to preset conditions to obtain multiple request task groups; A task group adding module, used for adding the requested task group to a pending pool; A group list creation module is used to create a group identifier for each of the request task groups and record the last modification time to obtain a group list; A request task allocation module is used to obtain a target request task and allocate the target request task to a pre-set concurrent slot; A task concurrent processing module, used for concurrently processing target request tasks assigned to the concurrent slots; A task occupied slot releasing module, which releases the slot occupied by the target request task when the target request task is executed; Wherein, the request task allocation module includes: A free slot checking unit, used for checking whether there is a free slot in the concurrent slot; a target group selection unit, configured to select a target request task group with the earliest modification time from the group list if there is a free slot; A target task acquisition unit, configured to take out the first request task in the target request task group from the to-be-processed pool as the target request task; A task allocation unit, used for allocating the target request task to an idle slot; A data updating unit is used to update the pending pool and the group list according to the group identifier corresponding to the target request task group, including updating the modification time of the group list.

[0018] In a third aspect, the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned method for concurrent processing of requests with sequential requirements when executing the computer program.

[0019] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-mentioned method for concurrent processing of requests with sequential requirements.

[0020] In summary, the present application includes at least one of the following beneficial technical effects: 1. Since traditional methods often find it difficult to achieve efficient concurrency while ensuring the order of task processing, the system performance is low and cannot meet the growing business needs; for example, in the user call bill risk control scenario, it is necessary to quickly process a large number of call bills to prevent risks, and to ensure that the call bills of the same user are processed in chronological order to accurately evaluate user behavior; this application realizes the organic combination of sequential execution within the group and concurrent processing between groups by grouping request tasks and introducing concurrent slots; specifically, it includes receiving multiple request tasks with sequential requirements, and intelligently grouping these tasks according to preset conditions to form multiple request task groups, and then adding all request task groups to a unified to-be-processed In the pool, a unique group identifier is created for each request task group, and the last modification time is recorded to form a dynamically maintained group list. The system continuously checks whether there are free slots in the pre-set concurrent slots. When a free slot is found, the target request task group with the earliest modification time is selected from the group list, and the first request task is taken out as the target request task. The system processes the target request tasks assigned to different concurrent slots at the same time to achieve efficient concurrency. When a target request task is executed, the concurrent slot it occupies is immediately released. This not only efficiently solves the contradiction between sequential requirements and concurrent processing, but also achieves balanced utilization of system resources through a dynamic update mechanism, greatly improving processing efficiency. 2. It is difficult for traditional concurrent systems to accurately grasp the system resource usage and task execution status in real time, resulting in inefficient resource utilization and inability to respond to high-priority task processing requirements in a timely manner. For example, in the user call bill risk control scenario, the system may not be able to quickly locate and adjust the high-risk user call bill tasks being processed, thereby delaying the timeliness of risk control; this application presets a slot mapping table to record the detailed usage status of each concurrent slot. When the target request task is assigned to an idle slot, the system immediately updates the status of the corresponding slot in the slot mapping table to occupied, and records the task identifier and group identifier corresponding to the request task occupying the slot, establishes a clear association between the slot and the task, and can quickly locate and adjust the execution status of a specific task, thereby realizing task priority adjustment in emergency situations; 3. This application obtains historical processing data of the request task group based on the group identification of the request task group, including key indicators such as processing frequency, exception rate and user complaint rate, among which the processing frequency reflects the activity level and system load of a certain type of task or a certain user group, the exception rate indicates the proportion of abnormal situations occurring during the processing, and the user complaint rate directly reflects the user's satisfaction with the service quality and possible problems. The three indicators complement each other and jointly construct a complete task importance evaluation system from the three key dimensions of system load, system health and user experience; based on the acquired historical data and the preset group division monitoring level standard, the system determines the monitoring level of the request task group and divides it into one of the three levels of routine monitoring, key monitoring or emergency processing; based on the determined monitoring level, the system adjusts the processing priority factor corresponding to the request task group accordingly, and then when obtaining the target request task, the system comprehensively considers the modification time and priority factor of the task group, calculates a comprehensive priority indicator, and thus obtains the target request task; it can more accurately judge the importance and urgency of the task, and thus make more reasonable resource allocation decisions. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a flowchart of a method for concurrently processing requests with sequence requirements according to an embodiment of the present application; Figure 2 It is a flowchart of step S110 in a method for concurrently processing requests with sequence requirements in an embodiment of the present application; Figure 3 It is a flowchart of recording slot usage status in a concurrent processing method of requests with sequence requirements in an embodiment of the present application; Figure 4 It is a flowchart of optimizing the priority of request tasks in a concurrent processing method of requests with sequence requirements in an embodiment of the present application; Figure 5It is a flowchart of hierarchical processing in a concurrent processing method of requests with sequence requirements in an embodiment of the present application; Figure 6 It is a module schematic diagram of a concurrent processing system of requests with sequence requirements according to an embodiment of the present application; Figure 7 It is a diagram of the internal structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to be used as limitations to the present application. As used in the specification and appended claims of the present application, the singular expressions "one", "a kind of", "said", "above", "the" and "this" are intended to also include plural expressions, unless there is a clear indication to the contrary in the context. It should also be understood that the term "and / or" used in the present application refers to any or all possible combinations comprising one or more listed items.

[0023] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as suggesting or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features, and in the description of the embodiments of the present application, unless otherwise specified, "plurality" means two or more.

[0024] The embodiments of the present application are further described in detail below in conjunction with the drawings in the specification.

[0025] In a first aspect, the present application provides a method for concurrently processing requests with sequential requirements, referring to Figure 1 , including the following steps: S110, receiving a plurality of request tasks with sequence requirements, and grouping the request tasks according to preset conditions to obtain a plurality of request task groups.

[0026] In this embodiment, the system receives multiple request tasks that need to be processed in a specific order. These tasks may come from the same user, the same business process, or have other common characteristics, and need to be processed in a certain order to ensure the correctness and continuity of the business.

[0027] Specifically, the system classifies the received request tasks according to the preset grouping conditions. For example, in the user call bill risk control scenario, the user's mobile phone number is grouped to ensure that the call bills of the same user are processed in chronological order. For another example, in the user activation account opening process, the user ID can be grouped to ensure that steps such as user information review, core system account opening, and resource accounting are executed in the correct order.

[0028] S120: Add the requested task groups to a pool to be processed.

[0029] In this embodiment, the system adds the request task group obtained in step S110 to a data structure called a "pending pool". The pending pool is used as an intermediate storage area to temporarily store task groups that have not yet been processed for subsequent scheduling and processing.

[0030] Specifically, the pending pool can be implemented using an appropriate data structure, such as a hash table or a priority queue. Each group in the pending pool can contain the unique identifier of the group (such as GroupID) and all request tasks in the group. For example, for a call record risk control scenario, an entry in the pending pool may be: {GroupID: "13800138000", Tasks: [Task1, Task2, Task3]}, where Task1, Task2, and Task3 are specific call record processing tasks arranged in the order of receipt.

[0031] S130: Create a group identifier for each requested task group, and record the last modification time to obtain a group list.

[0032] In this embodiment, the system assigns a unique group identifier (GroupID) to each request task group and records the last modification time of the group. This information is integrated into a group list.

[0033] Specifically, the group list can be implemented as a data structure sorted by last modification time, such as an ordered map or a priority queue. Each entry contains a group ID and a last modification time, for example: {GroupID1:timestamp1, GroupID2:timestamp2, ...}. The last modification time is updated when a new task is added to the group or a task is taken out of the group for processing. This design allows the system to prioritize groups that have not been updated for a long time to ensure fairness and avoid some groups being shelved for a long time.

[0034] S140: Obtain target request tasks, and assign the target request tasks to pre-set concurrent slots.

[0035] The system selects the target request task from the pending pool and assigns it to the pre-set concurrent processing slot. The concurrent slot represents the number of tasks that the system can process simultaneously. By reasonably assigning tasks to concurrent slots, parallel processing of tasks can be achieved, improving the overall processing efficiency of the system.

[0036] Specifically, when step S140 is executed, the following sub-steps are repeatedly executed: check whether there is a free slot in the concurrent slot; if there is a free slot, select the target request task group with the earliest modification time from the group list; in the pending pool, take out the first request task in the target request task group as the target request task; assign the target request task to the free slot; update the pending pool and the group list according to the group identifier corresponding to the target request task group, including updating the modification time of the group list.

[0037] In this embodiment, the system first determines whether the group list GroupList is empty. If it is empty, it is skipped. If it is not empty, the system obtains the first group identifier GroupID in GroupList and checks whether the GroupID already exists in the concurrent slot SlotMap. If it does not exist, proceed to the next step; if it exists, it means that there is a task being processed in this group, and the system will continue to check the next GroupID; if the GroupID is not in the SlotMap, the system will obtain the first request task RJobID of the group corresponding to the GroupID from the waiting pool WaitingPool, and the system will create a request handle CurlHandle for this RJobID, and assign a unique sub-request handle number CurlHandleID, and add this CurlHandle to the batch session to prepare for subsequent concurrent execution. The system will add the combined information of SlotID, GroupID and RJobID to the processing request pool, i.e. the preset processing pool ProcessingPool, with CurlHandleID as the key, to track the tasks being processed, delete the allocated RJobID from the WaitingPool, indicating that the task has entered the processing stage, update the last modification time of the corresponding GroupID in the GroupList, and reorder the GroupList to ensure fair scheduling.

[0038] Furthermore, in SlotMap, the system associates the selected SlotID with the assigned GroupID and marks the slot as occupied. After completing the above steps, the system checks whether there are any free slots and pending tasks. If there are, the above process is repeated; if the slot is full or the task has been assigned, the execution phase is entered.

[0039] S150 , concurrently processing the target request tasks assigned to the concurrent slots.

[0040] In this embodiment, during the execution phase, the system processes the target request tasks assigned to the concurrent slots in parallel.

[0041] Specifically, the system assigns an independent processing thread or process to each concurrent slot. Each processing unit is responsible for executing the target request task assigned to it, such as calling the corresponding API, executing specific business logic, etc. During the processing, the system needs to ensure that tasks in the same group are not processed at the same time to maintain the order requirements of task execution. At the same time, the system also needs to monitor the execution status of each task so that subsequent processing can be carried out in a timely manner after the task is completed.

[0042] S160. When the target request task is executed, the slot occupied by the target request task is released.

[0043] In this embodiment, when a target request task is completed, the system will release the concurrent slot occupied by the task so that it can be used to process new tasks.

[0044] Specifically, the system will first obtain the content returned by the request from the batch processing pool according to the package. Then, the system will obtain the information matching the corresponding task in the ProcessingPool (SlotID, GroupID, RJobID). Next, the system will remove and process the sub-request handle in the pool session, and clean up the data of the SlotID slot. Subsequently, the system will check whether there are any tasks in the group GroupID in the WaitingPool. If there are still tasks, the system will delete the record of GroupID in GroupList, indicating that the processing of the group has ended. If there are still tasks to be processed in the group in the WaitingPool, the system will continue to process the next task. If there are no more tasks in the group in the WaitingPool, the system will delete the handle record in the ProcessingPool and release the corresponding concurrent slot. Finally, the system will enter the home page, indicating that the processing cycle of the task has been completed and the release is complete.

[0045] In one embodiment, referring to Figure 2 In step S110, the request tasks are grouped according to preset conditions to obtain multiple request task groups, which specifically includes the following steps: S111. Obtain task attributes of each requested task.

[0046] In this embodiment, the system obtains the task attributes of each request task. The selection of task attributes depends on the specific application scenario and business requirements, and can be the inherent characteristics of the request task or the attributes derived from the business logic.

[0047] Specifically, the system obtains task attributes by parsing the metadata of the requested task or querying the relevant database. For example, in the call bill risk control scenario, the system will extract the user's mobile phone number as a task attribute. For the scenario of user activation and account opening, the system may extract the user's ID number or other unique identifier as a task attribute.

[0048] S112: Classify the requested tasks according to task attributes.

[0049] In this embodiment, the system uses task attributes to classify request tasks, and classifies request tasks with similar attributes or that need to be processed in a specific order together.

[0050] For example, in a call bill risk control scenario, the system may use the hash value of the mobile phone number as the classification basis to ensure that requests from the same mobile phone number are classified into the same category. For more complex scenarios, the system will consider multiple attributes, such as user level, geographic location, etc., and use a multi-dimensional classification algorithm to determine the category of the request task.

[0051] S113. Classify the request tasks with the same task attributes into the same request task group.

[0052] In this embodiment, the system formally classifies the request tasks classified in S112 into corresponding request task groups. A data structure such as a hash table can be created to store these groups. Each group can contain a request task queue to ensure that tasks within the same group are processed in a specific order (such as first-in-first-out). For example, in a user activation account opening scenario, the system may classify all related request tasks of the same user (such as information submission, review, account opening, notification, etc.) into the same group to ensure that these tasks are executed in the correct order.

[0053] S114. Allocate a unique group identifier to each request task group.

[0054] In this embodiment, the system assigns a unique identifier to each request task group created in S113. These unique identifiers can be generated using an increasing integer, a UUID, or a hash value based on task attributes. For example, in a call bill risk control scenario, the system may use the "GROUP_" prefix plus the hash value of the mobile phone number to create a group identifier.

[0055] S115. Record the creation time of each request task group as the initial last modification time.

[0056] In one embodiment, referring to Figure 3 , the method further comprises the following steps: S310. Record the usage status of each concurrent slot in a preset slot mapping table.

[0057] In this embodiment, the system designs a slot mapping table for real-time recording and managing the usage status of each concurrent slot. The mapping table records whether the slot is occupied.

[0058] Specifically, the slot mapping table can be designed as a key-value pair structure, where the key is the unique identifier of the slot (such as SlotID), and the value is an object or structure containing multiple fields. This object may include the following information: usage status (such as "free" or "occupied"), occupancy time, last update time, etc.

[0059] S320. When the target request task is allocated to the free slot, the status of the corresponding slot is updated to occupied in the slot mapping table, and the task identifier and group identifier corresponding to the request task occupying the corresponding slot are recorded.

[0060] In this embodiment, when the system allocates the target request task to the free slot, the status information of the corresponding slot in the slot mapping table is immediately updated.

[0061] Specifically, the update process may include changing the slot status from "free" to "occupied"; recording the task ID (TaskID) that occupies the slot; this ID can be a unique ID generated by the system to track the task throughout the processing process; recording the group ID (GroupID) to which the task belongs; and updating the last modified timestamp of the slot. Some additional metadata may also be recorded, such as the priority of the task, the estimated execution time, etc.

[0062] Furthermore, when the target request task is assigned to a concurrent slot, the target request task is added to a preset processing pool, and the slot identifier of the target request task is recorded in the processing pool, indicating the specific slot, group identifier and task identifier currently occupied by the task.

[0063] In one embodiment, referring to Figure 4 , the method further comprises the following steps: S410 . Based on the group identifier of the request task group, obtain historical processing data of the request task group, where the historical processing data includes processing frequency, abnormality rate, and user complaint rate.

[0064] In this embodiment, the system introduces a dynamic monitoring mechanism based on historical data analysis, which provides data support for subsequent monitoring level judgment and priority adjustment by obtaining historical processing data of request task groups.

[0065] Specifically, take a user call record risk control system of a large telecom operator as an example. The system needs to process a large number of user call records, identify potential fraud, and protect the interests of users and operators. The system divides users into multiple groups based on their call behavior characteristics and risk levels. According to the group identifier of the requested task group, the historical processing data of the group is extracted from the preset data storage system. The historical processing data includes key indicators such as processing frequency, abnormality rate, and user complaint rate. Among them, the processing frequency reflects the activity level and system load of a certain type of task or a user group, the abnormality rate indicates the proportion of abnormal situations in the processing process, and the user complaint rate directly reflects the user's satisfaction with the service quality and possible problems. The three indicators complement each other and jointly construct a complete task importance evaluation system from the three key dimensions of system load, system health, and user experience. In call record risk control, the system load can understand the call mode and system resource requirements of different user groups. The processing frequency of the user group can be obtained by querying historical data, such as the average daily call processing volume of each user group in the past 30 days. A high processing frequency may mean that the user group needs more system resources or may have abnormal call behavior. The abnormal rate can indicate the proportion of calls marked as suspicious or high-risk by the system, reflecting the health of the system and potential risks. The user complaint rate can be understood as the proportion of complaints received by the user number, which is usually related to bad behaviors such as harassing calls and fraud, and requires timely risk control.

[0066] S420: Based on historical processing data and preset grouping monitoring levels, determine the monitoring level of the requested task group, where the monitoring levels include routine monitoring, key monitoring, and emergency processing.

[0067] In this embodiment, the system adopts a multi-level monitoring mechanism, which determines the appropriate monitoring level for each request task group by analyzing historical processing data and comparing it with preset thresholds, including routine monitoring, key monitoring and emergency processing.

[0068] Specifically, the system collects historical data within a preset time period, smoothes outliers, removes the influence of extreme data on judgment, and then normalizes the three indicators of processing frequency, abnormality rate, and user complaint rate. Based on the mean and standard deviation of historical data, the dynamic thresholds of each indicator are calculated, among which the processing frequency threshold is dynamically adjusted with the time period, and the abnormality rate and user complaint rate thresholds are adjusted according to seasonal characteristics (such as holidays). Then, weights are assigned to the three indicators, and the degree of deviation of each indicator from the preset benchmark value is calculated to obtain the deviation score, and finally the weighted addition is obtained to obtain the comprehensive risk score. Different monitoring level demarcation thresholds are set based on the comprehensive risk score. When the comprehensive risk score does not exceed the first preset threshold, the monitoring level of the request task group is determined as regular monitoring. When the comprehensive risk score is greater than the first preset threshold but not greater than the second preset threshold, the monitoring level of the request task group is determined as key monitoring. When the comprehensive risk score is greater than the second preset threshold, the monitoring level of the request task group is determined as emergency processing.

[0069] Furthermore, in order to avoid the impact of frequent fluctuations in monitoring levels on the system, the system introduces a monitoring level adjustment buffer mechanism. The monitoring level upgrade is triggered only when the comprehensive risk score of the request task group reaches a higher level standard for multiple consecutive days. Similarly, the downgrade is triggered only when the comprehensive risk score of the request task group reaches a lower level standard. When the user complaint rate suddenly increases significantly, that is, the increase in the preset time period is greater than the preset threshold, the system activates the instant upgrade mechanism and adjusts the monitoring level in time to deal with sudden risks.

[0070] S430. Adjust the processing priority factor corresponding to the request task group according to the monitoring level.

[0071] Specifically, the system sets different basic priority scores according to the monitoring level of the request task group, wherein the basic score of the conventional monitoring level is a first preset value, the basic score of the key monitoring level is a second preset value, and the basic score of the emergency processing level is a third preset value, and the first preset value is less than the second preset value and less than the third preset value. Based on the basic score, the system first calculates the time decay factor of the task, and uses an exponential decay function to calculate based on the time difference between the modification time of the task and the current time, wherein the time decay factor of the task is determined by the larger value of the exponential decay function and the minimum decay threshold, and the difference between the current time and the task modification time is used as the independent variable, and the decay rate coefficient is used as a parameter for exponential calculation, so that the newly modified task obtains a higher time decay factor, and as time goes by, the time decay factor will gradually decrease, but will not be lower than the minimum decay threshold, so as to ensure that long-term tasks can still get processing opportunities. At the same time, the corresponding business weight coefficient is set according to the task type, and for tasks in special periods such as holidays, the corresponding business weight of the preset period is increased. At the same time, by counting the task backlog of each processing queue, the balance coefficient of task allocation is calculated, and the corresponding priority is reduced for tasks in the processing queue with a higher load. The final processing priority factor is obtained by multiplying the basic score, time decay factor, business weight coefficient and load balancing factor. It is understandable that the system will set upper and lower limits of the priority factor to prevent the priority from being too high or too low due to extreme situations.

[0072] S440. When acquiring the target request task, calculate the comprehensive priority based on the modification time and priority factor corresponding to the target request task group, and acquire the target request task based on the comprehensive priority.

[0073] In this embodiment, the system adjusts the processing priority factor of the request task group according to the monitoring level determined in the previous step. Then, when obtaining the target request task, the system comprehensively considers the modification time and priority factor of the task group, calculates a comprehensive priority index, and thus obtains the target request task; it can more accurately judge the importance and urgency of the task, and thus make more reasonable resource allocation decisions.

[0074] Traditional systems often use static monitoring strategies and cannot adjust processing priorities and resource allocation in a timely manner according to real-time situations, resulting in slow response when facing sudden abnormalities or high-risk situations, affecting system security and user experience. Figure 5 , the method further comprises the following steps: S510: When the request task group is determined to be at a regular monitoring level, obtain the request frequency of the request task group. If the request frequency is greater than or equal to a preset regular frequency threshold, raise the monitoring level of the request task group to a key monitoring level.

[0075] In this embodiment, the system optimizes resource allocation and risk management by dynamically adjusting the monitoring level. By setting the request frequency threshold, the system can promptly identify user groups that may have abnormal behavior or high risk.

[0076] Specifically, the system sets a sliding time window to calculate the request frequency. For example, for a general user group, if its average request frequency in the last hour exceeds the threshold of 10 times per minute, the system will upgrade it to the key monitoring level. This mechanism can effectively capture sudden abnormal behaviors, such as batch automatic calls and other possible fraud or harassment behaviors.

[0077] S520. When the request task group is determined to be at the key monitoring level, the current abnormality rate of the request task group is calculated, and the current abnormality rate is compared with the historical abnormality rate of the request task group. When the current abnormality rate exceeds the historical abnormality rate and the difference reaches the preset first abnormality rate growth threshold, the risk warning mechanism is triggered.

[0078] In this embodiment, the system identifies possible abnormal situations by comparing the current abnormal rate with the historical abnormal rate. This method takes into account that different user groups may have different baseline abnormal rates, and through relative comparison rather than absolute thresholds, the real abnormal situation can be captured more accurately.

[0079] Specifically, the system calculates the abnormality rate of the last 24 hours as the current abnormality rate and compares it with the average abnormality rate of the past 30 days. For example, if the historical abnormality rate of a user group is 5% and the current abnormality rate is 8%, the difference is 3%. Assuming that the first abnormality rate growth threshold is set to 2%, the system will trigger the risk warning mechanism. This mechanism can detect sudden increases in abnormal situations in a timely manner, allowing operators to quickly take corresponding measures.

[0080] S530. When the current abnormality rate exceeds the historical abnormality rate and the difference reaches the preset second abnormality rate growth threshold, the processing timeout time of the request task group is shortened to the preset key monitoring timeout time, and the secondary verification frequency of the processing results is increased, where the second abnormality rate threshold is greater than the first abnormality rate threshold.

[0081] In this embodiment, the system sets two levels of abnormal rate growth thresholds. When the abnormal situation deteriorates further, the system will take more stringent measures, including shortening the processing timeout and increasing the verification frequency, to handle possible high-risk situations more quickly and strictly.

[0082] Specifically, assuming that the second anomaly rate growth threshold is set to 5%, when the current anomaly rate of a user group is 5% or more higher than the historical anomaly rate, the system will shorten the processing timeout of the group from the original 30 seconds to 15 seconds, and increase the secondary verification frequency from once every 10 processing verifications to once every 5 processing verifications, thereby improving the accuracy of the system through more frequent verifications.

[0083] S540. When the request task group is judged to be at an emergency processing level, the currently idle concurrent slot is immediately allocated, and the processing timeout of the request task group is set to the preset minimum processing time; when the processing time exceeds the preset percentage of the preset minimum processing time, the alarm mechanism is automatically triggered.

[0084] In this embodiment, the system provides the highest priority resource allocation and the most stringent time control for emergency processing level tasks. By immediately allocating concurrent slots and setting the shortest processing time, the system ensures a rapid response to high-risk situations. At the same time, an automatic alarm mechanism based on processing time is set up to promptly notify relevant personnel when abnormal processing delays occur.

[0085] Specifically, the system sets the preset minimum processing time for urgent processing level tasks to 5 seconds, and the preset percentage to 80%. This means that if the processing time of an urgent task exceeds 4 seconds (80% of 5 seconds), the system will automatically trigger an alarm. This mechanism ensures that urgent tasks can be processed in a timely manner even under high load conditions, and quickly attracts attention when abnormal delays occur, thereby minimizing potential risks.

[0086] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0087] In the second aspect, the present application provides a concurrent processing system for requests with sequential requirements. The concurrent processing system for requests with sequential requirements of the present application is described below in conjunction with the above-mentioned concurrent processing method for requests with sequential requirements.

[0088] Reference Figure 6 , a concurrent processing system for requests with sequential requirements, comprising: A request task grouping module is used to receive multiple request tasks with sequence requirements and group the request tasks according to preset conditions to obtain multiple request task groups; A task group adding module is used to add request task groups to the pending pool; The group list creation module is used to create a group identifier for each request task group and record the last modification time to obtain a group list; The request task allocation module is used to obtain the target request task and allocate the target request task to the pre-set concurrent slot; The task concurrent processing module is used to concurrently process the target request tasks assigned to the concurrent slots; The task occupied slot release module releases the slot occupied by the target request task when the target request task is executed; Among them, the request task allocation module includes: A free slot checking unit, used for checking whether there is a free slot in the concurrent slot; a target group selection unit, configured to select a target request task group with the earliest modification time from the group list if there is an idle slot; A target task acquisition unit is used to take out the first request task in the target request task group from the pending pool as the target request task; A task allocation unit, used for allocating target request tasks to free slots; The data updating unit is used to update the pending pool and the group list according to the group identifier corresponding to the target request task group, including the modification time of updating the group list.

[0089] In one embodiment, the present application provides an electronic device, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown. The electronic device includes a processor, a memory and a network interface connected through a system bus. Among them, the processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the electronic device is used to store data. The network interface of the electronic device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a concurrent processing method of requests with sequential requirements is implemented.

[0090] Those skilled in the art will understand that Figure 7 The structure shown in the figure is merely a block diagram of a partial structure related to the scheme of the present application, and does not constitute a limitation on the electronic device to which the scheme of the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0091] In one embodiment, an electronic device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0092] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the above-mentioned computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), tape, floppy disk, flash memory or optical memory, etc. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0093] The above are all preferred embodiments of the present application, and the protection scope of the present application is not limited thereto. Therefore, any equivalent changes made according to the structure, shape, and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method for concurrently processing requests with sequential requirements, characterized in that: The steps include: Receiving multiple request tasks with sequence requirements, and grouping the request tasks according to preset conditions to obtain multiple request task groups; Adding the request task group to a pending pool; Create a group identifier for each of the request task groups, and record the last modification time to obtain a group list; Obtaining a target request task, and assigning the target request task to a pre-set concurrent slot; concurrently processing the target request tasks assigned to the concurrent slots; When the target request task is executed, releasing the slot occupied by the target request task; When obtaining a target request task and assigning the target request task to a pre-set concurrent slot, the following operations are repeatedly performed: Check if there is an idle slot in the concurrent slot; If there is a free slot, selecting the target request task group with the earliest modification time from the group list; In the to-be-processed pool, taking out the first request task in the target request task group as the target request task; Allocating the target request task to an idle slot; The to-be-processed pool and the group list are updated according to the group identifier corresponding to the target request task group, including updating the modification time of the group list.

2. The concurrent processing method according to claim 1, characterized in that: The request tasks are grouped according to preset conditions to obtain multiple request task groups, which specifically includes the following steps: Get the task attributes of each requested task; classifying the requested tasks according to the task attributes; Grouping request tasks with the same task attributes into the same request task group; Allocate a unique group identifier to each of the request task groups; The creation time of each of the request task groups is recorded as the initial last modification time.

3. The concurrent processing method according to claim 1, characterized in that: The method further comprises the steps of: Record the usage status of each concurrent slot in the preset slot mapping table; When the target request task is allocated to a free slot, the state of the corresponding slot is updated to occupied in the slot mapping table, and the task identifier and group identifier corresponding to the request task occupying the corresponding slot are recorded.

4. The concurrent processing method according to claim 3, characterized in that: The method further comprises the steps of: When the target request task is assigned to a concurrent slot, the target request task is added to a preset processing pool; The slot identifier, group identifier and task identifier of the target request task are recorded in the processing pool.

5. The concurrent processing method according to claim 3, characterized in that: The method further comprises the steps of: Based on the group identifier of the request task group, acquiring historical processing data of the request task group, the historical processing data including processing frequency, abnormality rate and user complaint rate; Based on the historical processing data and the preset grouping monitoring level, determining the monitoring level of the requested task group, wherein the monitoring level includes routine monitoring, key monitoring and emergency processing; According to the monitoring level, adjusting the processing priority factor corresponding to the request task group; When acquiring the target request task, a comprehensive priority is calculated based on the modification time corresponding to the target request task group and the priority factor, and the target request task is acquired based on the comprehensive priority.

6. The concurrent processing method according to claim 5, characterized in that: The method further comprises the steps of: When the request task group is determined to be at a regular monitoring level, obtaining the request frequency of the request task group, and if the request frequency is greater than or equal to a preset regular frequency threshold, raising the monitoring level of the request task group to a key monitoring level; When the request task group is determined to be at the key monitoring level, the current abnormality rate of the request task group is calculated, and the current abnormality rate is compared with the historical abnormality rate of the request task group. When the current abnormality rate exceeds the historical abnormality rate and the difference reaches a preset first abnormality rate growth threshold, a risk warning mechanism is triggered; When the current abnormality rate exceeds the historical abnormality rate, and the difference reaches a preset second abnormality rate growth threshold, shortening the processing timeout of the request task group to a preset key monitoring timeout, and increasing the secondary verification frequency of the processing result, wherein the second abnormality rate threshold is greater than the first abnormality rate threshold; When the request task group is determined to be at an emergency processing level, a currently idle concurrent slot is immediately allocated, and a processing timeout time of the request task group is set to a preset minimum processing time; When the processing time exceeds a preset percentage of the preset minimum processing time, an alarm mechanism is automatically triggered.

7. A concurrent processing system for requests with sequential requirements, characterized in that: include: A request task grouping module is used to receive multiple request tasks with sequence requirements and group the request tasks according to preset conditions to obtain multiple request task groups; A task group adding module, used for adding the requested task group to a pending pool; A group list creation module is used to create a group identifier for each of the request task groups and record the last modification time to obtain a group list; A request task allocation module is used to obtain a target request task and allocate the target request task to a pre-set concurrent slot; A task concurrent processing module, used for concurrently processing target request tasks assigned to the concurrent slots; A task occupied slot releasing module, which releases the slot occupied by the target request task when the target request task is executed; Wherein, the request task allocation module includes: A free slot checking unit, used for checking whether there is a free slot in the concurrent slot; a target group selection unit, configured to select a target request task group with the earliest modification time from the group list if there is a free slot; A target task acquisition unit, configured to take out the first request task in the target request task group from the to-be-processed pool as the target request task; A task allocation unit, used for allocating the target request task to an idle slot; A data updating unit is used to update the pending pool and the group list according to the group identifier corresponding to the target request task group, including the modification time of updating the group list.

8. An electronic device, characterized in that: The method comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the steps of the concurrent processing method for requests with sequential requirements described in any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the concurrent processing method for requests with sequential requirements described in any one of claims 1 to 6 are implemented.

Images