CN111666134A - Method and system for scheduling distributed tasks - Google Patents

Abstract

The invention discloses a distributed task scheduling method and system, and relates to the technical field of computers. A specific implementation of the method includes: receiving one or more query requests for task lock objects of tasks from one or more servers; querying the task lock objects in a database; in response to querying the task lock objects, sending a record to the one or more servers, the record including the task lock status and a specific version number; receiving first update data for the task from the first server, the first update data including the first version number ; in response to determining that the first version number is the same as the particular version number, performing a first update to the database; and when an error event occurs in a second of the one or more servers, causing the one or other servers in multiple servers fire listening events. This implementation improves the reliability of the distributed system and reduces the complexity of solution deployment.

Description

A method and system for distributed task scheduling

technical field

The present invention relates to the field of computer technology, and in particular, to a method and system for distributed task scheduling.

Background technique

There are many existing distributed task scheduling schemes. The commonly used method is to obtain distributed locks through the Redis scheme or the Zookeeper scheme to solve the scheduling problem of multi-host multi-task processing. Distributed locks are exclusive. Only one process can acquire the lock and perform tasks at the same time, and other processes cannot acquire it at the same time. The process releases the lock when the task is done, but the computer is not 100% reliable, so there is a problem of failure to release the lock.

Obtaining distributed locks through the Redis scheme is currently the most used technology. The basic principle is that multiple threads obtain locks through atomic operations of the Redis scheme, and only one thread will obtain the lock. Under this scheme, the general solution to the problem of failure to release the lock is to set the expiration time of the Redis key, so that even if the release of the lock fails, the lock can be released due to expiration, but it is difficult to define how long the expiration time of the key is set. Obtaining distributed locks through the Zookeeper solution is achieved by using its temporary ordered nodes. This method is relatively troublesome to deploy and is rarely used in production environments.

In the process of realizing the present invention, the inventor found that there are at least the following problems in the prior art:

(1) In the Redis scheme, if the expiration time of the key is not properly set, the lock will become invalid, but it is not easy to define how long it takes.

(2) The reliability of the distributed system cannot be guaranteed because the Zookeeper scheme strongly relies on Zookeeper, and the deployment of the Zookeeper scheme is relatively troublesome.

Therefore, the problem of lock failure in the distributed system under the current solution has not been well solved, which makes it difficult to guarantee the reliability of the distributed system.

SUMMARY OF THE INVENTION

In view of this, the embodiments of the present invention provide a method and system for distributed task scheduling, which can replace the traditional Redis scheme by using database optimistic locking, so it is not necessary to set the expiration time, which avoids the inconvenient setting of the expiration time of the key It will lead to the problem of lock failure, and by using Zookeeper as an auxiliary check scheme on the basis of optimistic locking, the deployment difficulties caused by directly adopting the Zookeeper scheme are avoided, and there is no strong dependence on Zookeeper. In addition, the problem of lock failure in distributed task scheduling can be well solved while avoiding the problems of the existing solutions.

To achieve the above object, according to an aspect of the embodiments of the present invention, a method for distributed task scheduling is provided.

The method for distributed task scheduling according to an embodiment of the present invention includes:

receive one or more query requests for a task's task lock object from one or more servers;

query the task lock object in the database;

In response to querying the task lock object, read records related to the task lock object from the database and send the records to the one or more servers, the records including task lock status and a particular version No;

receiving first update data for the task from a first server of the one or more servers, the first update data including a first version number;

in response to determining that the first version number is the same as the particular version number, performing a first update to the database using the first update data; and

When an error event occurs in the second server in the one or more servers, other servers in the one or more servers trigger a monitoring event, wherein the first server and the second server are the same or different .

Optionally, before receiving one or more query requests for the task lock object of the task from one or more servers, the method further includes:

create a parent node corresponding to the inspection server; and

One or more child nodes corresponding to the one or more servers are created under the parent node, wherein the parent node maintains in a list all child nodes currently surviving under it.

Optionally, the one or more sub-nodes are a list of IP addresses of the one or more servers corresponding to the one or more sub-nodes.

Optionally, the parent node and the one or more child nodes are EPHEMERAL type nodes.

Optionally, causing other servers in the one or more servers to trigger the monitoring event further includes:

Deleting the second child node corresponding to the second server from the list to obtain a new list;

sending the new list to child nodes in the new list;

receiving a lock query request from a server corresponding to a child node in the new list, wherein the lock query request is about whether the second child node holds an unreleased lock;

querying the database according to the lock query request; and

In response to the query that the second child node holds an unreleased lock, the lock is released, wherein the lock is an optimistic lock for the task.

Optionally, when the second child node holds an unreleased lock, the task lock status of the task is 1.

Optionally, releasing the lock further includes: setting the task lock status of the task to 0.

Optionally, before receiving one or more query requests for the task lock object of the task from one or more servers, the method further includes:

receive the IP address of the one or more servers;

querying the database for tasks with a task lock status of 1 according to the IP address; and

In response to finding the task whose task lock status is 1, the task lock status of the task is set to 0.

Optionally, after querying the task lock object in the database, the method further includes:

In response to the task lock object not being queried, records related to the task lock object are written to the database.

Optionally, the record includes at least the following fields: a task type field, a task description field, a task lock status field and a version number field.

