Data processing method and apparatus

Abstract

The application provides a data processing method and device, wherein the data processing method comprises: obtaining a preset number of expired tasks from a first buffer database every preset time length and writing the expired tasks into a second buffer database; in the case that the expired tasks included in the second buffer database exceed a load threshold of a storage database, obtaining a load threshold number of first expired tasks from the second buffer database, and processing corresponding data in the storage database according to the first expired tasks; determining second expired tasks in the second buffer database except the first expired tasks, and marking the second expired tasks as expired, wherein the expired mark is used to indicate that the corresponding data of the second expired tasks in the storage database is prohibited from operation. In this way, the expired tasks are processed with a time delay, the business system is prevented from frequently operating the database, the processing pressure of the business system and the storage database is reduced, and the processing accuracy of the expired tasks processed with a time delay is ensured.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method. This application also relates to a data processing apparatus, a computing device, and a computer-readable storage medium. Background Technology

[0002] With the rapid development of computer and internet technologies, more and more businesses can be conducted online. When conducting business online, a large amount of task data is generated. Some task data is not processed immediately upon generation, but is processed after a period of time. Therefore, the database needs to store a large amount of task data and monitor whether each task data has reached its processing time. For task data that has reached its processing time but has not been processed by the user, it needs to be deleted from the database to avoid occupying too much storage space.

[0003] In existing technologies, business systems can periodically poll the database to identify which tasks have expired, and then perform subsequent business logic processing on the expired data. This allows the business system to perform real-time queries, verifications, data insertion, and deletions. However, this method involves very frequent database processing, placing excessive pressure on both the business system and the database, potentially leading to system and database crashes. Summary of the Invention

[0004] In view of this, embodiments of this application provide a data processing method to address the technical deficiencies existing in the prior art. Embodiments of this application also provide a data processing apparatus, a computing device, and a computer-readable storage medium.

[0005] According to a first aspect of the embodiments of this application, a data processing method is provided, applied to a business system, including:

[0006] Every preset duration, a preset number of due tasks are retrieved from the first buffer database and written to the second buffer database;

[0007] If the number of expired tasks included in the second buffer database exceeds the load threshold of the storage database, the first expired task with the load threshold is obtained from the second buffer database, and the corresponding data in the storage database is processed according to the first expired task.

[0008] Identify a second expired task in the second buffer database, other than the first expired task, and mark the second expired task as expired. The expiration mark is used to indicate that the corresponding data of the second expired task in the storage database is prohibited from operation.

[0009] Optionally, before retrieving a preset number of due tasks from the first buffer database and writing them to the second buffer database every preset duration, the following steps are included:

[0010] Retrieve tasks to be processed, each task carrying a corresponding processing time limit;

[0011] Store the tasks to be processed and their corresponding processing time limits in the first buffer database;

[0012] Monitor the processing time limits of each pending task in the first buffer database, and determine the expired tasks from each pending task.

[0013] Optionally, before obtaining the task to be processed, the following steps are also included:

[0014] Receive at least one service creation request, wherein the creation request carries the processing time limit of the corresponding service;

[0015] Based on the creation request, create at least one corresponding business;

[0016] Receive user requests for specific business functions and generate corresponding pending tasks based on the requests. Each pending task carries a corresponding processing time limit.

[0017] Optionally, the second due task is marked for due, including:

[0018] Record the second expiring task in the first buffer database and mark it as expired.

[0019] Optionally, the method further includes:

[0020] Receive operation requests initiated by users for target tasks;

[0021] Search for the target task in the first buffer database;

[0022] If the target task is found, it is determined to be an overdue task, and an operation failure notification message is returned.

[0023] Optionally, the corresponding data in the storage database is processed according to the first due date task, including:

[0024] Create at least two threads and determine the number of tasks to be processed for each thread;

[0025] Based on the number of tasks to be processed by each thread, each first-expiring task is assigned to at least two threads;

[0026] The corresponding data in the storage database is processed using at least two threads based on the first expiration task.

[0027] Optionally, the corresponding data in the storage database is processed according to the first due date task, including:

[0028] Search the storage database for the target data corresponding to the first due task;

[0029] Delete the target data from the storage database and return a task due date reminder to the user corresponding to the first due task.

[0030] Optionally, the retrieval request carries task request parameters; based on the retrieval request, a task to be processed corresponding to the target business is generated, including:

[0031] Based on the task request parameters, verify the validity of the request in the validation database;

[0032] If the request is determined to be valid, a task to be processed corresponding to the target business is generated based on the request.

[0033] Optionally, the verification database includes at least one set of user identifiers corresponding to a business, the set of user identifiers including each user identifier that conforms to the first filtering rule of the corresponding business; based on the task request parameters, the validity of the acquisition request is verified in the verification database, including:

[0034] Obtain the target user identifier corresponding to the request from the task request parameters;

[0035] Determine if the target user identifier exists in the user identifier set corresponding to the target business;

[0036] If so, then the request is considered a valid request;

[0037] If not, then the request is determined to be invalid.

[0038] Optionally, the method further includes:

[0039] Obtain the target business identifier corresponding to the request from the task request parameters;

[0040] Determine whether the target business identifier conforms to the preset identifier rules;

[0041] If so, then the request is considered a valid request;

[0042] If not, then the request is determined to be invalid.

[0043] According to a second aspect of the embodiments of this application, a data processing apparatus is provided, applied to a business system, comprising:

[0044] The write module is configured to retrieve a preset number of due tasks from the first buffer database and write them to the second buffer database every preset time interval.

[0045] The processing module is configured to, when the number of expired tasks included in the second buffer database exceeds the load threshold of the storage database, retrieve the first expired task from the second buffer database based on the load threshold, and process the corresponding data in the storage database based on the first expired task;

[0046] The marking module is configured to identify a second expired task in the second buffer database, other than the first expired task, and mark the second expired task as expired. The expiration mark is used to indicate that the corresponding data of the second expired task in the storage database is prohibited from operation.

[0047] According to a third aspect of the embodiments of this application, a computing device is provided, comprising:

[0048] Memory and processor;

[0049] Memory is used to store computer-executable instructions, and the steps of data processing methods are implemented when the processor executes the computer-executable instructions.

[0050] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of a data processing method.

[0051] The data processing method provided in this application allows a business system to retrieve a preset number of due tasks from a first buffer database and write them to a second buffer database at preset intervals. If the number of due tasks in the second buffer database exceeds the load threshold of the storage database, the system retrieves a load threshold number of first due tasks from the second buffer database, processes the corresponding data in the storage database based on the first due tasks, determines second due tasks in the second buffer database other than the first due tasks, and marks the second due tasks as due. The due task is used to indicate that the corresponding data in the storage database for the second due task is prohibited from operation.

[0052] In this scenario, the business system can temporarily store the tasks corresponding to the various data generated by the user in a first buffer database. The business system can monitor each task temporarily stored in the first buffer database and retrieve a preset number of due tasks from the first buffer database every preset time interval, writing them to a second buffer database. That is, the second buffer database stores due tasks that require processing of the corresponding data in the storage database. At this point, based on the current load threshold of the storage database, the system can determine how many due tasks to process at once, retrieving only the corresponding number of due tasks from the second buffer database for processing. Thus, based on the load threshold of the storage database, the system processes the due tasks stored in the second buffer database sequentially. Due tasks that have not yet been processed can be marked as due, preventing user operations on the data corresponding to these due tasks in the storage database. In this way, through two buffer databases, due tasks are delayed, and due tasks that have not yet been processed are marked as due, ensuring that users cannot operate on data in the storage database that has expired and has not yet been processed. This delays due tasks, avoids frequent database operations by the business system, reduces the processing pressure on both the business system and the storage database, and ensures the accuracy of delayed due task processing. Attached Figure Description

[0053] Figure 1 This is a schematic diagram of the structure of a data processing system provided in one embodiment of this application;

[0054] Figure 2 This is a flowchart of a first data processing method provided in an embodiment of this application;

[0055] Figure 3a A schematic diagram of a method for determining a set of user identifiers according to an embodiment of this application is shown;

[0056] Figure 3b This is a schematic diagram of a task to be processed provided in the embodiments of this specification;

[0057] Figure 4 This is a flowchart of a second data processing method provided in an embodiment of this application;

[0058] Figure 5 This is a flowchart of a third data processing method provided in an embodiment of this application;

[0059] Figure 6 This is a flowchart of a fourth data processing method provided in an embodiment of this application;

[0060] Figure 7 This is a flowchart of the fifth data processing method provided in an embodiment of this application;

[0061] Figure 8 This is a flowchart of the sixth data processing method provided in an embodiment of this application;

[0062] Figure 9 This is a flowchart of the seventh data processing method provided in an embodiment of this application;

[0063] Figure 10 This is a flowchart of the eighth data processing method provided in an embodiment of this application;

[0064] Figure 11 This is a flowchart of the ninth data processing method provided in an embodiment of this application;

[0065] Figure 12 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0066] Figure 13 This is a structural block diagram of a computing device provided in one embodiment of this application. Detailed Implementation

[0067] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.

