Concurrent processing method, system, device and medium for requests with sequential requirements

Abstract

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. The present application receives multiple request tasks with sequential requirements, and groups the tasks according to preset conditions to form multiple request task groups, then adds all request task groups to a pending pool, creates a unique group identifier, and records the last modification time to form a group list, continuously checks whether there are free slots in the concurrent slots, and when a free slot is found, selects the target request task group with the earliest modification time from the group list, takes out the first request task as the target request task, and 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 released; the contradiction between sequential requirements and concurrent processing is resolved, balanced utilization of system resources is achieved, and 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 request processing with sequential requirements. Background Art

[0002] In modern communications systems, processing large numbers of sequentially demanding requests is a common challenge. These tasks can include complex processes such as user account activation and bill risk management. Efficient concurrency is crucial while maintaining sequential processing order to improve system responsiveness, reduce user wait times, and promptly address potential risk events.

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

[0004] Existing technologies struggle to achieve efficient resource utilization while ensuring correct processing of complex tasks. Especially when faced with dynamically changing task flows, the system struggles to adjust processing strategies in a timely manner, leading to uneven resource allocation and low processing efficiency. Furthermore, long-running tasks can easily lead to uneven resource utilization, impacting overall system performance. This situation warrants further improvement. 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 method, system, device and medium for concurrent processing of requests with sequence requirements, which adopts the following technical solutions:

[0006] In a first aspect, the present application provides a method for concurrently processing requests with sequence requirements, comprising the following steps:

[0007] 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;

[0008] Adding the requested task groups to a pending pool;

[0009] Create a group identifier for each of the request task groups, and record the last modification time to obtain a group list;

[0010] Obtain target request tasks and assign the target request tasks to pre-set concurrent slots;

[0011] concurrently processing the target request tasks assigned to the concurrent slots;

[0012] When the target request task is completed, the slot occupied by the target request task is released;

[0013] When obtaining a target request task and assigning the target request task to a pre-set concurrent slot, the following operations are repeatedly performed:

[0014] Check if there is an idle slot in the concurrent slot;

[0015] If there is a free slot, selecting the target request task group with the earliest modification time from the group list;

[0016] In the pending pool, taking the first request task in the target request task group as the target request task;

[0017] Allocating the target request task to an idle slot;

[0018] The to-be-processed pool and the group list are updated according to the group identifier corresponding to the target request task group, including the modification time of updating the group list.

[0019] By adopting the above technical solutions, the traditional methods often find it difficult to achieve efficient concurrency while ensuring the order of task processing, resulting in poor system performance and the 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 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 completed, 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.

[0020] Optionally, the request tasks are grouped according to preset conditions to obtain multiple request task groups, which specifically includes the following steps:

[0021] Get the task attributes of each requested task;

[0022] classifying the requested tasks according to the task attributes;

[0023] Grouping request tasks with the same task attributes into the same request task group;

[0024] Assigning a unique group identifier to each of the request task groups;

[0025] The creation time of each requested task group is recorded as the initial last modification time.

[0026] 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 record risk control scenario, the system needs to process call records of different users and different communication types at the same time, and must consider the user's credit rating and historical behavior. Simply processing all call records in chronological order cannot ensure that the call records 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 record request task, such as user ID, communication type and other key information. Based on the extracted task attributes, the system uses a preset classification algorithm to classify the call record request tasks, and automatically assigns call record request tasks with the same task attributes to the same request task group, ensuring that the call records of the same user are centrally managed and arranged in chronological order. Then, a unique group identifier is assigned to each formed request task group and the creation time of each request task group is recorded. This achieves refined classification of call record request tasks, enabling the system to ensure the processing order of the call records of the same user, greatly improving the efficiency and accuracy of risk control.

[0027] Optionally, the method further includes the following steps:

[0028] Record the usage status of each concurrent slot in the preset slot mapping table;

[0029] When the target request task is allocated to an idle 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.

[0030] By adopting the above technical solution, 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 an 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 to occupied in the slot mapping table, and records the task identifier and group identifier corresponding to the request task occupying the slot, establishing 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.