According to another aspect of the embodiments of the present invention, a distributed task scheduling system is provided.

The system for distributed task scheduling according to an embodiment of the present invention includes:

a query request receiving module, configured to receive one or more query requests from one or more servers to the task lock object of the task;

a lock object query module, used for querying the task lock object in the database;

A lock object processing module, configured to read records related to the task lock objects from the database and send the records to the one or more servers in response to the query to the task lock objects, the records Including task lock status and specific version number;

an update receiving module, configured to receive first update data for the task from a first server among the one or more servers, where the first update data includes a first version number;

an update execution module for performing a first update to the database using the first update data in response to determining that the first version number is the same as the specific version number; and

an auxiliary inspection module, configured to cause other servers in the one or more servers to trigger a monitoring event when an error event occurs in the second server in the one or more servers, wherein the first server and the The second server is the same or different.

Optionally, the auxiliary inspection module is further used for:

create a parent node corresponding to the inspection server; and

One or more child nodes corresponding to the one or more servers are created under the parent node, wherein the parent node maintains in a list all child nodes currently surviving under it.

Optionally, the one or more sub-nodes are a list of IP addresses of the one or more servers corresponding to the one or more sub-nodes.

Optionally, the parent node and the one or more child nodes are EPHEMERAL type nodes.

Optionally, the auxiliary inspection module is further used for:

Deleting the second child node corresponding to the second server from the list to obtain a new list;

sending the new list to child nodes in the new list;

receiving a lock query request from a server corresponding to a child node in the new list, wherein the lock query request is about whether the second child node holds an unreleased lock;

querying the database according to the lock query request; and

In response to the query that the second child node holds an unreleased lock, the lock is released, wherein the lock is an optimistic lock for the task.

Optionally, when the second child node holds an unreleased lock, the task lock status of the task is 1.

Optionally, the auxiliary checking module is further configured to: set the task lock status of the task to 0.

Optionally, the system further includes:

A server startup module for receiving the IP addresses of the one or more servers;

querying the database for tasks with a task lock status of 1 according to the IP address; and

In response to finding the task whose task lock status is 1, the task lock status of the task is set to 0.

Optionally, the lock object processing module is further configured to:

In response to the task lock object not being queried, records related to the task lock object are written to the database.

Optionally, the record includes at least the following fields: a task type field, a task description field, a task lock status field and a version number field.

According to another aspect of the embodiments of the present invention, a distributed task scheduling electronic device is provided.

The distributed task scheduling electronic device according to the embodiment of the present invention includes:

A distributed task scheduling electronic device, characterized in that it includes:

one or more processors;

a storage system for storing one or more programs,

When the one or more programs are executed by the one or more processors, the one or more processors implement the method for distributed task scheduling provided in the first aspect of the embodiments of the present invention.

According to yet another aspect of the embodiments of the present invention, a computer-readable medium is provided.

A computer-readable medium according to an embodiment of the present invention stores a computer program thereon, and when the program is executed by a processor, implements the distributed task scheduling method provided in the first aspect of the embodiment of the present invention.

An embodiment of the above invention has the following advantages or beneficial effects: because the database optimistic lock is used to perform task scheduling in a distributed system and Zookeeper is used to perform auxiliary inspection, it overcomes the problem that the expiration time of the key is not properly set. The technical problems of lock failure and strong dependence on zookeeper, thereby achieving the technical effect of improving the reliability of the distributed system and reducing the complexity of solution deployment.

Further effects of the above non-conventional alternatives will be described below in conjunction with specific embodiments.

Description of drawings

The accompanying drawings are used for better understanding of the present invention and do not constitute an improper limitation of the present invention. in:

1 is a schematic diagram of a main process of a method for distributed task scheduling according to an embodiment of the present invention;

Fig. 2 is a schematic flow chart of an exemplary Docker startup phase according to an embodiment of the present invention;

FIG. 3 is an exemplary flowchart of an exemplary task execution stage according to an embodiment of the present invention;

FIG. 4 is an exemplary flowchart of an exemplary program checking phase according to an embodiment of the present invention;

5 is a schematic flowchart of an exemplary Zookeeper inspection phase according to an embodiment of the present invention;

6 is a schematic diagram of the main flow of another method for distributed task scheduling according to an embodiment of the present invention;

7 is a schematic diagram of main modules of a system for distributed task scheduling according to an embodiment of the present invention;

FIG. 8 is an exemplary system architecture diagram to which an embodiment of the present invention may be applied;

FIG. 9 is a schematic structural diagram of a computer system suitable for implementing a terminal device or a server according to an embodiment of the present invention.

Detailed ways

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, which include various details of the embodiments of the present invention to facilitate understanding and should be considered as exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted from the following description for clarity and conciseness.

FIG. 1 is a schematic diagram of a main process of a method for distributed task scheduling according to an embodiment of the present invention. As shown in FIG. 1 , the method for distributed task scheduling according to an embodiment of the present invention includes steps S101 , S102 , S103 , S104 , and S105 and S106.

Step S101: Receive one or more query requests for the task lock object of the task from one or more servers.

This solution uses the optimistic lock of the database to be released by the Docker executor. Steps S101 to S105 are the normal execution flow of the optimistic locking scheme. In this paper, the term "Docker" refers to a server, such as a Linux server, on which the code program for executing the method can be deployed. The term "server" used throughout this paper can be used interchangeably with "Docker" without affecting the implementation of the solution. and technical effects.