[0068] The terminology used in one or more embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this application. The singular forms “a” and “the” as used in one or more embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this application refers to and includes any or all possible combinations of one or more associated listed items.

[0069] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this application, and similarly, second may also be referred to as first.

[0070] First, the terminology used in one or more embodiments of the present invention will be explained.

[0071] Seconds Kill: This refers to a sales method where items are sold out within a single second. Because some tasks come with high returns, they are often more attractive to people. Sometimes, all the task data can be sold out in just one second, hence the name Seconds Kill.

[0072] I / O request: an abbreviation for input / output, which refers to the handling of input and output requests.

[0073] NoSQL: refers to non-relational databases.

[0074] Relational databases: Relational databases are databases created based on the relational model. The series of rows and columns in a relational database are called tables, and a group of tables forms a database. Relational databases use data methods such as selection, projection, join, union, intersection, difference, division, and CRUD operations to query and store data.

[0075] QPS (Queries Per Second) is the number of queries a server can respond to per second. It is a measure of how much traffic a specific query server processes within a given time.

[0076] Concurrency: refers to a period of time in which several programs are in the process of starting and running, and these programs are all running on the same processor, but at any given moment only one program is executing on the processor.

[0077] Multithreading: completing multiple tasks simultaneously.

[0078] It's important to note that in traditional project solutions, after a user successfully completes a large batch of task data and generates an order, the system will periodically poll the database to determine which data is about to expire or has already expired, before proceeding with subsequent business logic. Traditional I / O-blocking services perform real-time queries, verifications, and data insertion. This constitutes very frequent database I / O operations. Frequent database queries can overload the business system and potentially cause it to crash.

[0079] Therefore, this application provides a data processing method that combines a first buffer database and a second buffer database, and refers to the idea of ​​a "funnel" algorithm to build a high-performance technical solution for delayed processing of expired data. This method can complete the timely processing of expired data without real-time interaction with the storage database, thereby reducing the I / O frequency of real-time database requests.

[0080] Furthermore, in practical applications, a user's eligibility for a particular service is only verified when the user wants to participate. With the complex business processes of the system (calculating whether a user is eligible for a flash sale), real-time queries and processing from the relational database should be avoided, or even prohibited. This is because as system traffic increases, the QPS (queries per second) also increases. A typical database server performs best with a QPS of 800-1200. Beyond 2000, the database becomes increasingly overwhelmed by SQL statements, slowing down system response and easily causing system crashes.

[0081] Therefore, this application provides a data processing method that can perform data preheating, determine the set of user identifiers corresponding to each business created by the business party, that is, the set of each user with business access rights, and store each set of user identifiers in a verification database for subsequent verification.

[0082] This application provides a data processing method. This application also relates to a data processing apparatus, a computing device, and a computer-readable storage medium, which will be described in detail in the following embodiments.

[0083] Figure 1 A schematic diagram of the structure of a data processing system according to an embodiment of this application is shown.

[0084] This application can be divided into two execution entities: a server and an application terminal. Users can initiate a request for a target service through the application terminal and send the request to the server. The server can generate and store corresponding pending tasks. Then, it can retrieve a preset number of expired tasks from a first buffer database every preset time interval and write them to a second buffer database. If the number of expired tasks in the second buffer database exceeds the load threshold of the storage database, it retrieves the load threshold number of first expired tasks from the second buffer database and processes the corresponding data in the storage database based on these first expired tasks. It then identifies second expired tasks in the second buffer database, excluding the first expired tasks, and marks these second expired tasks as expired. These expiration marks indicate that operations on the corresponding data in the storage database are prohibited for the second expired tasks.

[0085] The solution in this application uses a double-buffered database to delay expired tasks. For expired tasks that have not yet been processed, an expiration mark can be made, ensuring that users cannot operate on data that has expired and has not yet been processed in the storage database. This not only delays the processing of expired tasks, avoiding frequent database operations by the business system and reducing the processing pressure on the business system and the storage database, but also ensures the accuracy of the delayed processing of expired tasks.

[0086] Figure 2 A flowchart of a first data processing method according to an embodiment of this application is shown, which specifically includes the following steps:

[0087] Step 202: Retrieve a preset number of due tasks from the first buffer database every preset duration and write them to the second buffer database.

[0088] The first buffer database stores the pending tasks generated when a user requests a service, along with their corresponding processing time limits. This allows the business system to monitor whether each pending task in the first buffer database has reached its processing time limit and filter out expired tasks. The second buffer database receives and stores the expired tasks filtered from the first buffer database sequentially, for subsequent processing of the data corresponding to these expired tasks in the storage database. In practice, the first buffer database can be any intermediate database with temporary data storage capabilities, and the second buffer database can be any intermediate database with traffic shaping capabilities.

[0089] It should be noted that the storage database refers to the database that stores the specific data corresponding to each pending task. That is, the first buffer database is used to store each pending task in order to monitor the time limit of the pending tasks; the second buffer database is used to store the monitored overdue tasks; and the storage database is used to store the specific data corresponding to each pending task for actual operation and processing.

[0090] Specifically, the preset duration can refer to a pre-set time period, which can represent the frequency of writing due tasks from the first buffer database to the second buffer database. For example, the preset duration can refer to 1 minute, 5 minutes, 1 hour, etc.; the preset value can refer to a pre-set value, which is used to represent the number of due tasks written from the first buffer database to the second buffer database each time. For example, the preset value can be 20, 50, 100, etc.

[0091] In practical applications, the preset duration and preset value together determine the delay frequency for writing due tasks from the first buffer database to the second buffer database. The preset duration and preset value can be set independently according to the system parameters of the business system, such as retrieving 50 due tasks from the first buffer database and writing them to the second buffer database every 5 minutes. Here, due tasks can refer to tasks that have reached the user's operation time limit but have not yet been operated by the user.

[0092] It should be noted that, based on the requirements of the business system, after a user obtains a service request, a corresponding pending task can be generated. This pending task does not require immediate user action; rather, the user must act on it before its time limit. For expired tasks that have reached their time limit but have not yet been acted upon, the business system can automatically release the data corresponding to the expired tasks in the storage database. This means clearing the specific data corresponding to expired tasks that have reached their time limit but have not yet been acted upon from the storage database, and then performing subsequent data refresh, user notification, and other business operation logic. Therefore, the business system can monitor the processing time limits of each pending task in the first buffer database, determine whether each pending task has expired, and then retrieve a preset number of expired tasks from the first buffer database every preset time interval and write them to the second buffer database for subsequent processing of expired tasks.

[0093] In the embodiments of this specification, the business system monitors the processing time limit of each pending task in the first buffer database, filters out the due tasks, and then does not immediately write each of the filtered due tasks into the second buffer database in real time. Instead, like a funnel, each due task in the first buffer database slowly leaks into the second buffer database. That is, every preset time interval, a preset number of due tasks are retrieved from the first buffer database and written into the second buffer database, thereby reducing the processing pressure of the business system.

[0094] In an optional embodiment of this example, before writing due tasks from the first buffer database to the second buffer database, multiple pending tasks may be written to the first buffer database. That is, before retrieving a preset number of due tasks from the first buffer database every preset time interval and writing them to the second buffer database, the following may also be included:

[0095] Retrieve tasks to be processed, each task carrying a corresponding processing time limit;

[0096] Store the tasks to be processed and their corresponding processing time limits in the first buffer database;

[0097] Monitor the processing time limits of each pending task in the first buffer database, and determine the expired tasks from each pending task.

[0098] Specifically, the pending tasks can be tasks that require users to complete before the processing deadline. Each pending task carries a corresponding processing deadline, which can refer to a time period or the latest time. For example, the processing deadline can be January 1st-January 5th, within 30 minutes, or before January 20th. This application does not impose any restrictions on this.

[0099] In practical applications, a monitoring thread can be created. After storing the tasks to be processed and their corresponding processing time limits in the first buffer database, the monitoring thread can monitor the processing time limits of each task to be processed in the first buffer database and determine the tasks that have expired from each task to be processed.

[0100] Alternatively, timers can be created to monitor the processing time limits of each pending task in the first buffer database, and the due tasks can be identified from among them. Specifically, when storing the pending tasks and their corresponding processing time limits in the first buffer database, a timer can be created for each processing time limit. The timer will keep track of the time, and when the timer reaches the corresponding processing time limit, an expiration notification will be triggered, and the pending task corresponding to the expiration notification will be identified as the due task.

[0101] It should be noted that the acquired tasks to be processed and their corresponding processing time limits can be stored in the first buffer database. The business system can monitor the processing time limits of each task to be processed in the first buffer database through the monitoring thread, determine the current due task from each task to be processed based on the current time, and then the business system can retrieve a preset number of due tasks from the first buffer database every preset time interval and write them into the second buffer database, so as to process the due data in the storage database based on the due tasks in the second buffer database.

[0102] In the embodiments of this specification, the business system can store the acquired tasks to be processed and their corresponding processing time limits in a first buffer database, monitor the processing time limits of each task to be processed in the first buffer database, filter out expired tasks, and thus accurately monitor the processing of each task to be processed in the first buffer database.