[0031] Optionally, the method further includes the following steps:

[0032] When the target request task is assigned to a concurrent slot, the target request task is added to a preset processing pool;

[0033] The slot identifier, group identifier and task identifier of the target request task are recorded in the processing pool.

[0034] By adopting the above technical solutions, 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; it realizes comprehensive and real-time management of tasks being processed, greatly improving the system's task management capabilities and response speed, and the system can quickly locate and adjust tasks of specific users or specific types, and better realize task priority adjustment in emergency situations.

[0035] Optionally, the method further includes the following steps:

[0036] Based on the group identifier of the request task group, obtaining historical processing data of the request task group, the historical processing data including processing frequency, exception rate and user complaint rate;

[0037] Based on the historical processing data and the preset grouping monitoring level, determining the monitoring level of the requested task group, the monitoring level including routine monitoring, key monitoring and emergency processing;

[0038] Adjusting the processing priority factor corresponding to the request task group according to the monitoring level;

[0039] 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.

[0040] 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 bill risk control scenario, some user groups may need 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 time, 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 user group, the exception rate indicates the proportion of abnormal situations occurring during the processing process, and the user votes. 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 standards, the system determines the monitoring level of the request task group and divides it into one of the three levels: 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 to calculate a comprehensive priority indicator to obtain the target request task; it can more accurately judge the importance and urgency of the task, thereby making more reasonable resource allocation decisions.

[0041] Optionally, the method further comprises the following steps:

[0042] 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;

[0043] 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;

[0044] 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 frequency of secondary verification of the processing results, wherein the second abnormality rate threshold is greater than the first abnormality rate threshold;

[0045] When the request task group is judged to be at the 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.

[0046] By adopting the above technical solutions, traditional systems often adopt static monitoring strategies and are unable to adjust processing priorities and resource allocation in time according to real-time situations, resulting in slow response when facing sudden anomalies or high-risk situations, affecting the security of the system and user experience; this application dynamically upgrades the task group of the regular 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 anomaly rate with the historical anomaly rate, a risk warning is triggered when the anomaly rate increases significantly, thereby realizing early risk identification. When the anomaly 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 task group of the emergency level, 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 resource allocation is achieved, thereby improving overall processing efficiency.

[0047] In a second aspect, the present application provides a concurrent processing system for requests with sequential requirements, comprising:

[0048] 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;

[0049] A task group adding module, used for adding the requested task group to a pending pool;

[0050] 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;

[0051] A request task allocation module is used to obtain target request tasks and allocate the target request tasks to pre-set concurrent slots;

[0052] A task concurrent processing module, configured to concurrently process target request tasks assigned to the concurrent slots;

[0053] A task occupied slot releasing module, which releases the slot occupied by the target request task when the target request task is completed;

[0054] Wherein, the request task allocation module includes:

[0055] An idle slot checking unit, used to check whether there is an idle slot in the concurrent slot;

[0056] 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;

[0057] 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;

[0058] A task allocation unit, configured to allocate the target request task to an idle slot;

[0059] A data updating unit is configured to update the pending pool and the group list according to the group identifier corresponding to the target request task group, including a modification time of updating the group list.

[0060] 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.

[0061] 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.

[0062] In summary, this application includes at least one of the following beneficial technical effects:

[0063] 1. Since traditional methods often find it difficult to achieve efficient concurrency while ensuring the order of task processing, the system performance is poor and cannot meet the growing business needs. For example, in the user call record risk control scenario, it is necessary to quickly process a large number of call records to prevent risks, and to ensure that the call records 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 queue. 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 simultaneously to achieve efficient concurrency. When a target request task is completed, the concurrent slot it occupies is immediately released. This not only effectively resolves 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.

[0064] 2. Traditional concurrent systems find it difficult to accurately grasp the system resource usage and task execution status in real time, resulting in inefficient resource utilization and an inability to respond promptly to the processing needs of high-priority tasks. For example, in a 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 a target request task is assigned to an idle slot, the system immediately updates the status of the corresponding slot to occupied in the slot mapping table, and records the task identifier and group identifier corresponding to the request task occupying the slot, thereby establishing a clear association between the slot and the task. This allows for rapid location and adjustment of the execution status of specific tasks, enabling task priority adjustment in emergency situations.

