Task processing method for multiple operating systems, processor and storage medium

Abstract

Embodiments of the present application provide a task processing method, a processor, a server and a storage medium for multiple operating systems, which are applied to an intermediate service cluster. The task processing method comprises the following steps: calling a task acquisition interface of a host service to acquire a to-be-processed task list in the host service; caching the to-be-processed tasks in the task list to a memory database of the intermediate service cluster; acquiring the to-be-processed tasks from the memory database; parsing the to-be-processed tasks to generate corresponding task messages; in the case that it is determined according to the task messages that the to-be-processed tasks are compliance tasks, sending the task messages to a message queue; calling a task processing interface of a scheduling platform to send a task processing instruction to the scheduling platform, so that the scheduling platform processes the to-be-processed tasks corresponding to the task messages in the message queue according to the task processing instruction. The to-be-processed task list in the host service is acquired by the intermediate service cluster and cached to the memory database, so that the task information can be ensured not to be lost.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a task processing method, processor, server, and storage medium for multiple operating systems. Background Technology

[0002] The host service typically comprises multiple task regions, each with pending tasks to be processed. Processing these tasks requires invoking the corresponding task retrieval interface of the host service through the intelligent scheduling platform and synchronizing the task status on the host service. However, the intelligent scheduling service cannot directly access the host's database, and the intelligent scheduling system only provides interfaces for task invocation, conditional resending, and deletion. Simultaneously, the host service only provides interfaces for task querying and status updates. Therefore, a new intermediate service is needed to continuously retrieve tasks from the host service, process the tasks by calling the intelligent scheduling interface, and track the various statuses of the same task. Host service tasks have five statuses: initially pending, updated to queried, processing, successful, and failed. The task information query interface only returns information about tasks in the pending status. It can be seen that this technical solution involves at least three operating systems asynchronously coordinating task processing.

[0003] To address the aforementioned technical problems, existing technologies lack an effective solution for collaborative task processing across multiple operating systems. This leads to inconsistent task states across multiple operating systems, resulting in task processing disorder and compromising the stability and effectiveness of task processing. Summary of the Invention

[0004] The purpose of this application is to provide a task processing method, processor, server, and storage medium for multiple operating systems.

[0005] To achieve the above objectives, the first aspect of this application provides a task processing method for multiple operating systems, the task processing method being applied to an intermediate service cluster, the task processing method comprising:

[0006] Call the host service's task retrieval interface to obtain the list of pending tasks in the host service;

[0007] The tasks to be processed in the task list are cached in the in-memory database of the intermediate service cluster;

[0008] Retrieve tasks to be processed from the in-memory database;

[0009] The task to be processed is parsed to generate the corresponding task message;

[0010] If the task to be processed is determined to be a compliant task based on the task message, the task message is sent to the message queue.

[0011] Call the task processing interface of the scheduling platform to send task processing instructions to the scheduling platform, so that the scheduling platform can process the pending tasks corresponding to the task messages in the message queue according to the task processing instructions.

[0012] In this embodiment of the application, the task processing method further includes:

[0013] After retrieving the task to be processed from the memory database, a first status update notification is sent to the host service so that the host service updates the status of the task to be processed from pending status to queried status, and then from queried status to processing status according to the first status update notification.

[0014] Receive a successful status update notification from the host service;

[0015] Based on the successful status update notification, the status of the pending task in the in-memory database is changed from pending to queried, and then from queried to processing.

[0016] In this embodiment of the application, the task processing method further includes:

[0017] Receive the task completion notification sent by the scheduling platform after it has finished processing the pending tasks;

[0018] If the task status carried in the task completion notification is "processed successfully", a second status update notification is sent to the host service so that the host service updates the status of the pending task to "completed" based on the second status update notification.

[0019] In this embodiment of the application, the task processing method further includes:

[0020] If the task status carried in the task completion notification is a processing failure status, a third status update notification is sent to the host service so that the host service updates the status of the pending task to a processing failure status based on the third status update notification.

[0021] In this embodiment of the application, the task processing method further includes:

[0022] If the host service crashes while updating the status of the pending task from the queried status to the processing status according to the first status update notification, the host service will send a first status update notification to the host service based on the pending tasks in the memory database that are in the pending status. The first status update notification carries the task number of the pending task.

[0023] If the host service finds that the status of the pending task is "queried" based on the task number, receive the update failure notification returned by the host service.

[0024] Based on the update failure notification, change the status of the pending tasks in the in-memory database to the queried status.

[0025] In this embodiment of the application, the intermediate service cluster includes multiple intermediate servers, and the host service includes multiple task regions, each task region corresponding to a list of tasks to be processed; calling the task retrieval interface of the host service to obtain the list of tasks to be processed in the host service includes:

[0026] For any given task region, multiple intermediate servers call the task acquisition interface serially to obtain the list of tasks to be processed in that task region.

[0027] After confirming that an intermediate server has successfully obtained the list of tasks to be processed in the task area, a status update notification is sent to the host service to update the task status in the task area from pending to queried.

[0028] In this embodiment of the application, each task region corresponds to at least one hash queue, and caching the tasks to be processed in the task list to the in-memory database of the intermediate service cluster includes:

[0029] The tasks to be processed in the task list are cached in a hash queue in the in-memory database. The name of the hash queue is determined according to the area code of the task region. The hash queue contains multiple key-value pairs. For each key-value pair, the key is the task number of the task to be processed, and the value is the task information of the task to be processed corresponding to the task number.

[0030] In this embodiment of the application, the task processing method further includes:

[0031] If the call to the task retrieval interface of the host service fails to retrieve the list of pending tasks in the host service, the task retrieval interface should be called again.

[0032] An alarm will be issued if the number of failures reaches the first preset number.

[0033] In this embodiment of the application, the intermediate service cluster includes multiple intermediate servers, and the task retrieval interface of the host service is used to obtain the list of tasks to be processed in the host service, including:

[0034] Each intermediate server competes for a distributed lock on the task acquisition interface;

[0035] The successful intermediate server calls the host service's task retrieval interface to obtain the list of pending tasks in the host service.

[0036] If the number of failed calls to the task acquisition interface reaches the second preset number, the intermediate server that successfully competes for the distribution lock releases the distribution lock, allowing multiple intermediate servers to compete for the distribution lock again.

[0037] In this embodiment of the application, the task processing method further includes:

[0038] After caching the tasks to be processed in the task list to the in-memory database of the intermediate service cluster, the intermediate server that successfully calls the task retrieval interface releases the distribution lock, so that multiple intermediate servers can compete for the distribution lock again.

[0039] In this embodiment of the application, the task processing method further includes:

[0040] The parameters of each field in the task message are validated; if the parameters meet the preset rules, the task to be processed corresponding to the task message is determined to be a compliant task.