The technical solution can be divided into two stages: (1) a normal execution stage; (2) an auxiliary inspection stage. The normal execution phase includes the Docker startup phase and the task execution phase. The auxiliary inspection phase includes program inspection and Zookeeper inspection. Among them, the Docker startup phase can be completed when each server restarts in the task execution phase. The main purpose is to solve the problem that the lock cannot be released due to the restart when Docker still holds the unreleased lock, which further improves the Reliability of distributed systems. The Zookeeper check mainly solves the problem that the lock cannot be released due to Docker downtime during the task execution phase. The program check will run regularly, and it can be checked every 10 minutes and start synchronously with the normal execution phase. It mainly solves the problem that the optimistic lock needs to be released when the task execution is completed in the task execution phase, but the release fails.

In the normal execution phase, when the task is executing, the optimistic lock of the database will not be released until the task is executed. But we have to restart the Docker container because of new requirements (this is often encountered). When the Docker container is restarted, the optimistic lock of the database will not be released. Therefore, we have added the processing logic of Docker startup, mainly to solve the problem that the optimistic lock of the database will not be released. When the Docker container is started, the listener will be automatically executed to release the optimistic lock of the database held by the machine.

Preferably, before receiving one or more query requests for the task lock object of the task from one or more servers (step S101 ), the method further includes:

receive the IP address of the one or more servers;

querying the database for tasks with a task lock status of 1 according to the IP address; and

In response to finding the task whose task lock status is 1, the task lock status of the task is set to 0.

The main steps of an exemplary Docker startup phase are described below in conjunction with FIG. 2 .

FIG. 2 is a schematic flowchart of an exemplary Docker startup phase according to an embodiment of the present invention. As shown in FIG. 2 , an exemplary Docker startup phase 200 according to an embodiment of the present invention includes steps S201 , S202 , S203 , S204 and S205 .

Step S201: Docker starts to start.

In one embodiment, Docker start-up includes Docker application startup, Web container initialization, and execution of task lock release listeners.

Step S202: Execute the task lock release listener.

In one embodiment, the task lock release listener obtains the local IP address, and queries the database through the IP address whether there is a task in lock, that is, a task whose lock status in the database is 1.

Step S203: Check whether there is a task of local locking.

Step S204: Release the lock.

If there is a task in lock ("Yes" at step S203), the lock of the task is released, and the lock status of the task in the database is set to 0. If it does not exist ("No" at step S203), do nothing, and skip to step S205.

Step S205: Docker startup is completed.

The Docker startup phase solves the problem that the optimism caused by restarting Docker cannot be released, and enhances the reliability of the distributed system. In some embodiments, the Docker startup phase may not be included before step S101.

Step S102: Query the task lock object in the database.

If a Docker wants to execute a task, the first step is to query whether the task is locked by other Dockers. Therefore, after receiving one or more query requests for a task lock object of a task from one or more servers in step S101, the task lock object will be queried in the database to determine whether the task is currently locked by other servers.

In one embodiment, the Docker application queries task lock objects by task type.

Step S103: In response to the query to the task lock object, read records related to the task lock object from the database and send the records to the one or more servers, the records including the task lock status and a specific version number.

Preferably, after querying the task lock object in the database, it further includes:

In response to the task lock object not being queried, records related to the task lock object are written to the database.

Optionally, the record includes at least the following fields: a task type field, a task description field, a task lock status field and a version number field.

In one embodiment, if the task lock object is null, it means that there is no task of this type in the database, so a record is inserted into the database, and the fields include: task type (int), task description (varchar), task lock status ( int, the value is 0, indicating that the task has not been locked), the version number (long, the value is 1). Then get the local IP.

In one embodiment, if the task lock object is not null, the task lock state is obtained from the task lock object, and if the value of the task lock state is 1 (indicating that the task has been locked), the process ends. If the value of the task lock status is 0 (indicating that the task is not locked), get the local IP.

Step S104: Receive first update data for the task from a first server among the one or more servers, where the first update data includes a first version number.

The task will only be executed if Docker is sure that the task is not locked, and at the same time there may be multiple Dockers who have confirmed that the task is not locked and want to execute the task. The optimistic locking mechanism is actually implemented by introducing a version field in the database table. When we want to read data from the database, we also read the version field. If we want to update the read data and write it back to the database, we need to add 1 to the version, and compare the new data with the new one. The version is updated to the data table, and it must be checked whether the version value in the current database is the previous version when updating. If it is, it will be updated normally. If not, the update fails, indicating that other processes have updated the data in this process.

Therefore, each Docker application starts to update the task data in the database, and the update conditions include: task type, task lock status (value 0), version number (if it comes from step 2, the value is 1; if it comes from step 3) Come over, it can be obtained from the lock object). The update fields include: task lock status (updated to 1), version number (add 1 to the original version number), local IP address, and update time (current time). Based on database optimistic locking, only one Docker application can modify successfully.

Step S105: In response to determining that the first version number is the same as the specific version number, perform a first update on the database using the first update data.

In this case, step S104 is to receive the server that completes the update data earliest among the servers that want to perform the task, so that it successfully obtains the optimistic lock and completes the update.