[0065] 3. This application obtains historical processing data of the request task 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 them, the processing frequency reflects the activity level and system load of a certain type of task or a user group, the exception rate indicates the proportion of abnormal situations occurring during 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; based on the obtained 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 to calculate a comprehensive priority index to obtain the target request task; it can more accurately judge the importance and urgency of the task, thereby making more reasonable resource allocation decisions. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] Figure 1 This is a flowchart of a method for concurrently processing requests with sequence requirements according to an embodiment of the present application;

[0067] Figure 2 This is a flowchart of step S110 in a method for concurrently processing requests with sequence requirements according to an embodiment of the present application;

[0068] Figure 3 This is a flow chart of recording slot usage status in a concurrent processing method for requests with sequence requirements according to an embodiment of the present application;

[0069] Figure 4 This is a flow chart of optimizing the priority of request tasks in a concurrent processing method for requests with sequential requirements according to an embodiment of the present application;

[0070] Figure 5 This is a flowchart of hierarchical processing in a concurrent processing method for requests with sequence requirements according to an embodiment of the present application;

[0071] Figure 6 This is a module diagram of a concurrent processing system for requests with sequence requirements according to an embodiment of the present application;

[0072] Figure 7 This is a diagram of the internal structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0073] The terms used in the following examples of the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application. As used in the specification and appended claims of this application, the singular expressions "a," "an," "said," "above," "the," and "this" are intended to include plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in this application refers to any or all possible combinations comprising one or more of the listed items.

[0074] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to imply or suggest relative importance or implicitly indicate the number of the technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of this application, unless otherwise specified, "plurality" means two or more.

[0075] The embodiments of the present application are described in further detail below with reference to the accompanying drawings.

[0076] In the first aspect, the present application provides a method for concurrently processing requests with sequential requirements, referring to Figure 1 , including the following steps:

[0077] 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.

[0078] 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. They need to be processed in a certain order to ensure the accuracy and continuity of the business.

[0079] Specifically, the system categorizes received request tasks based on pre-set grouping criteria. For example, in a user call record risk control scenario, users are grouped by mobile phone number to ensure that records for the same user are processed in chronological order. Another example is the user ID grouping in the user activation and account opening process, ensuring that steps such as user information review, core system account opening, and resource accounting are executed in the correct order.

[0080] S120: Add the requested task groups to a pending pool.

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

[0082] Specifically, the pending pool can be implemented using an appropriate data structure, such as a hash table or priority queue. Each group in the pending pool can contain its unique identifier (such as GroupID) and all requested tasks within that group. For example, in a call record risk control scenario, an entry in the pending pool might be: {GroupID: "13800138000", Tasks: [Task1, Task2, Task3]}, where Task1, Task2, and Task3 are specific call record processing tasks arranged in the order they were received.

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

[0084] 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.

[0085] Specifically, the group list can be implemented as a data structure sorted by last modification time, such as an ordered map or priority queue. Each entry contains the group ID and 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 when a task is removed from the group for processing. This design allows the system to prioritize groups that have not been updated for a long time, ensuring fairness and preventing some groups from being left idle for long periods of time.

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

[0087] The system selects target request tasks from the pending pool and assigns them to pre-set concurrent processing slots. A concurrent slot represents the number of tasks the system can process simultaneously. By properly assigning tasks to concurrent slots, we can achieve parallel processing of tasks and improve the overall processing efficiency of the system.

[0088] 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 the modification time of the updated group list.

[0089] In this embodiment, the system first determines whether the group list GroupList is empty. If it is empty, it skips the process. 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 the group already has a task being processed, 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, that is, the preset processing pool ProcessingPool, with CurlHandleID as the key, to track the tasks being processed, delete the assigned 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.