[0041] In this embodiment of the application, the task processing method further includes:

[0042] If it is determined that the pending task is a non-compliant task, a fourth status update notification is sent to the host service so that the host service updates the status of the non-compliant task from pending to failed based on the fourth status update notification. The fourth status update notification contains the task number of the non-compliant task.

[0043] If the task status of a non-compliant task is successfully updated, the task information of the corresponding pending task in the memory database is deleted according to the task number of the non-compliant task, so as to free up space in the memory database.

[0044] In this embodiment of the application, the task processing method further includes:

[0045] If the task status update for a non-compliant task fails, resend the fourth status update notification to update the task status of the non-compliant task.

[0046] An alarm will be issued if the number of times the task status update for a non-compliant task fails reaches the third preset number.

[0047] In this embodiment of the application, the task processing method further includes:

[0048] After sending the task message to the message queue, the task information of the corresponding pending task is deleted from the memory database according to the task number of the pending task, so as to free up space in the memory database.

[0049] In this embodiment of the application, the task processing method further includes:

[0050] If sending the task message to the message queue fails, resend the task message to the message queue.

[0051] An alarm will be issued if the number of times the task message fails to be sent to the message queue reaches the fourth preset number.

[0052] In this embodiment of the application, calling the task processing interface of the scheduling platform to send task processing instructions to the scheduling platform includes:

[0053] Determine the task type of the task to be processed, and call the task processing interface corresponding to the task type to send the task processing instructions to the scheduling platform.

[0054] A second aspect of this application provides a task processing method for multiple operating systems, the task processing method being applied to a scheduling platform, the task processing method comprising:

[0055] Receive task processing instructions sent by the intermediate service cluster. The task processing instructions are sent by the intermediate service cluster after obtaining the list of tasks to be processed in the host service and determining that the tasks to be processed in the list are compliant tasks.

[0056] The task message in the message queue is obtained according to the task processing instruction. The task message in the message queue is uploaded by the intermediate service cluster after determining that the task to be processed is a compliant task.

[0057] Process the pending tasks corresponding to the task messages.

[0058] In this embodiment of the application, the task processing method further includes:

[0059] After completing the pending tasks, a task completion notification is sent to the intermediate service cluster. The intermediate service cluster then sends a corresponding status update notification to the host service based on the task completion notification to update the status of the pending tasks.

[0060] In the case where the task status carried in the task completion notification is the processing successful status, a second status update notification is sent to the host service through the intermediate service cluster, so that the host service updates the status of the task to be processed to the completed status according to the second status update notification.

[0061] If the task status carried in the task completion notification is a processing failure status, a third status update notification is sent to the host service through the intermediate service cluster, so that the host service updates the status of the task to be processed to a processing failure status according to the third status update notification.

[0062] A third aspect of this application provides a processor configured to execute the above-described task processing method for multiple operating systems.

[0063] A fourth aspect of this application provides a server including the processor described above.

[0064] A fifth aspect of this application provides a machine-readable storage medium storing instructions that, when executed by a processor, configure the processor to perform the aforementioned task processing method for multiple operating systems.

[0065] The sixth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described task processing method for multiple operating systems.

[0066] The aforementioned task processing method for multiple operating systems introduces an intermediate service cluster between the host service and the intelligent scheduling platform. After obtaining the list of tasks to be processed from the host service through the intermediate service cluster, the tasks are first cached in an in-memory database, ensuring that task information is not lost and that data read and write operations are highly efficient. Then, the tasks in the in-memory database are sent to a message queue. The scheduling platform consumes these tasks using a message queue, enabling asynchronous task invocation, traffic smoothing, and logical decoupling. This approach effectively ensures that tasks can be correctly invoked even under high concurrency. Regardless of whether the host service or the intermediate service cluster fails, tasks can continue to be processed normally after the server restarts, reducing the probability of tasks being stalled due to server downtime.

[0067] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0068] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings:

[0069] Figure 1 This illustration schematically shows an application environment diagram of a task processing method for multiple operating systems according to an embodiment of this application;

[0070] Figure 2 The illustration shows a schematic flowchart of a task processing method for multiple operating systems according to an embodiment of this application;

[0071] Figure 3 The schematic diagram illustrates a process for obtaining tasks to be processed according to an embodiment of this application;

[0072] Figure 4 The schematic diagram illustrates a process flow chart of the task processing procedure according to an embodiment of this application;

[0073] Figure 5A schematic flowchart of a task processing method for multiple operating systems according to another embodiment of this application is shown.

[0074] Figure 6 The diagram illustrates the internal structure of a computer device according to an embodiment of this application. Detailed Implementation

[0075] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0076] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0077] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0078] The task processing method for multiple operating systems provided in this application can be applied to, for example... Figure 1 In the application environment shown, the intermediate service cluster can obtain the list of tasks to be processed in the host service through the host service's task acquisition interface. Then, after processing the tasks, it communicates with the intelligent scheduling platform for processing. The host service (DRDA) can include multiple task regions, such as... Figure 1In the illustrated embodiment, the task area includes four regions: China (CN000), Americas (AM000), Asia Pacific (AP000), and Europe and Africa (EA000). The intermediate service cluster may include multiple intermediate servers, such as server a, server b, and server c. The intelligent scheduling platform may also include multiple scheduling servers, such as scheduling server a, scheduling server b, and scheduling server c.

[0079] Figure 2 A schematic flowchart illustrating a task processing method for multiple operating systems according to an embodiment of this application is shown. Figure 2 As shown, in one embodiment of this application, a task processing method for multiple operating systems is provided. This embodiment mainly applies this method to the above-mentioned... Figure 1 Taking the intermediate service cluster in the example, the steps include:

[0080] Step 202: Call the task retrieval interface of the host service to obtain the list of pending tasks in the host service.

[0081] Step 204: Cache the pending tasks in the task list into the in-memory database of the intermediate service cluster.

[0082] Step 206: Retrieve the tasks to be processed from the in-memory database.

[0083] Step 208: Parse the task to be processed to generate the corresponding task message.

[0084] Step 210: If the task to be processed is determined to be a compliant task based on the task message, the task message is sent to the message queue.

[0085] Step 212: Call the task processing interface of the scheduling platform to send task processing instructions to the scheduling platform, so that the scheduling platform can process the pending tasks corresponding to the task messages in the message queue according to the task processing instructions.