As mentioned above, the normal execution phase includes the Docker startup phase and the task execution phase. Generally, each of the multiple Dockers will go through the Docker startup phase when they are powered on, and the Docker task execution phase will be entered after each Docker is powered on. In one embodiment, in the task execution phase of Docker, when the task reaches the executable point, multiple Docker containers will execute the task at the same time. At this time, all Dockers will grab the optimistic lock of the database. Optimistically locked Docker can execute tasks.

The main steps of an exemplary task execution phase are described below in conjunction with FIG. 3 .

FIG. 3 is a schematic flowchart of an exemplary task execution stage according to an embodiment of the present invention. As shown in FIG. 3 , an exemplary task execution stage 300 according to an embodiment of the present invention includes steps S301 , S302 , S303 , S304 , and S305 , S306 and S307.

Step S301: One or more Dockers are ready to execute tasks.

In one embodiment, step S301 may further include sub-steps S301_1 to S301_N corresponding to the one or more Dockers, respectively representing the steps of Docker_1 to Docker_N preparing to execute tasks.

In one embodiment, the Docker application queries task lock objects by task type.

If the task lock object is null, it means that there is no task of this type in the database, so insert a record into the database, the fields include: task type (int), task description (varchar), task lock status (int, value 0, Indicates that the task has not been locked), the version number (long, the value is 1). Then get the IP address of the machine.

If the task lock object is not null, the task lock state is obtained from the task lock object, and if the value of the task lock state is 1 (indicating that the task has been locked), the process ends. If the value of the task lock status is 0 (indicating that the task is not locked), obtain the IP address of the machine.

Step S302: the one or more Dockers obtain the database optimistic lock through the task number and the version number.

Each Docker application starts to update the task data in the database, and the update conditions include: task type, task lock status (value 0), version number (if the task lock object is found to be null in step S301, the value is 1; if step S301 It is found that the task lock object is not null and can be obtained from the lock object). The update fields include: task lock status (updated to 1), version number (add 1 to the original version number), local IP address, and update time (current time).

Step S303: One of the one or more Dockers successfully acquires the optimistic lock.

Based on database optimistic locking, only one Docker application can modify successfully.

Step S304: The Docker that has obtained the optimistic lock starts to execute the task.

The Docker application that has obtained the optimistic lock starts to execute the task. When the task is executed, the lock is released. The operation of releasing the lock is to update the task lock status to 0.

Step S305: Docker that has acquired the optimistic lock completes the execution task and releases the optimistic lock.

Step S306: The optimistic lock is released successfully.

Step S307: If the optimistic lock release fails, a warning email is sent.

In step S305, the database cannot be 100% reliable, so there is a problem of failure to release the optimistic lock. In addition, the downtime of the Docker server will also cause the failure to release the optimistic lock. When the project is online, if the task is being executed, it will also fail to release the optimistic lock. Causes the release of the optimistic lock to fail. If the optimistic lock release fails, it is necessary to increase the link of human intervention. When the release of the optimistic lock fails, an alarm email and SMS will be sent to promptly notify the developer to manually release the optimistic lock.

As mentioned above, the auxiliary inspection phase includes program inspection and Zookeeper inspection. During the normal execution of the task, it is impossible to guarantee the service is 100% reliable, so an auxiliary inspection phase is added. The auxiliary inspection phase includes two types of inspections, one is program inspection and the other is Zookeeper inspection. The program check is mainly to solve the problem that the task is interrupted during the execution process, which is similar to step S307 in the above-mentioned task execution stage, but the processing time node is different. Step S307 in the task execution stage is when the task has been executed, but the release of the optimistic lock occurs. At this time, you can directly manually intervene to release the optimistic lock. But the program check is mainly aimed at the task interruption caused by the problem during the execution of the task.

The main steps of an exemplary program inspection phase are described below in conjunction with FIG. 4 .

FIG. 4 is a schematic flowchart of an exemplary program inspection phase according to an embodiment of the present invention. As shown in FIG. 4 , an exemplary program inspection phase 400 according to an embodiment of the present invention includes steps S401 , S402 , S403 and S404 .

Step S401: the check program is started.

In one embodiment, after the checker is started, the task object being executed is obtained from the task table.

Step S402: Obtain the holding time of the optimistic lock by the task.

In one embodiment, the time when the task acquires the optimistic lock is subtracted from the current time to obtain the time when the current task holds the optimistic lock.

Step S403: Determine whether the holding time exceeds 30 minutes.

In other embodiments, the value of 30 minutes can be configured. It is configured according to the length of task execution. Generally, it is configured as the time that the task with the longest execution time holds the optimistic lock among all tasks. Therefore, this condition will not be triggered in general, unless The program does have a problem.

Step S404: It is determined that the holding time exceeds 30 minutes, and an alarm email and a short message are sent.

If the task holds the optimistic lock for more than 30 minutes, an alert email and SMS will be sent. After the developer receives the alarm information, he checks whether the task has been interrupted. If it is interrupted, the optimistic lock is released manually. If the task is still executing, it is ignored.

Step S106: when an error event occurs in the second server in the one or more servers, causing other servers in the one or more servers to trigger a monitoring event, wherein the first server and the second server same or different.

Step S106 is a Zookeeper check synchronized with the normal execution flow of the optimistic locking scheme described in steps S101 to S105.