[0103] In an optional implementation of this embodiment, before obtaining the task to be processed, a service for the user to obtain can be created first. That is, before obtaining the task to be processed, the following can also be included:

[0104] Receive at least one business creation request, wherein the creation request carries the corresponding business processing time limit;

[0105] Based on the creation request, create at least one corresponding service.

[0106] Specifically, at least one service can refer to a service that a user can access. After a user accesses a service, a corresponding pending task and data can be generated. The pending task is stored in a first buffer database for time-limit monitoring, and the corresponding data is stored in a storage database for actual operation processing. For example, if the service is a flash sale of a certain product, after a user participates in the flash sale, a corresponding flash sale task and flash sale order data can be generated. The flash sale task is stored in the first buffer database, and the flash sale order data is stored in the storage database.

[0107] It should be noted that business users can pre-create at least one business through the business system and set custom processing time limits for each business. This means that different businesses can have different processing time limits, increasing the flexibility of business time limit requirements.

[0108] In an optional implementation of this embodiment, when creating at least one service, the service provider can set corresponding restrictions for each service. This means that filtering rules can be set for each service. For example, a target service requires users whose user points exceed a threshold; another example is that a target service requires users to have a certain level of knowledge in the relevant field. In other words, each service can carry filtering rules. After creating at least one corresponding service based on the creation request, the following steps are also included:

[0109] Based on the first filtering rule corresponding to the first service, determine the first user identifier set corresponding to the first service, wherein the first service is any one of at least one service;

[0110] Add the first user identifier set to the verification database.

[0111] It should be noted that the "first service" refers to any one of at least one service. Each service can be considered the first service, and based on its corresponding first filtering rule, the first user identifier set corresponding to the first service is determined. The verification database is a database that stores the user identifier sets corresponding to each service; that is, the verification database is used to store the user identifiers of each user that meet the restrictions of each service.

[0112] In practical applications, business systems typically have many registered users. Verification of a user's eligibility for a flash sale is only performed when a request for a specific business is received, leading to resource waste. In this application, to improve interaction efficiency, after creating at least one business, the system first filters registered users using filtering rules corresponding to each business to obtain a set of user identifiers for that business. Specifically, the set of user identifiers refers to the set of user identifiers eligible to participate in the corresponding business activity. For example, if the filtering rule is for users with a registration period of more than one year, then the set of user identifiers is the set of user identifiers with a registration period of more than one year.

[0113] For example, suppose the business party creates business A, which requires users who execute business A to have a user score of 1000 or more. Based on the filtering rule that users have a score of 1000 or more, the registered users are filtered to select users with a score of 1000 or more as target users, and the user ID of the target users is added to the user ID set corresponding to business A.

[0114] In one optional implementation of this embodiment, the first user identifier set corresponding to the first service is determined based on the first filtering rule corresponding to the first service, including:

[0115] Obtain the initial set of user identifiers and create the thread pool corresponding to the first filtering rule;

[0116] Add the user identifiers from the initial user identifier set to the filter task queue;

[0117] The thread pool reads user identifiers from the filtering task queue, filters them, and adds user identifiers that match the first filtering rule to the first user identifier set.

[0118] The initial user identifier set specifically refers to the set of user identifiers registered in the business system. A thread pool specifically refers to a multi-threaded processing method where tasks are added to a queue during processing, and these tasks are automatically started after threads are created.

[0119] The thread pool includes multiple pre-defined threads, which simultaneously process tasks related to determining the first set of user identifiers corresponding to the first business based on a first filtering rule. Each thread has the capability to process the task, but each thread has a limited request processing capacity, requiring the initial user identifiers obtained to be added to the filtering task queue. Specifically, the filtering task queue is a message queue used to store whether a user identifier matches the first set of user identifiers corresponding to the first task.

[0120] In practical applications, after obtaining the initial user identifier set, a corresponding verification request is generated based on each initial user identifier in the initial user identifier set and added to the filtering task queue. The thread pool reads the initial user identifiers sequentially from the filtering task queue for identification and filtering. User identifiers that meet the first filtering rule are added to the first user identifier set, and user identifiers that do not meet the first filtering rule are removed.

[0121] It should be noted that after filtering the initial set of user identifiers, a first set of user identifiers that meets the first filtering rule is obtained. In order to facilitate quick and efficient querying when processing subsequent retrieval requests, the obtained first set of user identifiers can be added to the verification database. Preferably, in this application, the verification database is a Redis (Remote Dictionary Server) database. Redis is a key-value storage system that supports different sorting methods. To ensure efficiency, the data in the Redis database is cached in memory, and updated data is periodically written to disk or modification operations are written to an append record file, which has high read and write characteristics.

[0122] See Figure 3a , Figure 3a This illustration shows a schematic diagram of a method for determining a set of user identifiers according to an embodiment of this application. In this embodiment, the example of a thread pool with 5 threads processing the task of determining the first set of user identifiers corresponding to a first service is explained. First, the set of user identifiers for all users already registered in the service system is obtained, i.e., the initial set of user identifiers is obtained. Simultaneously, the number of threads used to execute the task of determining this first set of user identifiers is determined to be 5, i.e., 5 threads are determined to execute the specified processing task, with each thread fixedly allocated to process 4 data items. Thus, 20 initial user identifiers can be obtained first and allocated to the 5 threads for processing. At this point, all threads are fully utilized, maximizing resource utilization. Subsequent tasks, due to the lack of idle threads, are added to the filtering task queue for processing. In practical applications, the processing capabilities of the 5 threads are not entirely the same; some execute quickly, while others execute slowly. Threads that finish processing first can continue to read new initial user identifiers from the filtering task queue for processing, calculating user identifiers that meet the conditions. Finally, the user identifier set after matching and filtering is saved to the Redis database along with the business identifier of the first business. With only one time-consuming calculation operation, it is not necessary to verify whether the user is qualified for the task again when the user receives the task, which greatly improves the system throughput.

[0123] It should be noted that the above steps can achieve data preheating, determine the user identifier set corresponding to each business created by the business party, and store each user identifier set in the verification database for subsequent verification.

[0124] In one optional implementation of this embodiment, after the business party creates at least one business through the business system, the user can choose to obtain the business they are interested in. At this time, a corresponding task to be generated can be generated and stored in the business system. That is, after creating at least one corresponding business according to the creation request and before obtaining the task to be processed, the following may also be included:

[0125] Receive user requests for specific services;

[0126] Based on the request, generate a task to be processed corresponding to the target business, wherein the task to be processed carries a corresponding processing time limit.

[0127] Specifically, the target service can refer to the service selected by the user from at least one pre-created service. It should be noted that users can select a target service of interest from at least one pre-created service, initiate a corresponding retrieval request to obtain the target service, and after successful retrieval, the service system can generate a pending task corresponding to the target service, each task carrying a corresponding processing time limit.

[0128] In practical applications, the business system can also display all pending tasks and their parameters. These parameters can include task type, task unit price (i.e., the reward for processing the pending task), task assignment time, task retrieval time (i.e., task processing time limit), and the number of tasks remaining, so that users can determine the progress of the task based on the displayed information.

[0129] Example, Figure 3b This is a schematic diagram of a task to be processed provided in an embodiment of this specification, such as... Figure 3b As shown, the tasks to be processed are annotation tasks, including: machine prediction answer top 10 rating and Test A. Among them, the machine prediction answer top 10 rating task displays the task type (annotation / text / reading comprehension), task unit price (1 yuan / item), collection time (2021-11-01, 13:53), collection time (2021-11-01, 14:53), and remaining files (1) below; the Test A task displays the task type (annotation / text / translation evaluation), task unit price (- yuan / item), collection time (2021-10-13, 14:06), collection time (2021-10-13, 15:06), and remaining files (1).

[0130] It should be noted that the task parameters of each pending task clearly show how many tasks remain unprocessed. If tens of thousands of users simultaneously generate corresponding pending tasks (such as annotation tasks) from the labeling business at different time periods, then the task data corresponding to these users' pending tasks will be processed. This process has high real-time requirements. If the storage database is frequently requested once per second to query which tasks are about to expire, along with numerous business processing tasks, the business system may immediately become sluggish or even crash.

[0131] Therefore, in this embodiment, the business system monitors the processing time limits of each pending task in the first buffer database, filters out expired tasks, and then does not immediately write each filtered expired task into the second buffer database. Instead, like a funnel, it retrieves a preset number of expired tasks from the first buffer database every preset time interval and writes them into the second buffer database, thereby reducing the processing pressure on the business system. That is, the high-performance asynchronous processing solution for pending tasks supports concurrent operations of a high number of pending tasks.

[0132] In one optional implementation of this embodiment, the user can select a target service of interest from various services created by the service provider. However, since target services have corresponding restrictions, the user can also perform a validity check on the initiated target service acquisition request to determine whether the request is valid before deciding whether to execute it. That is, the acquisition request carries task request parameters; based on the acquisition request, a task to be processed corresponding to the target service is generated, including:

[0133] Based on the task request parameters, verify the validity of the request in the validation database;

[0134] If the request is determined to be valid, a task to be processed corresponding to the target business is generated based on the request.