[0086] The pending tasks are stored on the host service. The intermediate service cluster can call the host service's task retrieval interface to obtain the list of pending tasks, and thus retrieve the tasks contained in that list. Each intermediate server in the intermediate service cluster contains its own in-memory database (Redis), which can be used for temporary data caching. After retrieving the pending tasks, the intermediate service cluster can first cache them in its in-memory database. Thus, even if the intermediate service cluster crashes, data loss is avoided and data integrity is guaranteed because the task information is stored in the in-memory database. The intermediate service cluster can then retrieve the pending tasks from the in-memory database, parse them, and generate a task message corresponding to each task. The intermediate service cluster can then analyze the task messages to determine whether the pending tasks are compliant.

[0087] In one embodiment, the method further includes: validating the parameters of each field in the task message; and determining that the task to be processed corresponding to the task message is a compliant task if the parameters meet the preset rules.

[0088] For each pending task's task message, the parameters of each field in the task message can be validated. Furthermore, the fields that each pending task's task message should include, and the parameters of each field, are determined based on the business requirements of each pending task. Therefore, the standard parameters for each field in each task message under actual requirements can be determined based on the business logic of each pending task. The standard parameters are then matched against the field parameters in the current pending task's task message to determine if the field parameters in the task message conform to preset rules. If they do, the pending task corresponding to the task message is determined to be a compliant task. Conversely, if the field parameters do not conform to the preset rules, the pending task corresponding to the task message is determined to be a non-compliant task. Once a pending task is determined to be a compliant task, the next step is to send the task message to a message queue, allowing multiple pending tasks to be consumed (processed) as messages (MQ). The intermediate service cluster can invoke the task processing interface of the scheduling platform to send task processing instructions for each pending task to the scheduling platform. The scheduling platform can then process the pending tasks in the message queue sequentially according to the task processing instructions and the message queue's order. In one embodiment, after sending the task message to the message queue, the intermediate service cluster can delete the corresponding task information from the memory database based on the task number of the pending task, thereby freeing up space in the memory database. Furthermore, if sending the task message of a compliant task to the message queue fails, the intermediate service cluster can resend the task message to retry sending it to the message queue. If sending to the message queue repeatedly fails, and the number of failures reaches a fourth preset number, the intermediate service cluster can issue a corresponding alarm to remind technical personnel to handle the issue.

[0089] In one embodiment, if it is determined that the task to be processed is a non-compliant task, a fourth status update notification is sent to the host service, so that the host service updates the status of the non-compliant task from the pending status to the call failure status according to the fourth status update notification. The fourth status update notification contains the task number of the non-compliant task. If the task status of the non-compliant task is successfully updated, the task information of the corresponding pending task in the memory database is deleted according to the task number of the non-compliant task to free up space in the memory database.

[0090] If the field parameters do not conform to the preset rules, the pending task corresponding to the task message can be determined to be a non-compliant task. In this case, the intermediate server can send a fourth status update notification to the host service. The host service can update the status of the non-compliant task from pending to failed based on the fourth status update notification. The fourth status update notification contains the task number of the non-compliant task. After updating the status of the non-compliant task from pending to failed, the host service will return a status update record for the non-compliant task to the intermediate server. After receiving the status update record, the intermediate server can delete the task information of the pending task corresponding to the non-compliant task from the in-memory database based on the task number of the non-compliant task contained in the status update record, thereby freeing up space in the in-memory database and avoiding unnecessary accumulation of redundant data. Furthermore, when the intermediate server sends a fourth status update notification to the host service to update the status of the task, the host service may also fail to update the status of the non-compliant task from pending to failed. In this scenario, if the host service fails to update the status of a non-compliant task, it will send a corresponding notification to the intermediate server. Upon receiving the notification of the update failure, the intermediate server will send a fourth status update notification to the host service, prompting it to update the status of the non-compliant task again. This process repeats. If the host service continues to fail to update, and the number of failures reaches a third preset limit, the intermediate server can issue an alert to remind relevant technical personnel to handle the issue.

[0091] In one embodiment, the task processing method further includes: after retrieving the task to be processed from the memory database, sending a first status update notification to the host service, so that the host service updates the status of the task to be processed from the pending status to the queried status and from the queried status to the processing status according to the first status update notification; receiving a status update success notification returned by the host service, and modifying the status of the task to be processed in the memory database from the pending status to the queried status and from the queried status to the processing status according to the status update success notification.

[0092] After retrieving the tasks to be processed from the in-memory database, the intermediate service cluster can send a first status update notification to the host service. The host service, based on this notification, updates the status of the tasks it records from "Pending" to "Queryed," and then updates the status from "Queryed" to "Processing." This process is repeated sequentially to update the status of the tasks. After updating the status to "Processing," the host service returns a success notification to the intermediate service cluster. Upon receiving this success notification, the intermediate service cluster updates the status of the tasks in its in-memory database from "Pending" to "Queryed," and then from "Queryed" to "Processing." This process is repeated sequentially to update the status of the tasks, ensuring that the task status stored in the intermediate service cluster is synchronized with the host service.

[0093] In one embodiment, the task processing method further includes: if the host service crashes during the process of updating the status of a pending task from a queried status to a processing status according to a first status update notification, sending a first status update notification to the host service based on the pending tasks in the memory database that are in a pending status, wherein the first status update notification carries a task number associated with the pending task; if the host service finds that the status of the pending task is a queried status based on the task number, receiving an update failure notification returned by the host service; and modifying the status of the pending task in the memory database to a queried status based on the update failure notification.

[0094] In this approach, suppose the host service experiences a system crash while updating the status of pending tasks from "queried" to "processing," before it can send a success notification to the intermediate service cluster to update the task status stored there. At this point, the host service stores the pending tasks as "processing," but the intermediate service cluster's in-memory database stores them as "pending." This creates a discrepancy between the task statuses of the intermediate and host services. Upon recovery, the intermediate service cluster sends a first status update notification to the host service, prompting it to update the task status. This first status update notification includes the task number of the pending task. This task number is globally unique and corresponds one-to-one with each pending task. However, since the host service's task status is already "processing," its attempt to update the status based on the task number in the first status update notification will fail. After the update failure, the host service sends a corresponding update failure notification to the intermediate service cluster. After receiving an update failure notification from the host service, the intermediate service cluster can modify the status of the corresponding pending task in the in-memory database to "queried" based on the task number and its corresponding status record carried in the update failure notification. This ensures consistency of task status between the intermediate service cluster and the host service.

[0095] In one embodiment, the task processing method further includes: receiving a task completion notification sent by the scheduling platform after the task to be processed is completed; and if the task status carried in the task completion notification is a processing success status, sending a second status update notification to the host service, so that the host service updates the status of the task to be processed to a completed status according to the second status update notification.