When using database optimistic locking to schedule a distributed system, if a periodic task (for example, executed every 1 hour) is being executed, the task in the database has been locked, and other Docker servers executing the task cannot execute the task. Task. If the Docker executing the task suddenly crashes when the task is half executed, the lock of the task in the database cannot be released. If no measures are taken to release the lock, the task will not be executed again in the future (it was originally every 1 performed once an hour). The Zookeeper check provided in this article is to solve the problem that the lock cannot be released due to Docker downtime. In one embodiment, the "release" action here is done by one of the Dockers.

Zookeeper checks mainly solve the problem of Docker downtime. For example, if Docker_1 is executing task A and Docker1 is down, but task A has not ended normally, the optimistic lock held by task A will not be released. When Docker_2 executes task A, it finds that the lock of task A has not been released. Then give up the execution of task A, so that task A will never be executed.

Preferably, before receiving one or more query requests for the task lock object of the task from one or more servers, the method further includes:

create a parent node corresponding to the inspection server; and

One or more child nodes corresponding to the one or more servers are created under the parent node, wherein the parent node maintains in a list all child nodes currently surviving under it.

Optionally, the one or more sub-nodes are a list of IP addresses of the one or more servers corresponding to the one or more sub-nodes.

Optionally, the parent node and the one or more child nodes are EPHEMERAL type nodes.

Preferably, causing other servers in the one or more servers to trigger the monitoring event further includes:

Deleting the second child node corresponding to the second server from the list to obtain a new list;

sending the new list to child nodes in the new list;

receiving a lock query request from a server corresponding to a child node in the new list, wherein the lock query request is about whether the second child node holds an unreleased lock;

querying the database according to the lock query request; and

In response to the query that the second child node holds an unreleased lock, the lock is released, wherein the lock is an optimistic lock for the task.

Optionally, when the second child node holds an unreleased lock, the task lock status of the task is 1.

Optionally, releasing the lock further includes: setting the task lock status of the task to 0.

The main steps of an exemplary Zookeeper inspection phase are described below in conjunction with FIG. 5 .

FIG. 5 is a schematic flowchart of an exemplary Zookeeper check phase according to an embodiment of the present invention. As shown in FIG. 5 , an exemplary Zookeeper check phase 500 according to an embodiment of the present invention includes steps S501 , S502 , S503 , S504 , and S505 , S506 and S507.

Step S501: Zookeeper detects the heartbeat of one or more Dockers.

All Dockers that execute tasks are registered with Zookeeper. The registration logic is as follows: first create a node /SERVERS on the Zookeeper server, then each Docker creates an EPHEMERAL type node under this node when it starts, for example, Docker_1 creates /SERVERS/${Docker_1's IP}, Docker_2 creates /SERVERS/${Docker_2's IP}, then Docker_1, Docker_2, ......, Docker_n all watch the parent node of /SERVERS. An EPHEMERAL type node has a very important feature, that is, if the connection between the client and the Zookeeper server is disconnected, the node will disappear. Then when a Docker goes down, its corresponding node will disappear, and then all pairs of / / in the cluster will disappear. Clients that watch by SERVERS will be notified.

Step S502: It is found that a Docker in the one or more Dockers is down.

Step S503: the surviving Docker executes the watcher monitor.

If Docker_1 is down, other Dockers (except Docker_1) will trigger monitoring events, and perform the following operations: First, get all child nodes under the /SERVERS node (the IP list of all surviving Dockers), because Docker_1 is down, then under the /SERVERS node All child nodes of Docker_1 do not contain the IP of Docker_1, so the IP of Docker_1 can be obtained by comparing with the last IP list.

Step S504: The surviving Docker checks whether the downed Docker holds a lock.

Step S505: In response to determining that the downed Docker holds the lock of the specific task, release the lock.

After other Dockers get the IP of Docker_1, they query the database for tasks that Docker_1 has not yet executed (that is, Docker_1 still holds the optimistic lock of the task and has not been released, but Docker_1 has been down, and the optimistic lock will never be released), and Docker_1 The optimistic lock holding the task is released.

Terms in this application have their ordinary meanings. The optimistic locking mechanism adopts a more relaxed locking mechanism. Most of them are implemented based on the data version Version record mechanism. The term "Zookeeper" is a distributed, open source distributed application coordination service, an open source implementation of Google's Chubby, an important component of Hadoop and Hbase. It is a software that provides consistent services for distributed applications. The functions provided include: configuration maintenance, domain name service, distributed synchronization, group service, etc. The term "Docker" is an open source application container engine that allows developers to package their applications and dependencies into a portable container that can then be distributed to any popular Linux machine, also virtualized. Containers are completely sandboxed and do not have any interface with each other.

The invention adopts the database optimistic locking technology and Zookeeper to complete distributed task scheduling. In the task acquiring lock stage, the database optimistic locking is used to ensure that each task can only be allocated to one thread at the same time, and the lock is released after the task execution is completed, because the database The reliability and ease of use of Docker are simple and reliable, but there is a problem. When Docker fails, the lock acquired by the task cannot be released. At this time, we will detect the Docker heartbeat through Zookeeper. When Docker goes down, Zookeeper will detect the down Docker and execute the watcher to release the lock. In this solution, when Docker fails, Zookeeper completes the release of the lock. Zookeeper is only used as an auxiliary equipment in the whole process, and does not strongly depend on Zookeeper, which solves the problem of Redis lock failure and the reliability of Zookeeper. In some embodiments, embodiments of the present application may also be applied to pessimistic locking.