[0135] Specifically, task request parameters can refer to information related to the user-initiated retrieval request, such as user identifier, business identifier, request timestamp, etc. It should be noted that the verification database stores a set of user identifiers corresponding to each business—that is, a set of users who can pass verification for each business. Therefore, based on the task request parameters, the validity of the retrieval request can be verified in the verification database. If the retrieval request is determined to be valid, it is then executed, generating a pending task corresponding to the target business. This signifies that the user has successfully retrieved the target business, and a corresponding pending task can be generated for that user. The processing deadline of this pending task can then be monitored.

[0136] In the embodiments described in this specification, after receiving a request for the target service, it is necessary to verify the validity of the request. In practical applications, the validity of the request can be verified in a verification database. Invalid requests can be eliminated, thus avoiding the execution of invalid requests, reducing access volume, and improving business processing efficiency.

[0137] In an optional implementation of this embodiment, after data preheating in the above steps, a set of user identifiers that meet the filtering rules corresponding to the target service has been obtained and stored in a verification database. Therefore, the acquisition request can be verified through the user identifiers. That is, the verification database includes at least one set of user identifiers corresponding to the service. The user identifier set includes each user identifier that conforms to the first filtering rule of the corresponding service. According to the task request parameters, the validity of the acquisition request is verified in the verification database, including:

[0138] Obtain the target user identifier corresponding to the request from the task request parameters;

[0139] Determine if the target user identifier exists in the user identifier set corresponding to the target business;

[0140] If so, then the request is considered a valid request;

[0141] If not, then the request is determined to be invalid.

[0142] Specifically, the task request parameters refer to the parameters related to the retrieval request carried in the retrieval request. These include the user identifier corresponding to the user initiating the retrieval request; specifically, the target user identifier is the user identifier that initiated the retrieval request. For example, if user Zhang San issues a retrieval request for target service A, then the target user identifier corresponding to this retrieval request is "Zhang San".

[0143] After obtaining the target user identifier corresponding to the request from the task parameter request, it is necessary to determine whether the target user identifier exists in the user identifier set corresponding to the target business in the verification data. Specifically, each user identifier set stored in the verification database carries a corresponding business identifier. At this point, the user identifier set corresponding to the target business can be found in the verification database based on the business identifier of the target business. Then, the target user identifier is queried in the found user identifier set. If the target user identifier is stored in the user identifier set, it means that the target user identifier is qualified to participate in the target business, and the request can be preliminarily determined to be a valid request. If the target user identifier is not in the user identifier set, it means that the target user identifier is not qualified to participate in the target business, and the request is invalid.

[0144] In an optional implementation of this embodiment, after obtaining the target user identifier corresponding to the request from the task request parameters, the method further includes:

[0145] Verify whether the target user identifier is a registered user;

[0146] If so, determine whether the target user identifier exists in the user identifier set corresponding to the target business;

[0147] If not, then the request is determined to be invalid.

[0148] Specifically, before determining whether the target user identifier is in the user identifier set corresponding to the target service, it's also possible to first determine whether the target user identifier is a registered user of the task system. For example, in some malicious attack requests, attackers might spoof user identifiers and first verify whether the target user identifier is a registered user (including the target user's login period). Only if the target user identifier is a registered user (or the current login status is successful) will the attacker further verify whether the target user identifier is in the user identifier set corresponding to the target service, thus further validating the retrieval request. If the target user identifier is not a registered user, or the login status is logged out, the retrieval request can be directly determined as invalid, without needing to further verify whether the target user identifier is in the user identifier set corresponding to the target service.

[0149] In an optional implementation of this embodiment, the data processing method further includes a pre-loaded Bloom filter to filter out obviously abnormal acquisition requests. That is, the method also includes:

[0150] Obtain the target business identifier corresponding to the request from the task request parameters;

[0151] Determine whether the target business identifier conforms to the preset identifier rules;

[0152] If so, then the request is considered a valid request;

[0153] If not, then the request is determined to be invalid.

[0154] In practice, a Bloom filter can be used to determine whether the target business identifier conforms to a preset identifier rule. This preset identifier rule can be a rule that is pre-set in the Bloom filter to verify the target business identifier.

[0155] It's important to note that Bloom filters have two characteristics: data that doesn't exist in the filter definitely doesn't exist in the database; and data that exists in the filter has a certain probability of not existing in the database. For example, if the business identifier of a business created in the business system is an 8-digit number, and the target business identifier in the task request parameters of a retrieval request includes letters, then this retrieval request does not meet the filtering rules of the Bloom filter and can be terminated. Bloom filters can initially filter out obviously abnormal retrieval requests, reducing the processing load on the business system.

[0156] In practical applications, the filtering precision of a Bloom filter can be set by the business side according to actual needs. That is, the business side can configure preset identification rules. Higher filtering precision results in higher performance consumption, while lower filtering precision results in lower performance consumption. The Bloom filter is pre-configured, and when a request arrives, it can perform initial filtering to remove obviously abnormal requests. The Bloom filter can be configured with business identifier filtering conditions, specifying the identification rules for the business identifiers, i.e., preset identification rules. After receiving a request, the target task identifier in the task request parameters of the request is retrieved, and it is determined whether the target task identifier meets the preset identification rules. If it does, the request is initially determined to be a valid request; otherwise, it is determined to be an invalid request.

[0157] For example, the Bloom filter sets the task identifier to a 12-digit number. After parsing the retrieved request, the target task identifier in the retrieved request parameters is found to be an 8-digit number. After filtering by the Bloom filter, this indicates that the retrieved request is invalid.

[0158] In another example, the Bloom filter sets the task identifier to a 12-digit numeric identifier, where the first 4 digits are the year identifier. In the task request parameters of the retrieved request, although the target task identifier is a 12-digit numeric identifier, the first 4 digits are not the year identifier, so it can also be determined that the retrieved request is an invalid request.

[0159] In another example, the Bloom filter sets the task identifier to a 12-digit numeric identifier, where the first 4 digits are the year identifier, the 5th and 6th digits are the month identifier, and the 7th to 12th digits are the serial number. In the task request parameters of the retrieved request, the naming of the target task identifier conforms to the rules in the Bloom filter, so it can be preliminarily determined that the retrieved request is a valid request.

[0160] It is important to note that the order of valid verification in the above judgment process is not restricted. The request can be verified first based on the target user identifier carried in the request, and then based on the target business identifier carried in the request; alternatively, the request can be verified first based on the target business identifier carried in the request, and then based on the target user identifier carried in the request. Only when each verification passes can the request be determined as a valid request.

[0161] Step 204: If the number of expired tasks included in the second buffer database exceeds the load threshold of the storage database, retrieve the first expired task with the load threshold from the second buffer database, and process the corresponding data in the storage database according to the first expired task.

[0162] Specifically, the load threshold refers to the number of data items that the storage database can currently process while ensuring its normal operation. This load threshold is used to determine the number of data items that can be processed in the storage database at any given time; for example, the load threshold could be 10, 20, 30, etc. Additionally, the first expired task is any expired task included in the second buffer database. Furthermore, the first expired task refers to any expired task that the storage database can currently process; that is, the corresponding data in the storage database can be processed based on the first expired task.

[0163] It should be noted that after a preset number of due tasks are retrieved from the first buffer database and written to the second buffer database at preset intervals, the second buffer database can store multiple due tasks. At this point, the data corresponding to each due task in the storage database needs to be cleared to free up storage space. In practical applications, the second buffer database may store a large number of due tasks, but the storage database has limited processing capacity. If all the data corresponding to the due tasks in the second buffer database are processed simultaneously, it may cause excessive processing pressure on the business system and the storage database, potentially leading to system crashes.

[0164] Therefore, in this embodiment of the specification, if the number of due tasks included in the second buffer database exceeds the load threshold of the storage database, it indicates that the number of due tasks included in the second buffer database exceeds the processing capacity of the storage database. In this case, only the load threshold number of first due tasks is retrieved from the second buffer database, and the corresponding data in the storage database is processed based on the first due tasks. In this way, the number of data items processed by the storage database can be flexibly determined based on the current load capacity of the storage database, avoiding the simultaneous processing of due tasks exceeding the load threshold in the storage database, reducing the processing pressure on the business system and the storage database, and preventing the business system and the storage database from crashing.

[0165] In one optional implementation of this embodiment, when processing the data corresponding to the expired tasks in the storage database, it can be done asynchronously using multiple threads. That is, the data in the storage database is processed according to the first expired task. The specific implementation process can be as follows:

[0166] Create at least two threads and determine the number of tasks to be processed for each thread;

[0167] Based on the number of tasks to be processed by each thread, each first-expiring task is assigned to at least two threads;

[0168] The corresponding data in the storage database is processed using at least two threads based on the first expiration task.

[0169] It should be noted that the first due task is the task that needs to be processed in the storage database. During processing, at least two threads can be created, each handling a certain number of due tasks. This determines the number of tasks each thread can handle. Subsequently, based on the task count for each thread, each first due task is assigned to one of the at least two threads. These threads then process the corresponding data in the storage database based on their assigned first due tasks. In this way, the first due tasks only need to be queued and processed on their assigned threads. Multi-threaded asynchronous concurrent processing of the first due tasks improves processing efficiency.