[0096] The intermediate service cluster can send the acquired tasks to a message queue and call the task processing interface of the scheduling platform to send task processing instructions to the scheduling platform, enabling the scheduling platform to process the tasks. After the scheduling platform completes processing the tasks according to the task processing instructions, it can send a task completion notification to the intermediate service cluster, which carries the task status of the tasks to be processed. If the intermediate service cluster receives the task completion notification and determines that the task status carried in the notification is a successful processing status, it can send a second status update notification to the host service. Upon receiving the second status update notification, the host service can update the status of the task corresponding to the task number carried in the notification to the completed status. In one embodiment, if the intermediate service cluster receives the task completion notification and determines that the task status carried in the notification is a failed processing status, it can send a third status update notification to the host service. Upon receiving the third status update notification, the host service can update the status of the task corresponding to the task number carried in the notification to the failed processing status.

[0097] In one embodiment, the intermediate service cluster includes multiple intermediate servers, and the host service includes multiple task regions, each corresponding to a list of tasks to be processed. Retrieving the list of tasks to be processed in the host service by calling the task retrieval interface includes: for any given task region, multiple intermediate servers serially call the task retrieval interface to obtain the list of tasks to be processed in that task region; after determining that an intermediate server has successfully obtained the list of tasks to be processed in the task region, a status update notification is sent to the host service to update the task status of the task region from pending to queried.

[0098] The intermediate service cluster can include multiple intermediate servers, such as server a, server b, and server c. The host service (DRDA) can include multiple task regions, such as four regions: China (CN000), Americas (AM000), Asia Pacific (AP000), and Europe and Africa (EA000). Each task region has its own list of tasks to be processed; that is, each task region corresponds to one list of tasks to be processed. When the intermediate service cluster obtains the list of tasks to be processed in the host service by calling the task acquisition interface, the multiple intermediate servers in the intermediate service cluster can call the task acquisition interface serially to obtain the list of tasks to be processed in the task region. In other words, the tasks in multiple task regions of the host service are parallel, and multiple intermediate servers can obtain the tasks to be processed in multiple task regions simultaneously. However, for the same task region, multiple intermediate servers obtain the tasks to be processed in that task region serially. This is to avoid multiple intermediate servers obtaining and processing the tasks to be processed in the same task region at the same time. Therefore, for any given task region, multiple intermediate servers can obtain the tasks to be processed serially. When any intermediate server successfully retrieves the pending tasks for a given task area, it sends a status update notification to the host server, changing the status of the task area from pending to queried. This prevents other intermediate servers from retrieving and processing the same tasks multiple times. In one embodiment, if retrieving the list of pending tasks from the host service's task retrieval interface fails, the interface is retried. If the number of failures reaches a first preset number, an alarm is issued. When the intermediate service cluster calls the host service's task retrieval interface to retrieve the list of pending tasks, if the retrieval fails, it can retry the interface. If it still fails, and the number of failures reaches a first preset number, the intermediate service cluster can issue an alarm to alert relevant technical personnel.

[0099] Furthermore, in one embodiment, calling the task acquisition interface of the host service to obtain the list of tasks to be processed in the host service includes: each intermediate server competing for the distributed lock of the task acquisition interface; the intermediate server that wins the competition calling the task acquisition interface of the host service to obtain the list of tasks to be processed in the host service; if the number of failed calls to the task acquisition interface reaches a second preset number, the intermediate server that wins the competition releases the distributed lock, so that multiple intermediate servers can compete for the distributed lock again.

[0100] To prevent multiple intermediate servers from acquiring and processing tasks in the same task region simultaneously, this method introduces distributed locks. When multiple intermediate servers in the intermediate service cluster compete to acquire the task acquisition interface of the host service in order to obtain tasks to be processed, they are actually competing for the distributed lock of the task acquisition interface. The host service can have multiple task regions, and each task region has its own corresponding distributed lock. For example, assuming there are 4 task regions, there are 4 distributed locks, each corresponding to one of the 4 task regions. Multiple intermediate servers can compete for the 4 distributed locks of the 4 task regions simultaneously. Only the intermediate server that successfully acquires the distributed lock can call the task acquisition interface. For example, if intermediate server A successfully acquires the distributed lock for the domestic (CN000) task region, only intermediate server A has the permission to call the task acquisition interface for the domestic (CN000) task region; other intermediate servers cannot call the task acquisition interface. In this way, tasks in the same task region are prevented from being processed multiple times. The intermediate server that successfully acquires the distributed lock then has the permission to call the task acquisition interface of the host service. When calling the task retrieval interface, the call may fail, meaning that no tasks can be retrieved after the call. If the number of failures reaches a second preset number, the successful intermediate server will release the distribution lock. Then, the distribution lock for that task area can be re-competed for by all intermediate servers. Only the successful intermediate server has the authority to call the task retrieval interface for the task area corresponding to that distribution lock. Further, in one embodiment, if the intermediate server that successfully competes for the distribution lock successfully calls the task retrieval interface and retrieves the tasks to be processed in the task area, it can cache the retrieved tasks in a memory database. After caching the tasks in the task list to the memory database, the intermediate server that successfully called the task retrieval interface can also release the distribution lock for that task area, allowing all the intermediate servers to re-compete for the distribution lock for that task area to retrieve new tasks.

[0101] Furthermore, in one embodiment, each task region corresponds to at least one hash queue. Cache the tasks to be processed in the task list to the memory database of the intermediate service cluster, which includes: caching the tasks to be processed in the task list to the hash queue of the memory database. The name of the hash queue is determined according to the area code of the task region. The hash queue contains multiple key-value pairs. For each key-value pair, the key is the task number of the task to be processed, and the value is the task information of the task to be processed corresponding to the task number.

[0102] The host service can include multiple task regions. Each intermediate server's in-memory database stores a hash queue corresponding to each task region. Each task region corresponds to at least one hash queue. Assuming the host service includes four task regions, then for any intermediate server, its in-memory database will contain at least four hash queues, each corresponding to one of the task regions. The name of the hash queue is determined by the region number of the task region. Each hash queue contains multiple key-value pairs, consisting of a key and a value. The key is a unique identifier. In this embodiment, the key in the key-value pair in the hash queue can be the task number of each pending task to ensure key uniqueness. The value can be the task information of the pending task corresponding to the task number. After obtaining the list of pending tasks from the host service, the intermediate server can cache the pending tasks in the hash queue of the in-memory database; specifically, it can cache the pending tasks in the hash queue corresponding to its task region.

[0103] Furthermore, in one embodiment, when calling the task processing interface of the scheduling platform to send task processing instructions to the scheduling platform, the task type of each task to be processed can be determined first, and the task processing interface corresponding to the task type of each task to be processed can be called to send the corresponding task processing instructions, so that the scheduling platform can perform the corresponding processing. For example, if the task type is a conditional task, that is, the task will only be triggered if specific conditions are met, the intermediate service cluster can call the resending, deletion, and other task processing interfaces of conditional tasks so that the scheduling platform can process the conditional tasks. If the task type is a scheduled task, the intermediate service cluster can call the instantiated task processing interface of the scheduling platform so that the scheduling platform can process the scheduled task.