An embodiment of the above invention has the following advantages or beneficial effects: because the database optimistic lock is used to perform task scheduling in a distributed system and Zookeeper is used to perform auxiliary inspection, it overcomes the problem that the expiration time of the key is not properly set. The technical problems of lock failure and strong dependence on zookeeper, thereby achieving the technical effect of improving the reliability of the distributed system and reducing the complexity of solution deployment.

FIG. 6 is a schematic diagram of the main flow of another distributed task scheduling method according to an embodiment of the present invention. As shown in FIG. 6 , another distributed task scheduling method according to an embodiment of the present invention includes steps S601 , S602 and S603 , S604, S605, S606, S607, S608, S609 and S610.

Step S601: Create a parent node corresponding to the check server.

Step S602: Create one or more child nodes corresponding to the one or more servers under the parent node, wherein the parent node maintains all child nodes currently surviving under it in a list.

Step S603: Receive one or more query requests for the task lock object of the task from one or more servers.

Step S604: Query the task lock object in the database.

Step S605: In response to the task lock object not being queried, write a record related to the task lock object to the database.

Step S606: In response to the query to the task lock object, read records related to the task lock object from the database and send the records to the one or more servers, the records including the task lock status and a specific version number.

Step S607: Receive first update data for the task from a first server among the one or more servers, where the first update data includes a first version number.

Step S608: In response to determining that the first version number is different from the specific version number, send a notification to the first server.

Step S609: In response to determining that the first version number is the same as the specific version number, perform a first update on the database using the first update data.

Step S610: When an error event occurs in the second server in the one or more servers, cause other servers in the one or more servers to trigger a monitoring event, wherein the first server and the second server same or different.

Preferably, causing other servers in the one or more servers to trigger the monitoring event further includes:

Deleting the second child node corresponding to the second server from the list to obtain a new list;

sending the new list to child nodes in the new list;

receiving a lock query request from a server corresponding to a child node in the new list, wherein the lock query request is about whether the second child node holds an unreleased lock;

querying the database according to the lock query request; and

In response to the query that the second child node holds an unreleased lock, the lock is released, wherein the lock is an optimistic lock for the task.

An embodiment of the above invention has the following advantages or beneficial effects: because the database optimistic lock is used to perform task scheduling in a distributed system and Zookeeper is used to perform auxiliary inspection, it overcomes the problem that the expiration time of the key is not properly set. The technical problems of lock failure and strong dependence on zookeeper, thereby achieving the technical effect of improving the reliability of the distributed system and reducing the complexity of solution deployment.

FIG. 7 is a schematic diagram of main modules of a distributed task scheduling system according to an embodiment of the present invention. As shown in FIG. 7 , a distributed task scheduling system 700 according to an embodiment of the present invention includes:

The query request receiving module 701 is configured to receive one or more query requests for the task lock object of the task from one or more servers.

The lock object query module 702 is configured to query the task lock object in the database.

The lock object processing module 703 is configured to, in response to the query to the task lock object, read records related to the task lock object from the database and send the records to the one or more servers, the Records include task lock status and specific version numbers.

An update receiving module 704, configured to receive first update data for the task from a first server among the one or more servers, where the first update data includes a first version number.

An update execution module 705, configured to perform a first update on the database using the first update data in response to determining that the first version number is the same as the specific version number.

Auxiliary checking module 706, configured to cause other servers in the one or more servers to trigger a monitoring event when an error event occurs in the second server in the one or more servers, wherein the first server and the The second server is the same or different.

Optionally, the auxiliary inspection module 706 is further configured to:

create a parent node corresponding to the inspection server; and

One or more child nodes corresponding to the one or more servers are created under the parent node, wherein the parent node maintains in a list all child nodes currently surviving under it.

Optionally, the one or more sub-nodes are a list of IP addresses of the one or more servers corresponding to the one or more sub-nodes.

Optionally, the parent node and the one or more child nodes are EPHEMERAL type nodes.

Optionally, the auxiliary inspection module 706 is further configured to:

Deleting the second child node corresponding to the second server from the list to obtain a new list;

sending the new list to child nodes in the new list;

receiving a lock query request from a server corresponding to a child node in the new list, wherein the lock query request is about whether the second child node holds an unreleased lock;

querying the database according to the lock query request; and

In response to the query that the second child node holds an unreleased lock, the lock is released, wherein the lock is an optimistic lock for the task.

Optionally, when the second child node holds an unreleased lock, the task lock status of the task is 1.

Optionally, the auxiliary checking module is further configured to: set the task lock status of the task to 0.

Optionally, the distributed task scheduling system 700 further includes:

A server startup module 707, configured to receive the IP addresses of the one or more servers;

querying the database for tasks with a task lock status of 1 according to the IP address; and

In response to finding the task whose task lock status is 1, the task lock status of the task is set to 0.

Optionally, the lock object processing module 703 is further configured to:

In response to the task lock object not being queried, records related to the task lock object are written to the database.

Optionally, the record includes at least the following fields: a task type field, a task description field, a task lock status field and a version number field.