[0090] Furthermore, in the SlotMap, the system associates the selected SlotID with the assigned GroupID, marking the slot as occupied. After completing the above steps, the system checks whether there are any free slots or pending tasks. If so, the above process repeats. If the slot is full or the task has been assigned, the execution phase begins.

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

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

[0093] Specifically, the system assigns an independent processing thread or process to each concurrent slot. Each processing unit is responsible for executing the assigned target request task, such as calling the corresponding API or executing specific business logic. During processing, the system must ensure that tasks within the same group are not processed simultaneously to maintain the required order of task execution. Furthermore, the system must monitor the execution status of each task to ensure timely follow-up processing after task completion.

[0094] S160. When the target request task is completed, the slot occupied by the target request task is released.

[0095] 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.

[0096] Specifically, the system will first obtain the content returned by the request from the batch processing pool based on 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 still tasks in the group GroupID in the WaitingPool. If there are still tasks, the system will delete the record of GroupID in the GroupList, indicating that the processing of the group has ended. If there are still tasks to be processed for this group in the WaitingPool, the system will continue to process the next task. If there are no more tasks for this 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.

[0097] 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:

[0098] S111. Obtain task attributes of each requested task.

[0099] 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. It can be an inherent feature of the request task or an attribute derived from business logic.

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

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

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

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

[0104] S113. Grouping request tasks with the same task attributes into the same request task group.

[0105] In this embodiment, the system formally groups the request tasks categorized 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 (e.g., first-in, first-out). For example, in a user account activation scenario, the system may group all related request tasks for the same user (e.g., information submission, review, account opening, notification, etc.) into the same group to ensure that these tasks are executed in the correct order.

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

[0107] In this embodiment, the system assigns a unique identifier to each request task group created in S113. These unique identifiers can be generated using incrementing integers, UUIDs, or hash values based on task attributes. For example, in a call record risk control scenario, the system might use the "GROUP_" prefix plus a hash value of the mobile phone number to create a group identifier.

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

[0109] In one embodiment, referring to Figure 3 , the method further comprises the steps of:

[0110] S310: Record the usage status of each concurrent slot in a preset slot mapping table.

[0111] 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.

[0112] 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 information such as usage status (such as "free" or "occupied"), occupancy time, and last update time.

[0113] 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.

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

[0115] Specifically, the update process might include changing the slot status from "free" to "occupied," recording the task ID (TaskID) that occupies the slot; this ID can be a unique system-generated ID used to track the task throughout the processing process; recording the group ID (GroupID) to which the task belongs; and updating the slot's last modification timestamp. Additional metadata, such as the task's priority and estimated execution time, may also be recorded.

[0116] 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.

[0117] In one embodiment, referring to Figure 4 , the method further comprises the steps of:

[0118] 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, exception rate, and user complaint rate.

[0119] 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.

[0120] For example, consider a large telecom operator's customer call record risk control system. This system must process massive amounts of user call records, identify potential fraud, and protect the interests of both users and the operator. The system categorizes users into multiple groups based on their call behavior characteristics and risk levels. Based on the group identifier of the requested task group, historical processing data for that group is extracted from a pre-defined data storage system. This historical processing data includes key metrics such as processing frequency, exception rate, and user complaint rate. The processing frequency reflects the activity level and system load of a particular task or user group. The exception rate indicates the proportion of exceptions encountered during the processing process. The user complaint rate directly reflects user satisfaction with service quality and potential issues. These three metrics complement each other, forming a comprehensive task importance assessment system based on the three key dimensions of system load, system health, and user experience. In call record risk control, system load can be used to understand the calling patterns and system resource requirements of different user groups. By querying historical data, the processing frequency of each user group can be obtained, such as the average daily call processing volume for each user group over the past 30 days. A high processing frequency may indicate that the user group requires more system resources or may exhibit abnormal calling behavior. The anomaly rate represents the proportion of calls marked as suspicious or high-risk by the system, reflecting system health and potential risks. The user complaint rate represents the proportion of complaints received against a user number. This rate is often associated with harassing calls, fraud, and other undesirable activity, requiring prompt risk management.

[0121] 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.

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