[0170] In one optional implementation of this embodiment, the expired task is a task that has reached its operation time limit but the user has not performed any operation. Therefore, it is necessary to delete the data corresponding to the expired task from the storage database. That is, the data in the storage database is processed according to the first expired task. The specific implementation process can be as follows:

[0171] Search the storage database for the target data corresponding to the first due task;

[0172] Delete the target data from the storage database and return a task due date reminder to the user corresponding to the first due task.

[0173] It should be noted that for each first-expiring task, the target data corresponding to the first-expiring task can be found in the storage database, the target data can be deleted from the storage database, and a task expiration reminder can be returned to the user corresponding to the first-expiring task, thereby reminding the user that the task has expired and deleting the data corresponding to the expired task from the storage database to avoid occupying too much storage space.

[0174] Step 206: Determine the second expired task in the second buffer database, excluding the first expired task, and mark the second expired task as expired. The expiration mark is used to indicate that the corresponding data of the second expired task in the storage database is prohibited from operation.

[0175] It should be noted that the first expired task refers to the expired task that the current storage database can process. The second expired task in the second buffer database, excluding the first expired task, is the expired task that exceeds the current load threshold of the storage database and cannot be processed by the storage database at present, requiring delayed processing. However, the second expired task has also reached its task processing time limit. If the corresponding data in the storage database is not deleted in time, it may cause users to continue to operate on expired tasks, which may lead to chaos in the business system.

[0176] Therefore, in this embodiment of the specification, for second-expiring tasks that have not yet been processed by the storage database due to exceed its current load threshold, an expiration mark can be made. This expiration mark is used to indicate that the data corresponding to the second-expiring task in the storage database is prohibited from operation. In other words, although the storage database still stores the data corresponding to the second-expiring task, the user cannot operate on that data, thus ensuring the accuracy of processing delayed-processing of expired tasks.

[0177] In one optional implementation of this embodiment, expiration marking can be performed using a first buffer database, that is, expiration marking can be performed on the second expiring task. The specific implementation process can be as follows:

[0178] Record the second expiring task in the first buffer database and mark it as expired.

[0179] It should be noted that the second expired task can be recorded in the first buffer database and marked as expired. This marks the data corresponding to the second expired task in the storage database as prohibited from operation, thus ensuring the accuracy of processing the expired task in the delayed processing.

[0180] In an optional implementation of this embodiment, after a user initiates a task processing request, the user can first query the first buffer database to see if an expiration flag exists, thereby determining whether the task is currently a processable task. That is, the method further includes:

[0181] Receive operation requests initiated by users for target tasks;

[0182] Search for the target task in the first buffer database;

[0183] If the target task is found, it is determined to be an overdue task, and an operation failure notification message is returned.

[0184] Specifically, the target task refers to the task the user currently wants to perform an operation on. In practical applications, when a user wants to perform an operation on a target task, they can initiate an operation request for that target task. After receiving the operation request, the business system can first search for the target task in the first buffer database. If the target task is found, it means that the target task the user wanted to operate on has expired, i.e., the target task is an expired task. At this time, an operation failure reminder message can be returned to the user to remind them that the target task has expired. In this way, expired tasks that have not yet been processed can be marked as expired, ensuring that users cannot operate on data that has expired and has not yet been processed in the storage database, thus ensuring the accuracy of processing expired tasks with delays.

[0185] In an optional implementation of this embodiment, the second expired task that has not yet been processed still needs to continue processing the data corresponding to the second expired task in the storage database when the storage database has processing capabilities. That is, after marking the second expired task as expired, it may also include:

[0186] After the data in the storage database corresponding to the first due task has been processed, the second due task is obtained based on the load threshold and used as the first due task. The data in the storage database corresponding to the current first due task is then processed until all the second due tasks have been processed.

[0187] Specifically, when continuing to obtain the second due task as the first due task based on the load threshold, if the number of second due tasks is greater than or equal to the load threshold, then the load threshold number of second due tasks can be obtained as the first due task; if the number of second due tasks is less than the load threshold, then each of the current second due tasks can be used as the first due task.

[0188] In practical applications, each time the first expired task with a load threshold can be selected from the second buffer data. Based on the first expired task, the corresponding data in the storage database is processed. After the processing is completed, based on the load threshold, the second expired task can be selected from the remaining expired tasks (i.e., the second expired task) in the second buffer database as the first expired task. The corresponding data in the storage database is processed based on the first expired task, and so on, until all the expired tasks in the second buffer database are processed.

[0189] It should be noted that, after obtaining the second expiring task as the first expiring task based on the load threshold and processing the corresponding data in the storage database according to the current first expiring task, since the second expiring task was previously marked as expired to prevent user operation if the corresponding data in the storage database is not deleted in the future, after obtaining the second expiring task as the first expiring task and processing the corresponding data in the storage database, the data corresponding to the second expiring task no longer exists in the storage database. Therefore, the expiration mark for the second expiring task in the first buffer database can be deleted at this time to save storage space in the first buffer database.

[0190] The data processing method provided in this application allows the business system to temporarily store tasks corresponding to various user-generated data in a first buffer database. The business system can monitor each task temporarily stored in the first buffer database and retrieve a preset number of due tasks from the first buffer database every preset time interval, writing them to a second buffer database. That is, the second buffer database stores due tasks that require processing of the corresponding data in the storage database. At this point, based on the current load threshold of the storage database, the number of due tasks to process at one time can be determined. Only the corresponding number of due tasks are retrieved from the second buffer database for processing. Thus, based on the load threshold of the storage database, the due tasks stored in the second buffer database are processed sequentially. Due tasks that have not yet been processed can be marked as due, preventing user operation on the data corresponding to these due tasks in the storage database. In this way, through two buffer databases, due tasks are delayed, and due tasks that have not yet been processed can be marked as due, ensuring that users cannot operate on data in the storage database that has expired and has not yet been processed. This delays due tasks, avoids frequent database operations by the business system, reduces the processing pressure on the business system and the storage database, and ensures the accuracy of delayed due task processing.

[0191] Figure 4 A flowchart of a second data processing method according to an embodiment of this application is shown, which specifically includes the following steps:

[0192] Step 402: Receive a creation request for at least one service, wherein the creation request carries the processing time limit of the corresponding service; create at least one corresponding service according to the creation request.

[0193] Step 404: Receive the user's acquisition request for the target service, and generate a task to be processed corresponding to the target service based on the acquisition request. The task to be processed carries the corresponding processing time limit.

[0194] It should be noted that in this embodiment, the business system receives at least one business creation request and a user's acquisition request for the target business. The user can select the target business of interest from at least one pre-created business and initiate the corresponding acquisition request to obtain the target business. After the user successfully acquires the target business, the business system can generate a pending task corresponding to the target business. The pending task can be a task that the user needs to complete before the processing time limit, and each pending task carries a corresponding processing time limit.

[0195] Step 406: Obtain the generated tasks to be processed, store the obtained tasks to be processed and their corresponding processing time limits in the first buffer database, monitor the processing time limits of each task to be processed in the first buffer database, and determine the tasks that have expired from each task to be processed.

[0196] It should be noted that in this embodiment, the business system can obtain the generated tasks to be processed, create a monitoring thread, store the tasks to be processed and their corresponding processing time limits in the first buffer database, and then monitor the processing time limits of each task to be processed in the first buffer database through the monitoring thread, and determine the due tasks from each task to be processed.

[0197] Step 408: Retrieve a preset number of due tasks from the first buffer database every preset duration and write them to the second buffer database.

[0198] Step 410: If the number of expired tasks included in the second buffer database exceeds the load threshold of the storage database, retrieve the first expired task with the load threshold from the second buffer database, and process the corresponding data in the storage database according to the first expired task.

[0199] It should be noted that in this embodiment, the business system can continue to execute steps 408 and 410. Considering that the second buffer database may store a large number of expired tasks, but the processing capacity of the storage database is limited, if all the data corresponding to the expired tasks in the second buffer database are processed in the storage database at the same time, it may cause the processing pressure of the business system and the storage database to be too great, which may lead to the business system and the storage database crashing.

[0200] Therefore, in practical applications, if the number of expired tasks in the second buffer database exceeds the load threshold of the storage database, it indicates that the number of expired tasks in the second buffer database exceeds the processing capacity of the storage database. In this case, only the load threshold number of first expired tasks is retrieved from the second buffer database, and the corresponding data in the storage database is processed based on these first expired tasks. In this way, the number of data items processed by the storage database can be flexibly determined based on its current load capacity, avoiding the simultaneous processing of expired tasks exceeding the load threshold in the storage database, reducing the processing pressure on both the business system and the storage database, and preventing downtime for both systems.

[0201] For example, suppose the load threshold of the storage database is 500, and the second buffer database contains 600 expired tasks (e.g., when a preset time is reached, a preset number of expired tasks are retrieved from the first buffer database and written to the second buffer database, so the second buffer database contains 600 expired tasks). If the number of expired tasks in the second buffer database exceeds the load threshold, then 500 first expired tasks can be retrieved from the second buffer database, and the corresponding data in the storage database can be processed based on these 500 first expired tasks.