An embodiment of the above invention has the following advantages or beneficial effects: because the database optimistic lock is used to perform task scheduling in a distributed system and Zookeeper is used to perform auxiliary inspection, it overcomes the problem that the expiration time of the key is not properly set. The technical problems of lock failure and strong dependence on zookeeper, thereby achieving the technical effect of improving the reliability of the distributed system and reducing the complexity of solution deployment.

FIG. 8 shows an exemplary system architecture 800 of a distributed task scheduling method or a distributed task scheduling system to which embodiments of the present invention may be applied.

As shown in FIG. 8 , the system architecture 800 may include terminal devices 801 , 802 , and 803 , a network 804 and a server 805 . The network 804 is a medium used to provide a communication link between the terminal devices 801 , 802 , 803 and the server 805 . Network 804 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

The user can use the terminal devices 801, 802, 803 to interact with the server 805 through the network 804 to receive or send messages and the like. Various communication client applications may be installed on the terminal devices 801 , 802 and 803 , such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only examples).

The terminal devices 801, 802, 803 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

The server 805 may be a server that provides various services, such as a background management server that provides support for shopping websites browsed by the terminal devices 801 , 802 and 803 (just an example). The background management server can analyze and process the received product information query request and other data, and feed back the processing results (such as target push information, product information—just an example) to the terminal device.

It should be noted that the distributed task scheduling method provided by the embodiment of the present invention is generally executed by the server 805 , and accordingly, the distributed task scheduling system is generally set in the server 805 .

It should be understood that the numbers of terminal devices, networks and servers in FIG. 8 are merely illustrative. There can be any number of terminal devices, networks and servers according to implementation needs.

Referring next to FIG. 9 , it shows a schematic structural diagram of a computer system 900 suitable for implementing a terminal device according to an embodiment of the present invention. The terminal device shown in FIG. 9 is only an example, and should not impose any limitations on the functions and scope of use of the embodiments of the present invention.

As shown in FIG. 9, a computer system 900 includes a central processing unit (CPU) 901, which can be loaded into a random access memory (RAM) 903 according to a program stored in a read only memory (ROM) 902 or a program from a storage section 908 Instead, various appropriate actions and processes are performed. In the RAM 903, various programs and data necessary for the operation of the system 900 are also stored. The CPU 901 , the ROM 902 , and the RAM 903 are connected to each other through a bus 904 . An input/output (I/O) interface 905 is also connected to bus 904 .

The following components are connected to the I/O interface 905: an input section 906 including a keyboard, a mouse, etc.; an output section 907 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc. ; and a communication section 909 including a network interface card such as a LAN card, a modem, and the like. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the I/O interface 905 as needed. A removable medium 911, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is mounted on the drive 910 as needed so that a computer program read therefrom is installed into the storage section 908 as needed.

In particular, the processes described above with reference to the flowcharts may be implemented as computer software programs in accordance with the disclosed embodiments of the present invention. For example, embodiments disclosed herein include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the method illustrated in the flowchart. In such an embodiment, the computer program may be downloaded and installed from the network via the communication portion 909, and/or installed from the removable medium 911. When the computer program is executed by the central processing unit (CPU) 901, the above-described functions defined in the system of the present invention are executed.

It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the above two. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or a combination of any of the above. More specific examples of computer readable storage media may include, but are not limited to, electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read only memory (ROM), erasable Programmable read only memory (EPROM or flash memory), fiber optics, portable compact disk read only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the present invention, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code therein. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device . Program code embodied on a computer readable medium may be transmitted using any suitable medium including, but not limited to, wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code that contains one or more logical functions for implementing the specified functions executable instructions. It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It is also noted that each block of the block diagrams or flowchart illustrations, and combinations of blocks in the block diagrams or flowchart illustrations, can be implemented in special purpose hardware-based systems that perform the specified functions or operations, or can be implemented using A combination of dedicated hardware and computer instructions is implemented.

The modules involved in the embodiments of the present invention may be implemented in a software manner, and may also be implemented in a hardware manner. The described modules can also be set in the processor, for example, it can be described as: a processor includes a query request receiving module, a locked object query module, a locked object processing module, an update receiving module, an update execution module and an auxiliary checking module. Wherein, the names of these modules do not constitute a limitation of the module itself under certain circumstances, for example, the lock object query module can also be described as "a module for querying the task lock object in the database".

As another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or may exist alone without being assembled into the device. The above-mentioned computer-readable medium carries one or more programs, and when the above-mentioned one or more programs are executed by a device, the device includes: one or more objects that receive task locking objects for tasks from one or more servers; query request; query the task lock object in a database; in response to querying the task lock object, read a record related to the task lock object from the database and send the record to the one or more a server, the record includes a task lock status and a specific version number; receiving first update data for the task from a first server of the one or more servers, the first update data including a first version number; in response to determining that the first version number is the same as the particular version number, performing a first update to the database using the first update data; and when a second of the one or more servers occurs In the event of an error, other servers in the one or more servers trigger a monitoring event, wherein the first server and the second server are the same or different.

An embodiment of the above invention has the following advantages or beneficial effects: because the database optimistic lock is used to perform task scheduling in a distributed system and Zookeeper is used to perform auxiliary inspection, it overcomes the problem that improper setting of the expiration time of the key will lead to The technical problems of lock failure and strong dependence on zookeeper, thereby achieving the technical effect of improving the reliability of the distributed system and reducing the complexity of solution deployment.