[0123] Specifically, the system collects historical data from a preset time period, smooths outliers, and removes the impact of extreme data on judgment. It then normalizes the three metrics: processing frequency, anomaly rate, and user complaint rate. Dynamic thresholds for each metric are calculated based on the mean and standard deviation of the historical data. The processing frequency threshold dynamically adjusts over time, while the anomaly rate and user complaint rate thresholds are adjusted based on seasonal characteristics (such as holidays). Weights are then assigned to the three metrics, and the degree of deviation of each metric from the preset baseline is calculated to obtain a deviation score. Finally, the weighted summation yields a comprehensive risk score. Different monitoring level thresholds are set based on the comprehensive risk score. When the comprehensive risk score does not exceed the first preset threshold, the monitoring level for the requested task group is set to routine monitoring. When the comprehensive risk score is greater than the first preset threshold but not greater than the second preset threshold, the monitoring level for the requested task group is set to key monitoring. When the comprehensive risk score is greater than the second preset threshold, the monitoring level for the requested task group is set to emergency handling.

[0124] Furthermore, to mitigate the impact of frequent fluctuations in monitoring levels, the system incorporates a monitoring level adjustment buffer mechanism. An upgrade to a monitoring level is triggered only when the combined risk score of a requested task group reaches a higher level for multiple consecutive days, and a downgrade is triggered only when the combined risk score of a requested task group reaches a lower level. If the user complaint rate suddenly and significantly increases—that is, if the increase exceeds a preset threshold within a preset period of time—the system initiates an immediate upgrade mechanism, promptly adjusting the monitoring level to address unexpected risks.

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

[0126] Specifically, the system sets different basic priority scores based on the monitoring level of the requested task group. The basic score for the regular monitoring level is a first preset value, the basic score for the critical monitoring level is a second preset value, and the basic score for the emergency processing level is a third preset value, with the first preset value being less than the second preset value and the third preset value. Based on the basic scores, the system first calculates the task's time decay factor. This is calculated using an exponential decay function based on the time difference between the task's modification time and the current time. The task's time decay factor is determined by the larger value of the exponential decay function and the minimum decay threshold. The difference between the current time and the task's modification time is used as the independent variable, and the decay rate coefficient is used as the parameter for exponential calculation. This gives newly modified tasks a higher time decay factor. Over time, the time decay factor gradually decreases, but never falls below the minimum decay threshold, ensuring that long-term tasks still receive processing opportunities. Furthermore, a corresponding service weight coefficient is set based on the task type. For tasks during special periods such as holidays, the corresponding service weight is increased. Furthermore, by analyzing the task backlog in each processing queue, a task allocation balancing coefficient is calculated, reducing the priority of tasks in processing queues with higher loads. The final processing priority factor is obtained by multiplying the base score, the time decay factor, the service weight coefficient, and the load balancing factor. It is understood that the system will set upper and lower limits for the priority factor to prevent extreme cases from causing the priority to be too high or too low.

[0127] 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.

[0128] In this embodiment, the system adjusts the processing priority factor of the request task group based on the monitoring level determined in the previous step. Then, when obtaining the target request task, the system comprehensively considers the task group's modification time and priority factor to calculate a comprehensive priority index to obtain the target request task. This allows for more accurate judgment of the task's importance and urgency, leading to more reasonable resource allocation decisions.

[0129] Traditional systems often use static monitoring strategies and are unable to adjust processing priorities and resource allocation in real time 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 steps of:

[0130] S510: When the request task group is determined to be at the 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 the key monitoring level.

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

[0132] Specifically, the system uses a sliding time window to calculate request frequency. For example, if the average request frequency of a typical user group exceeds the threshold of 10 requests per minute within the last hour, the system will upgrade the user group to a high-priority monitoring level. This mechanism effectively captures unexpected abnormal behavior, such as batch automated calls, which could be a scam or harassment.

[0133] 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.

[0134] In this embodiment, the system identifies possible anomalies by comparing the current anomaly rate with historical anomaly rates. This approach takes into account that different user groups may have different baseline anomaly rates. By using relative comparisons rather than absolute thresholds, it can more accurately capture true anomalies.