[0202] In addition, if the number of expired tasks in the second buffer database is less than the load threshold, then each of the currently expired tasks included in the second buffer database can be used as the first expired task, and the corresponding data in the storage database can be processed according to the current first expired task.

[0203] For example, suppose the load threshold of the storage database is 500, and the second buffer database contains 300 expired tasks. If the number of expired tasks in the second buffer database is less than the load threshold, then the 300 expired tasks in the second buffer database can be used as the first expired tasks, and the corresponding data in the storage database can be processed based on these 300 first expired tasks.

[0204] In one optional implementation of this embodiment, the expired task is a task that has reached its operation time limit but the user has not performed any operation. Therefore, it is necessary to delete the data corresponding to the expired task from the storage database. That is, the data in the storage database is processed according to the first expired task. The specific implementation process can be as follows:

[0205] Search the storage database for the target data corresponding to the first due task;

[0206] Delete the target data from the storage database and return a task due date reminder to the user corresponding to the first due task.

[0207] In one optional implementation of this embodiment, when processing the data corresponding to the expired tasks in the storage database, it can be done asynchronously using multiple threads. That is, the data in the storage database is processed according to the first expired task. The specific implementation process can be as follows:

[0208] Create at least two threads and determine the number of tasks to be processed for each thread;

[0209] Based on the number of tasks to be processed by each thread, each first-expiring task is assigned to at least two threads;

[0210] The corresponding data in the storage database is processed using at least two threads based on the first expiration task.

[0211] Step 412: Determine the second expired task in the second buffer database, other than the first expired task. Record the second expired task in the first buffer database and mark it as expired. The expiration mark is used to indicate that the corresponding data of the second expired task in the storage database is prohibited from operation.

[0212] Step 414: After the data in the storage database corresponding to the first due task has been processed, the second due task is obtained based on the load threshold and used as the first due task. The data in the storage database corresponding to the current first due task is then processed until all the second due tasks have been processed.

[0213] It should be noted that in this embodiment, the business system can continue to execute steps 412 and 414. The second buffer database may store a large number of expired tasks. Each time, the first expired tasks with a load threshold can be selected from the second buffer data. The corresponding data in the storage database is processed according to the first expired tasks. After the processing is completed, the second expired tasks can be obtained from the remaining expired tasks (i.e., the second expired tasks) in the second buffer database based on the load threshold as the first expired tasks. The corresponding data in the storage database is processed according to the first expired tasks. This process is repeated until all the expired tasks in the second buffer database have been processed.

[0214] Specifically, when continuing to obtain second due tasks as first due tasks based on the load threshold, if the number of second due tasks is greater than or equal to the load threshold, then load threshold number of second due tasks can be obtained as first due tasks; if the number of second due tasks is less than the load threshold, then each of the current second due tasks can be used as a first due task.

[0215] In practical applications, if the number of remaining expired tasks in the second buffer database (i.e., the number of second expired tasks) still exceeds the load threshold, then more second expired tasks can be obtained as first expired tasks based on the load threshold. The corresponding data in the storage database is then processed according to the current first expired tasks until all second expired tasks are completed. Conversely, if the number of remaining expired tasks in the second buffer database is less than the load threshold, then all remaining second expired tasks in the second buffer database can be used as first expired tasks, and the corresponding data in the storage database is processed according to the current first expired tasks.

[0216] For example, suppose the load threshold of the storage database is 500, and the second buffer database contains 1200 due tasks. If the number of due tasks in the second buffer database exceeds the load threshold, then 500 first due tasks can be retrieved from the second buffer database, and the remaining 700 due tasks are marked as second due tasks. The corresponding data in the storage database is then processed based on these 500 first due tasks. After processing, since the number of second due tasks (i.e., the remaining due tasks) in the second buffer database still exceeds the load threshold, another 500 second due tasks can be retrieved from the second buffer database as first due tasks, and the corresponding data in the storage database is processed based on these 500 first due tasks. After processing, since the number of second due tasks in the second buffer database is less than the load threshold, the remaining 200 second due tasks can be designated as first due tasks, and the corresponding data in the storage database is processed based on these 200 first due tasks.

[0217] Step 416: Receive the user's operation request for the target task, search for the target task in the first buffer database, and if the target task is found, determine that the target task is an expired task and return an operation failure reminder message.

[0218] Using the example above, step 416 can still involve the business system receiving the user's operation request for the target task.

[0219] The data processing method provided in this application allows the business system to temporarily store tasks corresponding to various user-generated data in a first buffer database. The business system can monitor each task temporarily stored in the first buffer database and retrieve a preset number of due tasks from the first buffer database every preset time interval, writing them to a second buffer database. That is, the second buffer database stores due tasks that require processing of the corresponding data in the storage database. At this point, based on the current load threshold of the storage database, the number of due tasks to process at one time can be determined. Only the corresponding number of due tasks are retrieved from the second buffer database for processing. Thus, based on the load threshold of the storage database, the due tasks stored in the second buffer database are processed sequentially. Due tasks that have not yet been processed can be marked as due, preventing user operation on the data corresponding to these due tasks in the storage database. In this way, through two buffer databases, due tasks are delayed, and due tasks that have not yet been processed can be marked as due, ensuring that users cannot operate on data in the storage database that has expired and has not yet been processed. This delays due tasks, avoids frequent database operations by the business system, reduces the processing pressure on the business system and the storage database, and ensures the accuracy of delayed due task processing.

[0220] The above is an illustrative scheme of a data processing method according to this embodiment. It should be noted that the technical solution of the data processing method here is the same as that described above. Figure 1 The technical solutions for the data processing methods shown belong to the same concept. Details not described in detail here can be found in the above-mentioned... Figure 1 The technical solution of the data processing method shown is described.

[0221] Figure 5 A flowchart of a third data processing method according to an embodiment of this application is shown, which specifically includes the following steps:

[0222] Step 502: Obtain the tasks to be processed, wherein each task carries a corresponding processing time limit; store the tasks to be processed and their corresponding processing time limits in the first buffer database; monitor the processing time limits corresponding to each task to be processed in the first buffer database, and determine the tasks that have expired from each task to be processed.

[0223] Step 504: Retrieve a preset number of due tasks from the first buffer database every preset duration and write them to the second buffer database.

[0224] Step 506: If the number of expired tasks included in the second buffer database exceeds the load threshold of the storage database, retrieve the first expired task with the load threshold from the second buffer database, and process the corresponding data in the storage database according to the first expired task.

[0225] Step 508: Determine the second expired task in the second buffer database, excluding the first expired task, and mark the second expired task as expired. The expiration mark is used to indicate that the corresponding data of the second expired task in the storage database is prohibited from operation.

[0226] The data processing method provided in this application allows the business system to store the acquired tasks to be processed and their corresponding processing time limits in a first buffer database, monitor the processing time limits of each task to be processed in the first buffer database, filter out expired tasks, and thus accurately monitor the processing of each task to be processed in the first buffer database.

[0227] The above is an illustrative scheme of a data processing method according to this embodiment. It should be noted that the technical solution of the data processing method here is the same as that described above. Figure 1 The technical solutions for the data processing methods shown belong to the same concept. Details not described in detail here can be found in the above-mentioned... Figure 1 The technical solution of the data processing method shown is described.

[0228] Figure 6 A flowchart of a fourth data processing method according to an embodiment of this application is shown, which specifically includes the following steps:

[0229] Step 602: Receive a creation request for at least one service, wherein the creation request carries the processing time limit of the corresponding service; create at least one corresponding service according to the creation request.

[0230] Step 604: Receive the user's acquisition request for the target service, and generate a task to be processed corresponding to the target service based on the acquisition request. The task to be processed carries the corresponding processing time limit.

[0231] The data processing method provided in this application allows business users to pre-create at least one business through their business system and set custom processing time limits for each business. This means different businesses can have different processing time limits, increasing the flexibility of business time limit requirements. Users can select a target business of interest from the pre-created at least one business and initiate a corresponding retrieval request to obtain the target business. After successful retrieval, a pending task corresponding to the target business is generated, and each pending task carries a corresponding processing time limit, increasing the accuracy of time limit monitoring.

[0232] The above is an illustrative scheme of a data processing method according to this embodiment. It should be noted that the technical solution of the data processing method here is the same as that described above. Figure 1The technical solutions for the data processing methods shown belong to the same concept. Details not described in detail here can be found in the above-mentioned... Figure 1 The technical solution of the data processing method shown is described.

[0233] Figure 7 A flowchart of a fifth data processing method according to an embodiment of this application is shown, which specifically includes the following steps:

[0234] Step 702: Retrieve a preset number of due tasks from the first buffer database every preset duration and write them to the second buffer database.

[0235] Step 704: If the number of expired tasks included in the second buffer database exceeds the load threshold of the storage database, retrieve the first expired task with the load threshold from the second buffer database, and process the corresponding data in the storage database according to the first expired task.

[0236] Step 706: Determine the second expired task in the second buffer database, other than the first expired task. Record the second expired task in the first buffer database and mark it as expired. The expiration mark is used to indicate that the corresponding data of the second expired task in the storage database is prohibited from operation.