The above-mentioned specific embodiments do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims (22)

1. a method for distributed task scheduling, is characterized in that, comprises: receive one or more query requests for a task's task lock object from one or more servers; query the task lock object in the database; In response to querying the task lock object, read records related to the task lock object from the database and send the records to the one or more servers, the records including task lock status and a particular version No; receiving first update data for the task from a first server of the one or more servers, the first update data including a first version number; in response to determining that the first version number is the same as the particular version number, performing a first update to the database using the first update data; and When an error event occurs in the second server in the one or more servers, other servers in the one or more servers trigger a monitoring event, wherein the first server and the second server are the same or different . 2. The method according to claim 1, wherein before receiving one or more query requests for the task lock object of the task from one or more servers, further comprising: create a parent node corresponding to the inspection server; and One or more child nodes corresponding to the one or more servers are created under the parent node, wherein the parent node maintains in a list all child nodes currently surviving under it. 3. The method according to claim 2, wherein the one or more sub-nodes is a list of IP addresses of the one or more servers corresponding to the one or more sub-nodes. 4. The method of claim 2, wherein the parent node and the one or more child nodes are EPHEMERAL type nodes. 5. The method according to claim 2, wherein causing other servers in the one or more servers to trigger a listening event further comprises: Deleting the second child node corresponding to the second server from the list to obtain a new list; sending the new list to child nodes in the new list; receiving a lock query request from a server corresponding to a child node in the new list, wherein the lock query request is about whether the second child node holds an unreleased lock; querying the database according to the lock query request; and In response to the query that the second child node holds an unreleased lock, the lock is released, wherein the lock is an optimistic lock for the task. 6 . The method according to claim 5 , wherein when the second child node holds an unreleased lock, the task lock status of the task is 1. 7 . 7 . The method of claim 5 , wherein releasing the lock further comprises: setting a task lock status of the task to 0. 8 . 8. The method according to claim 1, wherein before receiving one or more query requests for task lock objects of the task from one or more servers, further comprising: receive the IP address of the one or more servers; querying the database for tasks with a task lock status of 1 according to the IP address; and In response to finding the task whose task lock status is 1, the task lock status of the task is set to 0. 9. The method according to claim 1, wherein after querying the task lock object in the database, it further comprises: In response to the task lock object not being queried, records related to the task lock object are written to the database. 10. The method according to claim 1 or 9, wherein the record comprises at least the following fields: a task type field, a task description field, a task lock status field and a version number field. 11. A system for distributed task scheduling, comprising: a query request receiving module, configured to receive one or more query requests from one or more servers to the task lock object of the task; a lock object query module, used for querying the task lock object in the database; A lock object processing module, configured to read records related to the task lock objects from the database and send the records to the one or more servers in response to the query to the task lock objects, the records Including task lock status and specific version number; an update receiving module, configured to receive first update data for the task from a first server among the one or more servers, where the first update data includes a first version number; an update execution module for performing a first update to the database using the first update data in response to determining that the first version number is the same as the specific version number; and an auxiliary inspection module, configured to cause other servers in the one or more servers to trigger a monitoring event when an error event occurs in the second server in the one or more servers, wherein the first server and the The second server is the same or different. 12. The system of claim 11, wherein the auxiliary inspection module is further configured to: create a parent node corresponding to the inspection server; and One or more child nodes corresponding to the one or more servers are created under the parent node, wherein the parent node maintains in a list all child nodes currently surviving under it. 13. The system according to claim 12, wherein the one or more sub-nodes is a list of IP addresses of the one or more servers corresponding to the one or more sub-nodes. 14. The system of claim 12, wherein the parent node and the one or more child nodes are EPHEMERAL type nodes. 15. The system of claim 12, wherein the auxiliary inspection module is further configured to: Deleting the second child node corresponding to the second server from the list to obtain a new list; sending the new list to child nodes in the new list; receiving a lock query request from a server corresponding to a child node in the new list, wherein the lock query request is about whether the second child node holds an unreleased lock; querying the database according to the lock query request; and In response to the query that the second child node holds an unreleased lock, the lock is released, wherein the lock is an optimistic lock for the task. 16 . The system of claim 15 , wherein when the second child node holds an unreleased lock, the task lock status of the task is 1. 17 . 17. The system according to claim 15, wherein the auxiliary checking module is further configured to: set the task lock status of the task to 0. 18. The system of claim 11, wherein the system further comprises: A server startup module for receiving the IP addresses of the one or more servers; querying the database for tasks with a task lock status of 1 according to the IP address; and In response to finding the task whose task lock status is 1, the task lock status of the task is set to 0. 19. The system according to claim 11, wherein the lock object processing module is further configured to: In response to the task lock object not being queried, records related to the task lock object are written to the database. 20. The system according to claim 11 or 19, wherein the record comprises at least the following fields: a task type field, a task description field, a task lock status field and a version number field. 21. A distributed task scheduling electronic device, characterized in that, comprising: one or more processors; a storage system for storing one or more programs, The one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-10. 22. A computer-readable medium on which a computer program is stored, characterized in that, when the program is executed by a processor, the method according to any one of claims 1-10 is implemented.

Images