[0104] It should be added that the aforementioned first, second, third, and fourth status update notifications, as well as the update failure notification, are all status update notifications, designed to update the status of the tasks to be processed by the host service or intermediate service cluster. However, they are distinguished by name for ease of description. Similarly, the first, second, third, and fourth preset counts are all pre-set threshold values. Their values ​​can be the same or different, depending on the settings of the technical personnel. While distinguished for ease of description, they can be set to the same value in practice. For example, all of the above preset counts can be set to 3 times.

[0105] The aforementioned task processing method for multiple operating systems introduces an intermediate service cluster between the host service and the intelligent scheduling platform. After obtaining the list of tasks to be processed from the host service through the intermediate service cluster, the tasks are first cached in an in-memory database, ensuring that task information is not lost and that data read and write operations are highly efficient. Then, the tasks in the in-memory database are sent to a message queue. The scheduling platform consumes these tasks using a message queue, enabling asynchronous task invocation, traffic smoothing, and logical decoupling. This approach effectively ensures that tasks can be correctly invoked even under high concurrency. Regardless of whether the host service or the intermediate service cluster fails, tasks can continue to be processed normally after the server restarts, reducing the probability of tasks being stalled due to server downtime. Furthermore, timely alerts are issued in case of abnormal events, allowing for prompt problem detection and resolution.

[0106] like Figure 3 The diagram illustrates a flowchart of a process in one embodiment where a task to be processed is acquired and undergoes a series of processing operations. Figure 3 As shown, the intermediate service cluster can be configured with a scheduled task, which periodically calls the host service's task retrieval interface to obtain a list of tasks to be processed from the host service, and then retrieves the tasks from that list. The intermediate service cluster comprises multiple intermediate servers, and the host service comprises multiple task regions, each corresponding to a list of tasks to be processed. Therefore, each intermediate server can compete for a distributed lock on the task retrieval interface for all task regions. Figure 3 As shown, assuming there are four task regions, meaning the host service includes tasks in four major areas, then task retrieval processes can be started for each of the four major areas. Each of the four task regions has a corresponding distribution lock. Multiple intermediate servers can simultaneously compete for the four distribution locks for the four task regions. Only the intermediate server that successfully acquires the distribution lock can then call the task retrieval interface.

[0107] For example, if intermediate server A successfully acquires the distribution lock for the domestic (CN000) task region, only intermediate server A has the authority to call the task retrieval interface for the domestic (CN000) task region; other intermediate servers cannot call the task retrieval interface. This prevents tasks in the same task region from being processed multiple times. The intermediate server that successfully acquires the distribution lock has the authority to call the host service's task retrieval interface to obtain pending tasks from the host service. Then, it can be determined whether the intermediate service cluster successfully retrieved the task. If task retrieval fails, the task retrieval interface can be called again to retry retrieving pending tasks. If the number of failed retrievals reaches a first preset number, such as three times, an alarm can be issued. Simultaneously, the intermediate server that successfully acquired the distribution lock will release the distribution lock, allowing multiple intermediate servers to re-compete for the distribution lock. If a task is successfully retrieved, the intermediate servers in the intermediate service cluster can register the retrieved pending tasks in the in-memory database for caching. Then, the intermediate server that successfully called the task retrieval interface can also release the distribution lock for that task region, allowing all multiple intermediate servers to re-compete for the distribution lock for that task region to obtain new pending tasks.

[0108] The intermediate server can retrieve tasks to be processed from the in-memory database. It can then send a first status update notification to the host service. Based on this notification, the host service updates the status of the tasks it records from "Pending" to "Queryed," and then from "Queryed" to "Processing." This process is repeated sequentially. After updating a task to "Processing," the host service returns a success notification to the intermediate service cluster. Upon receiving this success notification, the intermediate service cluster updates the status of the tasks in its in-memory database from "Pending" to "Queryed," and then from "Queryed" to "Processing." This process is repeated sequentially to ensure that the task status stored in the intermediate service cluster is synchronized with the host service.

[0109] The intermediate server can cache pending tasks from the task list in a hash queue of an in-memory database. The name of the hash queue is determined by the area code of the task region. The hash queue contains multiple key-value pairs. For each key-value pair, the key is the task number of the pending task, and the value is the task information of the pending task corresponding to that task number. Then, the intermediate server can parse pending tasks whose status has been updated to "processing" to generate corresponding task messages. Next, the intermediate server can validate the parameters of each field in the task message to determine if the field parameters conform to preset rules. If they do, the pending task corresponding to the task message is determined to be a compliant task. Conversely, if the field parameters do not conform to the preset rules, the pending task corresponding to the task message is determined to be a non-compliant task. If a pending task is determined to be a non-compliant task, the intermediate server can determine that the check for that task has failed and can send a fourth status update notification to the host service, so that the host service can change the status of the task to "call failed". The system can determine whether the host service has successfully updated the task's status. If successful, the host service will return a success notification to the intermediate server. The intermediate server can then confirm that the host service has updated the task's status to a failed call state. The intermediate server can then delete the corresponding pending task information from the in-memory database based on the task's task number, freeing up database space. If the host service fails to update the task's status, it will send a notification to the intermediate server. Upon receiving this notification, the intermediate server will send a fourth status update notification to the host service, prompting it to update the non-compliant task's status again. This process repeats. If the host service continues to fail to update, and the number of failures reaches a third preset limit, the intermediate server can issue an alert to remind relevant technical personnel to handle the issue.

[0110] Once it's determined that the tasks to be processed are compliant, the next step is to send the task message to a message queue, allowing multiple tasks to be consumed (processed) via messages (MQ). Further, it can be determined whether sending the task message to the message queue was successful. If successful, the intermediate server can delete the corresponding task information from the in-memory database based on the task number, thus freeing up space in the in-memory database. If sending the task message to the message queue fails, multiple resend attempts can be made. If the number of failed attempts reaches a fourth preset number, an alarm can be issued. After successful sending to the message queue, the intermediate service cluster can call the task processing interface of the scheduling platform to send task processing instructions for each task to the scheduling platform. The scheduling platform can then process the tasks in the message queue sequentially according to the message queue's sorting order.