[0237] The data processing method provided in this application can record the second due task in the first buffer database and mark it for expiration, thereby prohibiting operations on the corresponding data of the second due task in the storage database, which ensures the accuracy of processing the due task in the delayed processing.

[0238] The above is an illustrative scheme of a data processing method according to this embodiment. It should be noted that the technical solution of the data processing method here is the same as that described above. Figure 1 The technical solutions for the data processing methods shown belong to the same concept. Details not described in detail here can be found in the above-mentioned... Figure 1 The technical solution of the data processing method shown is described.

[0239] Figure 8 A flowchart of a sixth data processing method according to an embodiment of this application is shown, which specifically includes the following steps:

[0240] Step 802: Receive the operation request initiated by the user for the target task.

[0241] Step 804: Search for the target task in the first buffer database. If the target task is found, determine that the target task is an expired task and return an operation failure reminder message.

[0242] Step 806: If the target task is not found, perform operations on the data corresponding to the target task in the storage database based on the operation request, and return the operation result.

[0243] The data processing method provided in this application can mark expired tasks that have not yet been processed, ensuring that users cannot operate on expired data that has not yet been processed in the storage database, thus guaranteeing the accuracy of processing expired tasks with delays.

[0244] The above is an illustrative scheme of a data processing method according to this embodiment. It should be noted that the technical solution of the data processing method here is the same as that described above. Figure 1 The technical solutions for the data processing methods shown belong to the same concept. Details not described in detail here can be found in the above-mentioned... Figure 1 The technical solution of the data processing method shown is described.

[0245] Figure 9 A flowchart of a seventh data processing method according to an embodiment of this application is shown, which specifically includes the following steps:

[0246] Step 902: Create at least two threads and determine the number of tasks to be processed for each thread.

[0247] Step 904: Based on the number of tasks to be processed for each thread, assign each first-expiring task to at least two threads.

[0248] Step 906: Process the corresponding data in the storage database using at least two threads, based on the corresponding first due task.

[0249] The data processing method provided in this application defines the first due task as the task currently requiring processing in the storage database. During processing, at least two threads can be created, each handling a certain number of due tasks. This determines the task processing quantity for each thread. Subsequently, based on the task processing quantity for each thread, each first due task is assigned to one of the at least two threads. These at least two threads then process the corresponding data in the storage database based on their respective first due tasks. In this way, the first due tasks only need to be queued and processed on their assigned threads, enabling asynchronous concurrent processing of the first due tasks by multiple threads, thus improving the processing efficiency of the first due tasks.

[0250] The above is an illustrative scheme of a data processing method according to this embodiment. It should be noted that the technical solution of the data processing method here is the same as that described above. Figure 1 The technical solutions for the data processing methods shown belong to the same concept. Details not described in detail here can be found in the above-mentioned... Figure 1The technical solution of the data processing method shown is described.

[0251] Figure 10 A flowchart of an eighth data processing method according to an embodiment of this application is shown, which specifically includes the following steps:

[0252] Step 1002: Retrieve a preset number of due tasks from the first buffer database every preset duration and write them to the second buffer database.

[0253] Step 1004: If the number of expired tasks included in the second buffer database exceeds the load threshold of the storage database, retrieve the first expired task with the load threshold from the second buffer database.

[0254] Step 1006: Locate the target data corresponding to the first due task in the storage database, delete the target data from the storage database, and return a task due reminder to the user corresponding to the first due task.

[0255] Step 1008: Determine the second expired task in the second buffer database, excluding the first expired task, and mark the second expired task as expired. The expiration mark is used to indicate that the corresponding data of the second expired task in the storage database is prohibited from operation.

[0256] The data processing method provided in this application, for each first expired task, can search for the target data corresponding to the first expired task in the storage database, delete the target data from the storage database, and return a task expiration reminder to the user corresponding to the first expired task, thereby reminding the user that the task has expired and deleting the data corresponding to the expired task in the storage database to avoid occupying too much storage space.

[0257] The above is an illustrative scheme of a data processing method according to this embodiment. It should be noted that the technical solution of the data processing method here is the same as that described above. Figure 1 The technical solutions for the data processing methods shown belong to the same concept. Details not described in detail here can be found in the above-mentioned... Figure 1 The technical solution of the data processing method shown is described.

[0258] Figure 11 A flowchart of a ninth data processing method according to an embodiment of this application is shown, which specifically includes the following steps:

[0259] Step 1102: Retrieve a preset number of due tasks from the first buffer database every preset duration and write them to the second buffer database.

[0260] Step 1104: If the number of expired tasks included in the second buffer database exceeds the load threshold of the storage database, retrieve the first expired task with the load threshold from the second buffer database, and process the corresponding data in the storage database according to the first expired task.

[0261] Step 1106: Determine the second expired task in the second buffer database, excluding the first expired task, and mark the second expired task as expired. The expiration mark is used to indicate that the corresponding data of the second expired task in the storage database is prohibited from operation.

[0262] Step 1108: After the data in the storage database corresponding to the first due task has been processed, the second due task is obtained based on the load threshold and used as the first due task. The data in the storage database corresponding to the current first due task is then processed until all the second due tasks have been processed.

[0263] The data processing method provided in this application continues to obtain a second expired task as the first expired task based on the load threshold. After processing the corresponding data in the storage database according to the current first expired task, since the second expired task was previously marked as expired to prevent user operation if the corresponding data in the storage database is not deleted in the future, the second expired task is obtained as the first expired task. After processing the corresponding data in the storage database, the data corresponding to the second expired task no longer exists in the storage database. Therefore, the expiration mark of the second expired task in the first buffer database can be deleted at this time to save the storage space of the first buffer database.

[0264] The above is an illustrative scheme of a data processing method according to this embodiment. It should be noted that the technical solution of the data processing method here is the same as that described above. Figure 1 The technical solutions for the data processing methods shown belong to the same concept. Details not described in detail here can be found in the above-mentioned... Figure 1 The technical solution of the data processing method shown is described.

[0265] Corresponding to the above method embodiments, this application also provides data processing apparatus embodiments. Figure 12 A schematic diagram of the structure of a data processing apparatus according to an embodiment of this application is shown. Figure 12 As shown, the device includes:

[0266] The write module 1202 is configured to retrieve a preset number of due tasks from the first buffer database and write them to the second buffer database every preset time interval.

[0267] The processing module 1204 is configured to, when the number of expired tasks included in the second buffer database exceeds the load threshold of the storage database, obtain the load threshold number of first expired tasks from the second buffer database, and process the corresponding data in the storage database according to the first expired tasks;

[0268] The marking module 1206 is configured to identify a second expired task in the second buffer database, other than the first expired task, and to mark the second expired task as expired. The expiration mark is used to indicate that the corresponding data of the second expired task in the storage database is prohibited from operation.

[0269] Optionally, the device further includes a first acquisition module configured to:

[0270] Retrieve tasks to be processed, each task carrying a corresponding processing time limit;

[0271] Store the tasks to be processed and their corresponding processing time limits in the first buffer database;

[0272] Monitor the processing time limits of each pending task in the first buffer database, and determine the expired tasks from each pending task.

[0273] Optionally, the first acquisition module is further configured as follows:

[0274] Receive at least one service creation request, wherein the creation request carries the processing time limit of the corresponding service;

[0275] Based on the creation request, create at least one corresponding business;

[0276] Receive user requests for specific business functions and generate corresponding pending tasks based on the requests. Each pending task carries a corresponding processing time limit.

[0277] Optionally, the marking module 1206 is further configured to:

[0278] Record the second expiring task in the first buffer database and mark it as expired.

[0279] Optionally, the device also includes a lookup module configured to:

[0280] Receive operation requests initiated by users for target tasks;

[0281] Search for the target task in the first buffer database;

[0282] If the target task is found, it is determined to be an overdue task, and an operation failure notification message is returned.

[0283] Optionally, the processing module 1204 is further configured to:

[0284] Create at least two threads and determine the number of tasks to be processed for each thread;

[0285] Based on the number of tasks to be processed by each thread, each first-expiring task is assigned to at least two threads;

[0286] The corresponding data in the storage database is processed using at least two threads based on the first expiration task.

[0287] Optionally, the processing module 1204 is further configured to:

[0288] Search the storage database for the target data corresponding to the first due task;

[0289] Delete the target data from the storage database and return a task due date reminder to the user corresponding to the first due task.

[0290] Optionally, the device further includes a second acquisition module configured to:

[0291] After the data in the storage database corresponding to the first due task has been processed, the second due task is obtained based on the load threshold and used as the first due task. The data in the storage database corresponding to the current first due task is then processed until all the second due tasks have been processed.

[0292] Optionally, the request carries task request parameters; the first acquisition module is further configured as follows:

[0293] Based on the task request parameters, verify the validity of the request in the validation database;

[0294] If the request is determined to be valid, a task to be processed corresponding to the target business is generated based on the request.

[0295] Optionally, the service carries filtering rules; the first acquisition module is further configured as follows:

[0296] Based on the first filtering rule corresponding to the first service, determine the first user identifier set corresponding to the first service, wherein the first service is any one of at least one service;

[0297] Add the first user identifier set to the verification database.

[0298] Optionally, the verification database includes at least one set of user identifiers corresponding to a business, and the set of user identifiers includes each user identifier that conforms to the first filtering rule of the corresponding business; the first acquisition module is further configured to:

[0299] Obtain the target user identifier corresponding to the request from the task request parameters;

[0300] Determine if the target user identifier exists in the user identifier set corresponding to the target business;

[0301] If so, then the request is considered a valid request;

[0302] If not, then the request is determined to be invalid.

[0303] Optionally, the first acquisition module is further configured as follows:

[0304] Verify whether the target user identifier is a registered user;

[0305] If so, determine whether the target user identifier exists in the user identifier set corresponding to the target business;

[0306] If not, then the request is determined to be invalid.

[0307] Optionally, the first acquisition module is further configured as follows:

[0308] Obtain the initial set of user identifiers and create the thread pool corresponding to the first filtering rule;

[0309] Add the user identifiers from the initial user identifier set to the filter task queue;

[0310] The thread pool reads user identifiers from the filtering task queue, filters them, and adds user identifiers that match the first filtering rule to the first user identifier set.

[0311] Optionally, the first acquisition module is further configured as follows:

[0312] Obtain the target business identifier corresponding to the request from the task request parameters;

[0313] Determine whether the target business identifier conforms to the preset identifier rules;

[0314] If so, then the request is considered a valid request;

[0315] If not, then the request is determined to be invalid.

[0316] The data processing apparatus provided in this application allows the business system to temporarily store tasks corresponding to various user-generated data in a first buffer database. The business system can monitor each task temporarily stored in the first buffer database and retrieve a preset number of due tasks from the first buffer database every preset time interval, writing them to a second buffer database. That is, the second buffer database stores due tasks that require processing of the corresponding data in the storage database. At this point, based on the current load threshold of the storage database, the number of due tasks to process at one time can be determined, and only the corresponding number of due tasks are retrieved from the second buffer database for processing. Thus, based on the load threshold of the storage database, the due tasks stored in the second buffer database are processed sequentially. Due tasks that have not yet been processed can be marked as due, preventing user operation on the data corresponding to these due tasks in the storage database. In this way, through two buffer databases, due tasks are delayed, and due tasks that have not yet been processed are marked as due, ensuring that users cannot operate on data in the storage database that has expired and has not yet been processed. This delays due tasks, avoids frequent database operations by the business system, reduces the processing pressure on the business system and the storage database, and ensures the accuracy of delayed due task processing.

[0317] The above is an illustrative scheme of a data processing apparatus according to this embodiment. It should be noted that the technical solution of this data processing apparatus and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the data processing apparatus, please refer to the description of the technical solution of the data processing method described above.

[0318] Furthermore, the components in the device embodiment should be understood as functional modules necessary to implement each step of the program flow or method, and these functional modules are not actual functional divisions or separations. A device claim defined by such a set of functional modules should be understood as a functional module architecture that primarily implements the solution through the computer program described in the specification, and not as a physical device that primarily implements the solution through hardware.

[0319] Figure 13 A structural block diagram of a computing device 1300 according to an embodiment of this application is shown. The components of the computing device 1300 include, but are not limited to, a memory 1310 and a processor 1320. The processor 1320 is connected to the memory 1310 via a bus 1330, and a database 1350 is used to store data.

[0320] The computing device 1300 also includes an access device 1340, which enables the computing device 1300 to communicate via one or more networks 1360. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 1340 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0321] In one embodiment of this application, the aforementioned components of the computing device 1300 and Figure 13 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 13 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0322] The computing device 1300 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 1300 can also be a mobile or stationary server.

[0323] The processor 1320 is used to execute computer-executable instructions for data processing methods.

[0324] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the data processing method described above.

[0325] One embodiment of this application also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, are used for a data processing method.

[0326] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the data processing method described above.

[0327] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0328] Computer instructions include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0329] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0330] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0331] The preferred embodiments disclosed above are merely illustrative of this application. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this application. These embodiments are selected and specifically described in this application to better explain the principles and practical applications of this application, thereby enabling those skilled in the art to better understand and utilize this application. This application is limited only by the claims and their full scope and equivalents.

Claims

1. A data processing method, characterized in that, Applied to business systems, including: Every preset time interval, a preset number of due tasks are retrieved from the first buffer database and written to the second buffer database. The first buffer database is a database that stores each pending task generated when a user obtains a service and the processing time limit corresponding to each pending task, and is used to monitor the time limit of the pending tasks. The second buffer database is used to store the monitored due tasks. If the number of due tasks included in the second buffer database exceeds the load threshold of the storage database, the first due task of the load threshold is obtained from the second buffer database, and the corresponding data in the storage database is processed according to the first due task. The storage database refers to the database that stores the specific data corresponding to each task to be processed. Identify a second expired task in the second buffer database, other than the first expired task, and mark the second expired task as expired. The expired task is used to indicate that the data corresponding to the second expired task in the storage database is prohibited from operation.

2. The data processing method according to claim 1, characterized in that, Before the preset number of due tasks are retrieved from the first buffer database and written to the second buffer database at each preset time interval, the following steps are included: Obtain tasks to be processed, wherein the tasks to be processed carry corresponding processing time limits; Store the tasks to be processed and their corresponding processing time limits in the first buffer database; Monitor the processing time limits of each pending task in the first buffer database, and determine the expired task from each pending task.

3. The data processing method according to claim 2, characterized in that, Before acquiring the task to be processed, the process also includes: Receive at least one service creation request, wherein the creation request carries the processing time limit of the corresponding service; Based on the creation request, create at least one corresponding service; Receive a user's request for a target service, and generate a task to be processed corresponding to the target service based on the request, wherein the task to be processed carries a corresponding processing time limit.

4. The data processing method according to any one of claims 1-3, characterized in that, The step of marking the second due task as due includes: The second expired task is recorded in the first buffer database and marked as expired.

5. The data processing method according to claim 4, characterized in that, The method further includes: Receive operation requests initiated by users for target tasks; Search for the target task in the first buffer database; If the target task is found, it is determined to be an overdue task, and an operation failure notification is returned.

6. The data processing method according to any one of claims 1-3, characterized in that, The step of processing the corresponding data in the storage database according to the first due task includes: Create at least two threads and determine the number of tasks to be processed for each thread; Based on the number of tasks to be processed by each thread, each first due task is assigned to the at least two threads; The data in the storage database is processed by the at least two threads based on the corresponding first due task.

7. The data processing method according to any one of claims 1-3, characterized in that, The step of processing the corresponding data in the storage database according to the first due task includes: Search the storage database for the target data corresponding to the first due task; Delete the target data from the storage database and return a task expiration reminder to the user corresponding to the first expired task.

8. The data processing method according to claim 3, characterized in that, The acquisition request carries task request parameters; the step of generating the task to be processed corresponding to the target business based on the acquisition request includes: Based on the task request parameters, verify the validity of the acquisition request in the verification database; If the request is determined to be a valid request, a task to be processed corresponding to the target service is generated based on the request.

9. The data processing method according to claim 8, characterized in that, The verification database includes a set of user identifiers corresponding to the at least one service, and the set of user identifiers includes each user identifier that conforms to a first filtering rule of the corresponding service; the step of verifying the validity of the acquisition request in the verification database according to the task request parameters includes: Obtain the target user identifier corresponding to the acquisition request in the task request parameters; Determine whether the target user identifier exists in the user identifier set corresponding to the target service; If so, then the request is determined to be a valid request; If not, then the request is determined to be invalid.

10. The data processing method according to claim 8 or 9, characterized in that, The method further includes: Obtain the target business identifier corresponding to the acquisition request in the task request parameters; Determine whether the target service identifier conforms to the preset identifier rules; If so, then the request is determined to be a valid request; If not, then the request is determined to be invalid.

11. A data processing apparatus, characterized in that, Applied to business systems, including: The writing module is configured to retrieve a preset number of due tasks from the first buffer database every preset time interval and write them to the second buffer database. The first buffer database is a database that stores each pending task generated when a user obtains a service and the processing time limit corresponding to each pending task, and is used to monitor the time limit of the pending tasks. The second buffer database is used to store the monitored due tasks. The processing module is configured to, when the number of due tasks included in the second buffer database exceeds the load threshold of the storage database, retrieve the first due tasks from the second buffer database according to the load threshold, and process the corresponding data in the storage database according to the first due tasks, wherein the storage database refers to the database that stores the specific data corresponding to each task to be processed; The marking module is configured to identify a second expired task in the second buffer database, other than the first expired task, and mark the second expired task as expired, wherein the expiration mark is used to indicate that the data corresponding to the second expired task in the storage database is prohibited from operation.

12. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the steps of the data processing method according to any one of claims 1 to 10.

13. A computer-readable storage medium storing computer instructions, characterized in that, When executed by the processor, this instruction implements the steps of the data processing method according to any one of claims 1 to 10.

14. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps of the data processing method according to any one of claims 1 to 10.

Images