[0135] Specifically, the system calculates the anomaly rate for the last 24 hours as the current anomaly rate and compares it with the average anomaly rate for the past 30 days. For example, if a user group's historical anomaly rate is 5% and its current anomaly rate is 8%, the difference is 3%. Assuming the first anomaly rate growth threshold is set at 2%, the system will trigger a risk warning mechanism. This mechanism can promptly detect sudden increases in anomalies, allowing operators to quickly take appropriate measures.

[0136] 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.

[0137] In this embodiment, the system sets two levels of abnormality 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.

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

[0139] S540. When the request task group is judged to be at the 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.

[0140] In this example, the system prioritizes resources and strictest time constraints for urgent tasks. By immediately allocating concurrent slots and setting minimum processing times, the system ensures a rapid response to high-risk situations. Furthermore, an automatic alert mechanism based on processing time is implemented to promptly notify relevant personnel of unusual processing delays.

[0141] Specifically, the system sets the minimum processing time for urgent tasks to 5 seconds and the default processing percentage to 80%. This means that if the processing time for an urgent task exceeds 4 seconds (80% of 5 seconds), the system will automatically trigger an alarm. This mechanism ensures that urgent tasks are handled promptly even under high load conditions and quickly attracts attention when abnormal delays occur, thereby minimizing potential risks.

[0142] 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 this application.

[0143] On 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 combination with the above-mentioned concurrent processing method for requests with sequential requirements.

[0144] Reference Figure 6 , a concurrent processing system for requests with sequential requirements, comprising:

[0145] 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;

[0146] The task group adding module is used to add the request task group to the pending pool;

[0147] 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;

[0148] 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;

[0149] The task concurrent processing module is used to concurrently process the target request tasks assigned to the concurrent slots;

[0150] The task occupied slot release module releases the slot occupied by the target request task when the target request task is completed;

[0151] The request task allocation module includes:

[0152] An idle slot checking unit, used to check whether there is an idle slot in the concurrent slot;

[0153] 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;

[0154] 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;

[0155] A task allocation unit, configured to allocate target request tasks to free slots;

[0156] 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 the updated group list.

[0157] 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 via a system bus. 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 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 via a network connection. When the computer program is executed by the processor, a method for concurrently processing requests with sequential requirements is implemented.

[0158] Those skilled in the art will understand that Figure 7The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the electronic device to which the solution 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 component arrangement.

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

[0160] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. The above-described computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the above-described method embodiments. Any reference to memory, storage, database, or other media used in the embodiments provided herein may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM may be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0161] The above are all preferred embodiments of the present application, and are not intended to limit the scope of protection of the present application. Therefore, any equivalent changes made based on the structure, shape, and principle of the present application should be included in the scope of protection of the present application.

Claims

1. A method for concurrently processing requests with sequential requirements, characterized in that: The steps include: 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 requested task groups 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; Obtain target request tasks and assign the target request tasks to pre-set concurrent slots; concurrently processing the target request tasks assigned to the concurrent slots; When the target request task is completed, the slot occupied by the target request task is released; 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 pending pool, taking 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 the modification time of updating 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; Assigning a unique group identifier to each of the request task groups; The creation time of each requested task group 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 an idle 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.

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, obtaining historical processing data of the request task group, the historical processing data including processing frequency, exception 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, the monitoring level including routine monitoring, key monitoring and emergency processing; Adjusting the processing priority factor corresponding to the request task group according to the monitoring level; 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 results, 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, the currently idle concurrent slot is immediately allocated, and the processing timeout period 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 target request tasks and allocate the target request tasks to pre-set concurrent slots; A task concurrent processing module, configured to concurrently process 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 completed; Wherein, the request task allocation module includes: An idle slot checking unit, used to check whether there is an idle 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, 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, configured to allocate the target request task to an idle slot; A data updating unit is configured to update the pending pool and the group list according to the group identifier corresponding to the target request task group, including a 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 method for concurrently processing 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 computer program implements the steps of the concurrent processing method for requests with sequence requirements according to any one of claims 1 to 6.

Images