[0111] like Figure 4 The diagram illustrates a flowchart of the processing of pending tasks in one embodiment. In this embodiment, the intelligent scheduling platform can process pending tasks in the message queue by consuming the message queue. First, the intermediate server can determine the task type of the pending task and call the task processing interface corresponding to each task type to send the corresponding task processing instruction, so that the scheduling platform can perform the corresponding processing. For example, if the task type is a conditional task, that is, the task will only be triggered if specific conditions are met, the intermediate service cluster can call the resending, deletion, and other task processing interfaces for conditional tasks, so that the scheduling platform can process the conditional task. If the task type is a scheduled task, the intermediate service cluster can call the instantiation task processing interface of the scheduling platform, so that the scheduling platform can process this scheduled task. Next, the intermediate service cluster can obtain the processing status of each pending task from the intelligent scheduling platform. That is, the intermediate service cluster can receive the task completion notification returned by the intelligent scheduling platform. If the task status carried in the task completion notification is a successful processing status, the intermediate service cluster can send a second status update notification to the host service, so that the host service can update the status of the pending task to the completed status according to the second status update notification. If the task status in the task completion notification is "processing failed," the intermediate service cluster can send a third status update notification to the host service, so that the host service can update the status of the pending task to "processing failed" based on the third status update notification. Conversely, if the intelligent scheduling platform's request to process a pending task times out, the task will not be consumed; that is, it will not be processed, and there is no need to update the task status in this case.

[0112] like Figure 5As shown, in one embodiment, a task processing method is also provided. This embodiment mainly applies this method to the above-mentioned... Figure 1 Taking the scheduling platform in the example, the steps include:

[0113] Step 502: Receive task processing instructions sent by the intermediate service cluster. The task processing instructions are sent by the intermediate service cluster after obtaining the list of tasks to be processed in the host service and determining that the tasks to be processed in the list are compliant tasks.

[0114] Step 504: Obtain the task message in the message queue according to the task processing instruction. The task message in the message queue is uploaded by the intermediate service cluster after determining that the task to be processed is a compliant task.

[0115] Step 506: Process the pending tasks corresponding to the task messages.

[0116] The pending tasks are stored on the host service. The intermediate service cluster can call the host service's task retrieval interface to obtain the list of pending tasks, thus retrieving the tasks contained within that list. The intermediate service cluster can parse the pending tasks, generating a task message corresponding to each task. Further, the intermediate service cluster can analyze the task messages to determine if the pending task is compliant. If a pending task is determined to be compliant, the intermediate service cluster can send the task message to a message queue, allowing multiple pending tasks to be consumed (processed) via messages (MQ). The intermediate service cluster can call the scheduling platform's task processing interface to send task processing instructions for each pending task to the scheduling platform. After receiving the task processing instructions from the intermediate service cluster, the scheduling platform can process the pending tasks in the message queue sequentially according to the message queue's order. Conversely, if a pending task is not compliant, the intermediate server can send a corresponding fourth-state update notification to the host service. The host service can then update the status of the non-compliant task from pending to failed based on the fourth-state update notification.

[0117] In one embodiment, the task processing method further includes: after completing the task to be processed, sending a task completion notification to an intermediate service cluster, so that the intermediate service cluster sends a corresponding status update notification to the host service according to the task completion notification, so as to update the status of the task to be processed; wherein, if the task status carried in the task completion notification is a processing success status, a second status update notification is sent to the host service through the intermediate service cluster, so that the host service updates the status of the task to be processed to a completed status according to the second status update notification; if the task status carried in the task completion notification is a processing failure status, a third status update notification is sent to the host service through the intermediate service cluster, so that the host service updates the status of the task to be processed to a processing failure status according to the third status update notification.

[0118] Furthermore, after the scheduling platform completes processing the task to be processed according to the task processing instructions, it can send a task completion notification to the intermediate service cluster. This notification carries the task status of the pending task. If the intermediate service cluster receives the task completion notification and determines that the task status in the notification indicates successful processing, it can send a second status update notification to the host service. Upon receiving the second status update notification, the host service can update the status of the pending task corresponding to the task number in the notification to "completed." In one embodiment, if the intermediate service cluster receives the task completion notification and determines that the task status in the notification indicates "failed processing," it can send a third status update notification to the host service. Upon receiving the third status update notification, the host service can update the status of the pending task corresponding to the task number in the notification to "failed processing." After acquiring the pending task, the intermediate service cluster can first cache it in its in-memory database. The first status update notification is a status update notification sent by the intermediate service cluster to the host service after retrieving the task to be processed from the intermediate service cluster's in-memory database. This allows the host service to update the status of the task to be processed from pending to queried, and then from queried to processing, based on the first status update notification.

[0119] The aforementioned task processing method for multiple operating systems introduces an intermediate service cluster between the host service and the intelligent scheduling platform. After obtaining the list of tasks to be processed from the host service through the intermediate service cluster, the tasks are first cached in an in-memory database to ensure that task information is not lost and that data read and write operations are highly efficient. Then, the tasks to be processed in the in-memory database are sent to a message queue. The scheduling platform consumes the tasks using a message queue, which enables asynchronous task invocation, traffic peak reduction, and logical decoupling.

[0120] Figure 2-5 This is a flowchart illustrating a task processing method for multiple operating systems in one embodiment. It should be understood that, although... Figure 2-5 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2-5 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0121] This application provides a storage medium storing a program that, when executed by a processor, implements the above-described task processing method for multiple operating systems.

[0122] This application provides a processor for running a program, wherein the program executes the above-described task processing method for multiple operating systems.

[0123] In one embodiment, a server is provided, including the processor described above.

[0124] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6As shown, the computer device includes a processor A01, a network interface A02, memory (not shown), and a database (not shown) connected via a system bus. The processor A01 provides computing and control capabilities. The memory includes internal memory A03 and a non-volatile storage medium A04. The non-volatile storage medium A04 stores an operating system B01, a computer program B02, and a database (not shown). The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A04. The database stores task data for tasks to be processed. The network interface A02 communicates with external terminals via a network connection. When the computer program B02 is executed by the processor A01, it implements a task processing method for multiple operating systems.

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

[0126] This application provides a device including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the following steps: calling the task acquisition interface of the host service to obtain a list of tasks to be processed in the host service; caching the tasks to be processed in the task list into the memory database of the intermediate service cluster; retrieving the tasks to be processed from the memory database; parsing the tasks to be processed to generate corresponding task messages; if the task to be processed is determined to be a compliant task based on the task message, sending the task message to a message queue; and calling the task processing interface of the scheduling platform to send task processing instructions to the scheduling platform, so that the scheduling platform processes the tasks to be processed corresponding to the task messages in the message queue according to the task processing instructions.

[0127] In one embodiment, the task processing method further includes: after retrieving the task to be processed from the memory database, sending a first status update notification to the host service, so that the host service updates the status of the task to be processed from the pending status to the queried status and from the queried status to the processing status according to the first status update notification; receiving a status update success notification returned by the host service; and modifying the status of the task to be processed in the memory database from the pending status to the queried status and from the queried status to the processing status according to the status update success notification.

[0128] In one embodiment, the task processing method further includes: receiving a task completion notification sent by the scheduling platform after the task to be processed is completed; and if the task status carried in the task completion notification is a processing success status, sending a second status update notification to the host service, so that the host service updates the status of the task to be processed to a completed status according to the second status update notification.

[0129] In one embodiment, the task processing method further includes: if the task status carried in the task completion notification is a processing failure status, sending a third status update notification to the host service, so that the host service updates the status of the task to be processed to a processing failure status according to the third status update notification.

[0130] In one embodiment, the task processing method further includes: if the host service crashes during the process of updating the status of a pending task from a queried status to a processing status according to a first status update notification, sending a first status update notification to the host service based on the pending tasks in the memory database that are in a pending status, wherein the first status update notification carries a task number associated with the pending task; if the host service finds that the status of the pending task is a queried status based on the task number, receiving an update failure notification returned by the host service; and modifying the status of the pending task in the memory database to a queried status based on the update failure notification.

[0131] In one embodiment, the intermediate service cluster includes multiple intermediate servers, and the host service includes multiple task regions, each corresponding to a list of tasks to be processed. Calling the task retrieval interface of the host service to obtain the list of tasks to be processed in the host service includes: for any given task region, multiple intermediate servers serially call the task retrieval interface to obtain the list of tasks to be processed in that task region; after determining that an intermediate server has successfully obtained the list of tasks to be processed in the task region, a status update notification is sent to the host service to update the task status of the task region from pending to queried.

[0132] In one embodiment, each task region corresponds to at least one hash queue. Cache the tasks to be processed in the task list to the in-memory database of the intermediate service cluster. This includes: caching the tasks to be processed in the task list to the hash queue of the in-memory database. The name of the hash queue is determined according to the area code of the task region. The hash queue contains multiple key-value pairs. For each key-value pair, the key is the task number of the task to be processed, and the value is the task information of the task to be processed corresponding to the task number.

[0133] In one embodiment, the task processing method further includes: if the call to the task acquisition interface of the host service fails to obtain the list of tasks to be processed in the host service, calling the task acquisition interface again; and issuing an alarm when the number of failures reaches a first preset number.

[0134] In one embodiment, the intermediate service cluster includes multiple intermediate servers. Calling the task acquisition interface of the host service to obtain the list of tasks to be processed in the host service includes: each intermediate server competing for a distributed lock on the task acquisition interface; the intermediate server that wins the competition calling the task acquisition interface of the host service to obtain the list of tasks to be processed in the host service; if the number of failed calls to the task acquisition interface reaches a second preset number, the intermediate server that wins the competition releases the distributed lock, so that multiple intermediate servers can compete for the distributed lock again.

[0135] In one embodiment, the task processing method further includes: after caching the tasks to be processed in the task list to the memory database of the intermediate service cluster, the intermediate server that successfully calls the task retrieval interface releases the distribution lock, so that multiple intermediate servers can compete for the distribution lock again.

[0136] In one embodiment, the task processing method further includes: validating the parameters of each field in the task message; and determining that the task to be processed corresponding to the task message is a compliant task if the parameters meet the preset rules.

[0137] In one embodiment, the task processing method further includes: if it is determined that the task to be processed is a non-compliant task, sending a fourth status update notification to the host service, so that the host service updates the status of the non-compliant task from the pending status to the call failure status according to the fourth status update notification, wherein the fourth status update notification contains the task number of the non-compliant task; if the task status of the non-compliant task is successfully updated, deleting the task information of the corresponding pending task in the memory database according to the task number of the non-compliant task, so as to release the space of the memory database.

[0138] In one embodiment, the task processing method further includes: resending a fourth status update notification to update the task status of the non-compliant task if the task status update of the non-compliant task fails; and issuing an alarm prompt if the number of times the task status update of the non-compliant task fails reaches a third preset number.

[0139] In one embodiment, the task processing method further includes: after sending the task message to the message queue, deleting the task information of the corresponding task to be processed from the memory database according to the task number of the task to be processed, so as to release the space of the memory database.

[0140] In one embodiment, the task processing method further includes: resending the task message to the message queue if sending the task message to the message queue fails; and issuing an alarm if the number of times the task message fails to be sent to the message queue reaches a fourth preset number.

[0141] In one embodiment, calling the task processing interface of the scheduling platform to send task processing instructions to the scheduling platform includes: determining the task type of the task to be processed, and calling the task processing interface corresponding to the task type to send task processing instructions to the scheduling platform.

[0142] This application embodiment also provides a device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the following steps: receiving a task processing instruction sent by an intermediate service cluster, wherein the task processing instruction is sent by the intermediate service cluster after obtaining a list of tasks to be processed in the host service and determining that the tasks to be processed in the list are compliant tasks; obtaining a task message in a message queue according to the task processing instruction, wherein the task message in the message queue is uploaded by the intermediate service cluster after determining that the task to be processed is a compliant task; and processing the task to be processed corresponding to the task message.

[0143] In one embodiment, the task processing method further includes: after completing the task to be processed, sending a task completion notification to an intermediate service cluster, so that the intermediate service cluster sends a corresponding status update notification to the host service according to the task completion notification, so as to update the status of the task to be processed; wherein, if the task status carried in the task completion notification is a processing success status, a second status update notification is sent to the host service through the intermediate service cluster, so that the host service updates the status of the task to be processed to a completed status according to the second status update notification; if the task status carried in the task completion notification is a processing failure status, a third status update notification is sent to the host service through the intermediate service cluster, so that the host service updates the status of the task to be processed to a processing failure status according to the third status update notification.

[0144] This application also provides a computer program product that, when executed on a data processing device, is adapted to execute a program that initializes task processing method steps for multiple operating systems.

[0145] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0146] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0147] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0148] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0149] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0150] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0151] Computer-readable media include both permanent and non-permanent, removable and non-removable media, which can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0152] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0153] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A task processing method for multiple operating systems, characterized in that, The task processing method is applied to an intermediate service cluster, and the task processing method includes: Call the task retrieval interface of the host service to obtain the list of tasks to be processed in the host service; The tasks to be processed in the task list are cached in the memory database of the intermediate service cluster; The task to be processed is retrieved from the memory database; The task to be processed is parsed to generate the corresponding task message; If the task to be processed is determined to be a compliant task based on the task message, the task message is sent to the message queue. The task processing interface of the scheduling platform is invoked to send a task processing instruction to the scheduling platform, so that the scheduling platform processes the pending task corresponding to the task message in the message queue according to the task processing instruction. Specifically, after retrieving the task to be processed from the memory database, a first status update notification is sent to the host service, so that the host service updates the status of the task to be processed from the pending status to the queried status, and from the queried status to the processing status according to the first status update notification. Receive the status update success notification returned by the host service; Based on the status update success notification, the status of the task to be processed in the memory database is changed from pending status to queried status, and then changed from queried status to processing status. Receive a task completion notification sent by the scheduling platform after it has finished processing the pending task; If the task status carried in the task completion notification is a successful processing status, a second status update notification is sent to the host service so that the host service updates the status of the pending task to a completed status according to the second status update notification.

2. The task processing method according to claim 1, characterized in that, The task processing method further includes: If the task status carried in the task completion notification is a processing failure status, a third status update notification is sent to the host service so that the host service updates the status of the pending task to a processing failure status according to the third status update notification.

3. The task processing method according to claim 1, characterized in that, The task processing method further includes: If the host service crashes while updating the status of the pending task from the queried status to the processing status according to the first status update notification, the host service sends a first status update notification to the host service based on the pending tasks in the memory database that are in the pending status. The first status update notification carries the task number of the pending task. If the host service finds that the status of the task to be processed is queried based on the task number, the host service shall receive an update failure notification returned by the host service. Based on the update failure notification, the status of the pending task in the memory database is changed to "queried".

4. The task processing method according to claim 1, characterized in that, The intermediate service cluster includes multiple intermediate servers, and the host service includes multiple task areas, each task area corresponding to a list of tasks to be processed. The task retrieval interface for calling the host service retrieves the list of pending tasks in the host service, including: For any given task region, the multiple intermediate servers serially call the task acquisition interface to obtain the list of tasks to be processed in that task region. After confirming that an intermediate server has successfully obtained the list of tasks to be processed in the task area, a status update notification is sent to the host service to update the task status of the task area from pending to queried.

5. The task processing method according to claim 4, characterized in that, Each task region corresponds to at least one hash queue, and caching the tasks to be processed in the task list to the in-memory database of the intermediate service cluster includes: The tasks to be processed in the task list are cached in a hash queue of the memory database. The name of the hash queue is determined according to the area code of the task region. The hash queue contains multiple key-value pairs. For each key-value pair, the key is the task number of the task to be processed, and the value is the task information of the task to be processed corresponding to the task number.

6. The task processing method according to claim 1, characterized in that, The task processing method further includes: If the task retrieval interface of the host service fails to retrieve the list of pending tasks in the host service, the task retrieval interface should be called again. An alarm will be issued if the number of failures reaches the first preset number.

7. The task processing method according to claim 1, characterized in that, The intermediate service cluster includes multiple intermediate servers, and the task retrieval interface for calling the host service retrieves the list of tasks to be processed in the host service, including: Each intermediate server competes for the distributed lock of the task acquisition interface; The intermediate server that wins the competition calls the task acquisition interface of the host service to obtain the list of pending tasks in the host service. If the number of failed calls to the task acquisition interface reaches a second preset number, the intermediate server that successfully competes for the distribution lock releases the distribution lock, so that the multiple intermediate servers can compete for the distribution lock again.

8. The task processing method according to claim 7, characterized in that, The task processing method further includes: After caching the tasks to be processed in the task list to the memory database of the intermediate service cluster, the intermediate server that successfully calls the task retrieval interface releases the distribution lock, so that the multiple intermediate servers can compete for the distribution lock again.

9. The task processing method according to claim 1, characterized in that, The task processing method further includes: The parameters of each field in the task message are validated; If the parameters are determined to meet the preset rules, the task to be processed corresponding to the task message is determined to be a compliant task.

10. The task processing method according to claim 9, characterized in that, The task processing method further includes: If the pending task is determined to be a non-compliant task, a fourth status update notification is sent to the host service so that the host service updates the status of the non-compliant task from pending to call failure according to the fourth status update notification. The fourth status update notification contains the task number of the non-compliant task. If the task status of the non-compliant task is successfully updated, the task information of the corresponding pending task in the memory database is deleted according to the task number of the non-compliant task, so as to free up space in the memory database.

11. The task processing method according to claim 10, characterized in that, The task processing method further includes: If the task status update of the non-compliant task fails, the fourth status update notification will be resent to update the task status of the non-compliant task. An alarm will be issued if the number of times the task status update of the non-compliant task fails reaches a third preset number.

12. The task processing method according to claim 1, characterized in that, The task processing method further includes: After the task message is sent to the message queue, the task information of the corresponding task to be processed in the memory database is deleted according to the task number of the task to be processed, so as to release the space of the memory database.

13. The task processing method according to claim 1, characterized in that, The task processing method further includes: If sending the task message to the message queue fails, the task message shall be resent to the message queue. If the number of times the task message fails to be sent to the message queue reaches a fourth preset number, an alarm will be issued.

14. The task processing method according to claim 1, characterized in that, The step of calling the task processing interface of the scheduling platform to send task processing instructions to the scheduling platform includes: Determine the task type of the task to be processed, and call the task processing interface corresponding to the task type to send the task processing instruction to the scheduling platform.

15. A task processing method for multiple operating systems, characterized in that, The task processing method is applied to a scheduling platform, and the task processing method includes: Receive task processing instructions sent by the intermediate service cluster. The task processing instructions are sent by the intermediate service cluster after obtaining the list of tasks to be processed in the host service and determining that the tasks to be processed in the list of tasks to be processed are compliant tasks. The task message in the message queue is obtained according to the task processing instruction, wherein the task message in the message queue is uploaded by the intermediate service cluster after determining that the task to be processed is a compliant task; Process the pending tasks corresponding to the task messages; Specifically, after retrieving the task to be processed from the memory database, the intermediate service cluster sends a first status update notification to the host service, so that the host service updates the status of the task to be processed from the pending status to the queried status, and then from the queried status to the processing status according to the first status update notification; the intermediate service cluster receives a status update success notification returned by the host service, and modifies the status of the task to be processed in the memory database from the pending status to the queried status, and then from the queried status to the processing status according to the status update success notification. The task processing method further includes: After the pending task is completed, a task completion notification is sent to the intermediate service cluster, so that the intermediate service cluster can send a corresponding status update notification to the host service based on the task completion notification to update the status of the pending task. In the case where the task status carried in the task completion notification is a successful processing status, a second status update notification is sent to the host service through the intermediate service cluster, so that the host service updates the status of the task to be processed to a completed status according to the second status update notification. If the task status carried in the task completion notification is a processing failure status, a third status update notification is sent to the host service through the intermediate service cluster, so that the host service updates the status of the pending task to a processing failure status according to the third status update notification.

16. A processor, characterized in that, It is configured to perform the task processing method for multiple operating systems as described in any one of claims 1 to 15.

17. A server, characterized in that, Includes the processor according to claim 16.

Images