A method and device for executing scheduled tasks in a remote active-active system

Abstract

The present invention belongs to the technical field of remote active-active architecture, and specifically relates to a method and device for executing scheduled tasks in a remote active-active system. This invention uses different ZKs as registration centers in a remote environment, and solves the problem of repeated execution of scheduled tasks in a remote active-active system. It can be used in two remote computer rooms, can switch between the master and the slave along with the database, reduce latency, use an independent ZK cluster, avoid network and cluster election brain split problems caused by cross-city ZK clusters, and the slave and host can adjust the number of shards executed according to the task read and write type to ensure execution efficiency. Netty is used as the heartbeat interaction mechanism between scheduled tasks, and priority scheduling of scheduled tasks is achieved through a custom sharding algorithm. In addition, automatic master-slave switching will be achieved in the event of a failure in a certain location.

Description

Technical Field

[0001] The present invention belongs to the technical field of remote active-active architecture, and in particular relates to a method and device for executing scheduled tasks in a remote active-active system. Background Art

[0002] For enterprises in cloud environments, the importance of building an active-active data center is self-evident. On the one hand, it can provide an active-active model for external business production services, greatly improving resource utilization and system efficiency and performance; on the other hand, it can achieve remote disaster recovery, allowing the system to obtain greater value.

[0003] When using ElasticJob for scheduled tasks, many development teams directly deploy a single point. This may not be a problem for asynchronous non-core businesses (such as reconciliation and monitoring), but for high-availability compensation and scheduled core data modifications (such as interest updates in financial scenarios), single-point deployment is extremely prone to problems.

[0004] Executing scheduled tasks in a remote active-active system has numerous limitations. Because active-active systems require multi-site deployment across multiple machines, a typical project often contains dozens of scheduled tasks. Once deployed across multiple machines, scheduled tasks may be executed repeatedly. Both fixed IP addresses and staggered schedules present significant drawbacks. While the distributed scheduled task framework ElasticJob can address this issue, it relies on a single ZooKeeper (ZK) environment. When deploying ZooKeeper clusters across multiple data centers, high network latency and network fluctuations can often lead to issues affecting the stability of the ZooKeeper cluster.

[0005] This system supports ElasticJob. Summary of the Invention

[0006] The purpose of the present invention is to provide a method for executing scheduled tasks in a remote active-active system, which can realize priority scheduling of scheduled tasks through a custom sharding algorithm and realize automatic active-standby switching in the event of a failure in a certain location.

[0007] The technical solutions adopted by the present invention are as follows:

[0008] A method for executing a scheduled task in a remote active-active system, comprising:

[0009] Get the master-slave information of the database and distinguish between the master and slave machines;

[0010] The master and slave establish a channel through the Netty Server Channel Initializer to exchange periodic heartbeat data and scheduled task sharding information. The master returns an ACK message after receiving the information.

[0011] If the slave does not sense the heartbeat of the master within the specified time, or detects the database master-slave switch during scheduled access to the database, it indicates that the host scheduled task service is abnormal or the database has a master-slave switch, triggering the master-slave switch of the scheduled task management module;

[0012] Get the business of creating an Elasticjob scheduled task and mark the read / write type of the task;

[0013] The host obtains the list of business shard instances, JobInstance, from ZooKeeper;

[0014] The slave sends heartbeat data;

[0015] Get the business type and adjust the shard ratio according to the business type.

[0016] In a preferred solution, the step of obtaining the master-slave information of the database and distinguishing between the master and the slave includes:

[0017] Specify the connection information of the master database and the slave database in the database configuration file;

[0018] Initialize the system at startup and allow the management module to obtain database configuration information;

[0019] Based on the configuration information obtained from the database, the management module determines the role of the current node, which includes master and slave. The master is the main node responsible for executing scheduled task management, and the slave is the backup node that can switch to the master in the event of master-slave switching.

[0020] If a master-slave switch occurs in the database, the management module will synchronize and update the master-slave information in a timely manner.

[0021] In a preferred solution, the steps of establishing a channel between the host and the slave through the Netty Server Channel Initializer to exchange periodic heartbeat data and scheduled task sharding information, and returning an ACK message after the host receives the information, include:

[0022] Get Netty Server Channel Initializer;

[0023] Enable the master and slave to establish a channel through the Netty Server Channel Initializer;

[0024] The slave machine periodically sends heartbeat data and scheduled task sharding information to the master machine;

[0025] After receiving the heartbeat data and scheduled task slicing information, the host performs task management and scheduling, and returns an ACK message to confirm receipt.

[0026] In a preferred solution, the steps of establishing a channel between the host and the slave through the Netty Server Channel Initializer to exchange periodic heartbeat data and scheduled task shard information, and returning an ACK message after the host receives the information, further comprising:

[0027] If the slave does not sense the heartbeat of the master within the specified time, or detects the database master-slave switch during scheduled access to the database, it indicates that the host scheduled task service is abnormal or the database has a master-slave switch, triggering the master-slave switch of the scheduled task management module;

[0028] If the slave switches to the master state, that is, it becomes the master node capable of executing scheduled task management, the slave sends a switch message to the master, notifying the master of the master-slave switch. After receiving the switch message, the master checks the status of the database;

[0029] If the master finds that the database has become a slave, the master sends an ACK message agreeing to the switch;

[0030] If the database is not found to become a slave database, an ACK message rejecting the switch is sent;

[0031] If the slave does not receive a reply from the master for a long time, that is, the master scheduled task service is abnormal and communication is impossible, the slave will actively switch to the master state;

[0032] If the scheduled task service corresponding to the master database returns to normal, the slave will switch back under certain conditions.

[0033] In a preferred solution, the steps of creating an Elasticjob scheduled task service and marking the read / write type of the task include:

[0034] Get the ElasticJob scheduled task business created by the system;

[0035] Get the interface for setting task attributes in the ElasticJob framework;

[0036] According to the interface for setting task attributes in the ElasticJob framework, the ElasticJob scheduled tasks for obtaining services are marked, where the marking includes write tasks and read tasks.

[0037] In a preferred solution, the step of the host obtaining a list of job instances from ZooKeeper includes:

[0038] Get the ZooKeeper path;

[0039] The host connects to ZooKeeper;.

[0040] The host obtains information about the business shard instance from the ZooKeeper path. The information about the business shard instance obtained includes a list of the business shard instances.

[0041] In a preferred embodiment, the step of sending heartbeat data by the slave includes:

[0042] The slave obtains the heartbeat data format and generates a heartbeat data packet

[0043] Add the information of the on-board business shard instance JobInstance to the heartbeat data packet;

[0044] Use the established Netty communication channel to send the generated heartbeat data packets to the host.

[0045] In a preferred solution, the step of obtaining the service type and adjusting the shard ratio according to the service type includes:

[0046] Get the shard manager;

[0047] The shard manager receives the task information and determines the business type of the task, which includes read tasks and write tasks.

[0048] Set the shard ratio based on the business type.

[0049] In a preferred solution, the step of setting the shard ratio according to the business type includes:

[0050] Get business type;

[0051] If the service type is a read task, it indicates that the number of shards and the occupancy ratio of the host executing the service are greater than those of the slave. Increase the number of shards and the occupancy ratio of the host executing the service.

[0052] If the business type is a write task, it indicates that the number of shards and the occupancy ratio of the slave executing the business are greater than those of the master. Increase the number of shards and the occupancy ratio of the slave executing the business.

[0053] And, a device for executing a scheduled task in a remote active-active system, comprising:

[0054] one or more processors;

[0055] a storage device having one or more programs stored thereon;

[0056] When the one or more programs are executed by the one or more processors, the one or more processors implement the method for executing scheduled tasks in the remote active-active system.

[0057] The technical effects achieved by the present invention are:

[0058] The present invention adopts different ZK as registration center in a remote environment, solves the problem of repeated execution of scheduled tasks in a remote active-active system, can be used in two remote computer rooms, can switch between the primary and secondary systems together with the database, reduces delay, uses an independent ZK cluster, avoids the network and cluster election brain split problems caused by cross-city ZK clusters, and the slave and host can adjust the number of executed shards according to the task read and write type to ensure execution efficiency. Netty is used as the heartbeat interaction mechanism between scheduled tasks, and priority scheduling of scheduled tasks is realized through a custom sharding algorithm. In addition, automatic primary and secondary switching will be realized in the event of a failure in a certain location. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 is a flow chart of the method provided by the present invention;

[0060] Figure 2 It is a schematic framework diagram of the timing task architecture of the present invention;

[0061] Figure 3 Schematic diagram of the heartbeat management module of the scheduled task manager of the present invention;

[0062] Figure 4 It is a schematic diagram of the shard management module of the timed task manager of the present invention. DETAILED DESCRIPTION

[0063] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0064] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art may make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0065] Secondly, the term "one embodiment" or "embodiment" herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in a preferred embodiment" appearing in various places throughout this specification does not necessarily refer to the same embodiment, nor does it constitute a separate or selective embodiment that is mutually exclusive of other embodiments.

[0066] Secondly, the present invention is described in detail with reference to schematic diagrams. When describing the embodiments of the present invention in detail, for the sake of convenience, the schematic diagrams are only examples and should not limit the scope of protection of the present invention.

[0067] Please see the attached Figures 1 to 4 As shown, a method for executing scheduled tasks in a remote active-active system is provided, including:

[0068] S1. Obtain the master-slave information of the database and distinguish between the master and slave machines;

[0069] S2. The host and the slave establish a channel through the Netty Server Channel Initializer to exchange periodic heartbeat data and scheduled task sharding information. The host returns an ACK message after receiving the information.

[0070] If the slave does not sense the heartbeat of the master within the specified time, or detects the database master-slave switch during scheduled access to the database, it indicates that the host scheduled task service is abnormal or the database has a master-slave switch, triggering the master-slave switch of the scheduled task management module;

[0071] S3. Get the business of creating an Elasticjob scheduled task and mark the task's read / write type.

[0072] S4. The host obtains the list of business shard instances, JobInstance, from ZooKeeper.

[0073] S5, the slave sends heartbeat data;

[0074] S6. Obtain the business type and adjust the shard ratio according to the business type.

[0075] As in the above steps S1 to S6, during the system initialization phase, the management module reads the database configuration information to identify the master database and the slave database, thereby distinguishing whether the current node is the master or the slave, using the Netty framework through the NettyServer Channel Initializer establishes a communication channel between the master and the slave to realize the periodic exchange of heartbeat data and scheduled task shard information. When the slave does not perceive the heartbeat of the master within the specified time or detects the master-slave switch of the database, the master-slave switch logic is triggered, and the slave switches to the master state. When creating an ElasticJob scheduled task, the read-write type of the task is marked and the information is embedded in the task configuration for subsequent task scheduling and shard management. The host obtains the list of business shard instances JobInstance from the specified path by connecting to ZooKeeper, including the status and related information of each shard. The slave regularly generates heartbeat data packets, which include the current slave status and business shard instance information, and sends them to the host through the Netty communication channel. The shard manager adjusts the shard ratio of the master node and the slave node according to the business type of the task to meet the execution requirements of different business types. By effectively distinguishing between the master and the slave, the system can ensure that it can be flexible in a remote active-active environment. Actively manage scheduled tasks and adapt to scenarios such as master-slave switching to improve system availability. Establishing an efficient communication channel helps synchronize system status in real time, reduce communication delays, ensure that the master and slave machines can work together effectively, and improve the real-time and stability of the system. In the event of an abnormality in the host scheduled task service or a master-slave switch in the database, timely triggering of the master-slave switch helps the system quickly adapt to changes and ensure the continuous execution of scheduled tasks. By marking the read and write types of tasks, the system can perform reasonable shard management and scheduling based on the characteristics of the tasks, improving the efficiency and performance of task execution. By obtaining real-time business shard instance information from ZooKeeper, the system can better perform task scheduling and shard management to ensure efficient execution of tasks. Regularly sending heartbeat data helps monitor the status of the slave in real time, ensuring that the host can obtain slave information in a timely manner and ensuring real-time communication. Adjusting the shard ratio according to the business type makes the system more flexible to adapt to the execution characteristics of different task types and improves the system's processing capabilities for read and write tasks.

[0076] The steps to obtain the master and slave information of the database and distinguish between the master and slave machines include:

[0077] S101. Specify the connection information of the master database and the slave database in the database configuration file;

[0078] S102, initializing the system at startup, and allowing the management module to obtain configuration information of the database;

[0079] S103. The management module determines the role of the current node based on the acquired database configuration information. The roles include master and slave. The master is the primary node responsible for executing scheduled task management, and the slave is the backup node that can switch to the master during master-slave switching.

[0080] If a master-slave switch occurs in the database, the management module will synchronize and update the master-slave information in a timely manner.

[0081] As in steps S101 to S103 above, in the system's database configuration file, by specifying the connection information of the master and slave databases, including the database address, user name, password, etc., when the system starts, the management module is responsible for performing initialization operations, including obtaining the database configuration information. The management module determines the role of the current node based on the obtained database configuration information, dividing it into two roles: master and slave. During system operation, if a master-slave switch of the database occurs, the management module will monitor this change and update it in a timely manner. Specifying the connection information through the configuration file enables the system to easily obtain the connection information of the master and slave databases, thereby performing role judgment and initialization. The configuration information acquisition in the initialization phase enables the system to accurately identify the master-slave relationship of the database at runtime, providing the necessary information foundation for subsequent master-slave switch and task management. Through role judgment, the system can clearly distinguish the responsibilities of the current node. The master is responsible for executing scheduled task management, while the slave serves as a backup node. Real-time synchronization of master-slave information helps the system quickly adapt to database changes, ensures the data accuracy of the management module, and provides a reliable foundation for subsequent task scheduling and master-slave switch.

[0082] The steps to establish a channel between the master and slave through the Netty Server Channel Initializer to implement the exchange of periodic heartbeat data and scheduled task sharding information, and the master returns an ACK message after receiving the information, include:

[0083] S201. Get Netty Server Channel Initializer;

[0084] S202, the host and the slave establish a channel through the Netty Server Channel Initializer;

[0085] S203, the slave regularly sends heartbeat data and scheduled task sharding information to the master;

[0086] S204: After receiving the heartbeat data and the scheduled task slice information, the host performs task management and scheduling, and returns an ACK message to confirm receipt.

[0087] As shown in steps S201 to S204 above, Netty Server Channel Initializer is a key component in the Netty framework, which is used to initialize the processing pipeline of the Netty communication channel. Netty ServerChannelInitializer is initialized separately during the system startup process of the host and the slave to ensure that the two use the same processing pipeline. The slave generates heartbeat data and timed task slicing information within a specified time interval and sends it to the host through the established Netty channel. The host receives the heartbeat data and timed task slicing information sent by the slave through the Netty channel, performs task management and scheduling, and then generates an ACK message and returns it to the slave. By obtaining Netty Server ChannelInitializer, the system can flexibly configure and customize the initialization process of the Netty communication channel to meet specific needs. ChannelInitializer, the master and slave can establish a unified communication channel, which improves the consistency and maintainability of system communication. Regular heartbeat data and task information exchange helps maintain real-time communication between the master and slave, ensuring that the system can timely understand the status of the slave and task execution. The master's task management and scheduling can make appropriate decisions based on the information of the slave, and the return of the ACK message ensures that the slave receives feedback from the master, enhancing the reliability of communication.

[0088] The master and slave establish a channel through the Netty Server Channel Initializer to implement the exchange of periodic heartbeat data and scheduled task sharding information. After the master receives the information and returns the ACK message, it also includes:

[0089] If the slave does not sense the heartbeat of the master within the specified time, or detects the database master-slave switch during scheduled access to the database, it indicates that the host scheduled task service is abnormal or the database has a master-slave switch, triggering the master-slave switch of the scheduled task management module;

[0090] If the slave switches to the master state, that is, it becomes the master node capable of executing scheduled task management, the slave sends a switch message to the master, notifying the master of the master-slave switch. After receiving the switch message, the master checks the status of the database;

[0091] If the master finds that the database has become a slave, the master sends an ACK message agreeing to the switch;

[0092] If the database is not found to become a slave database, an ACK message rejecting the switch is sent;

[0093] If the slave does not receive a reply from the master for a long time, that is, the master scheduled task service is abnormal and communication is impossible, the slave will actively switch to the master state;

[0094] If the scheduled task service corresponding to the master database returns to normal, the slave will switch back under certain conditions.

[0095] As mentioned above, the scheduled task management module monitors the status of the slave. If the heartbeat of the host is not received within the specified time or the master-slave switch of the database is detected, the master-slave switch logic is triggered, and the slave actively monitors the status of the host and promptly discovers the master-slave switch event to ensure the system's rapid response to the master-slave switch and the availability of the system. After the slave switches to the master state, it sends a switch message to the host through the Netty channel to notify the host of the master-slave switch. The host obtains the master-slave switch information in time and can adjust the task management and sharding strategy in time to ensure a smooth transition of the master-slave switch. After the host receives the switch message sent by the slave, it checks the status of the database to determine whether the database has become a slave. By checking the database status, the host can accurately determine the result of the master-slave switch and provide a basis for subsequent processing. If the host checks the database status and finds that it has become a slave, the host sends an AC to agree to the switch. The master machine sends a K message to the slave machine. The master machine's consent switching message ensures the consistency of the master-slave switching. After receiving the consent message, the slave machine can continue to assume the role of the master machine. If the master machine checks the database status and finds that it has not become a slave database, the master machine sends an ACK message of refusal to switch to the slave machine. The master machine's refusal to switch message ensures the stability of the system, prevents incorrect switching, and ensures the normal operation of the system. The slave machine regularly monitors the master machine's reply. If it is not received for a long time, it is judged that the host service is abnormal, and the slave machine is triggered to actively switch to the master state. The active switching of the slave machine ensures the system's rapid response to the host anomaly and ensures the stable operation of the system. Under certain conditions, such as the master database scheduled task service is normal, the slave machine can consider switching back and continue to assume the role of the slave machine. According to the status of the master database scheduled task service, the system can dynamically adjust the master-slave relationship to ensure that the overall system maximizes the task execution efficiency under normal operation.

[0096] The steps to create an Elasticjob scheduled task business and mark the task's read / write type include:

[0097] S301. Obtain the ElasticJob scheduled task business created by the system;

[0098] S302, obtaining the interface for setting task attributes in the ElasticJob framework;

[0099] S303: Mark the ElasticJob scheduled task of the acquired business according to the interface for setting task attributes in the ElasticJob framework, where the marking includes write tasks and read tasks.

[0100] As in the above steps S301 to S303, in the system, the ElasticJob scheduled task business should be created by the business module and registered in the task scheduling framework. The ElasticJob framework provides an interface for setting task attributes for configuring various attributes of the task. The task attribute setting interface provided by the ElasticJob framework is used to mark the obtained business ElasticJob scheduled tasks and mark the read and write types of the tasks. By obtaining the ElasticJob scheduled task business created by the system, the system can accurately understand which scheduled tasks currently exist, providing a basis for subsequent task marking. Obtaining the task attribute setting interface enables the system to dynamically configure various attributes of the task, including the execution method and scheduling strategy of the task, so as to flexibly adapt to different business needs. Marking the read and write types of the task helps the task scheduling framework better understand the nature of the task. For example, the tag can include information such as read tasks and write tasks, so that the task scheduling framework can more intelligently allocate the execution nodes of the task when sharding.

[0101] The steps for the host to obtain the JobInstance list of business shard instances from ZooKeeper include:

[0102] S401. Obtain the ZooKeeper path.

[0103] S402, the host connects to ZooKeeper;

[0104] S403: The host obtains information about the service shard instance from the ZooKeeper path, where the information about the service shard instance obtained includes a list of service shard instances.

[0105] As in steps S401 to S403 above, in a distributed system, business sharding information is usually stored in a specific path in ZooKeeper. The host uses the ZooKeeper client library to establish a connection with the ZooKeeper server. The host obtains the stored business sharding instance information from the specified path through the ZooKeeper client, which may include the IP address of the instance, execution status, etc. By obtaining the ZooKeeper path, the system can clearly determine the location where the business sharding information is stored in ZooKeeper, providing an accurate path for the host's subsequent connection and information acquisition. By connecting to ZooKeeper, the host can read and monitor the business sharding information stored in ZooKeeper to maintain real-time sharding information synchronization. Obtaining information about business sharding instances enables the host to understand the current business sharding status, including which instances are running and their execution status, providing necessary information for subsequent task scheduling, helping the system to flexibly adapt to business changes and ensure balanced execution of tasks in a distributed environment.

[0106] The steps for the slave to send heartbeat data include:

[0107] S501, the slave obtains the heartbeat data format and generates a heartbeat data packet

[0108] S502, adding the information of the on-board business shard instance JobInstance to the heartbeat data packet;

[0109] S503: Use the established Netty communication channel to send the generated heartbeat data packet to the host.

[0110] As in the above-mentioned steps S501 to S503, the format of the heartbeat data is defined in advance by the slave, including necessary information such as slave status, operating status, etc. The slave generates a heartbeat data packet that conforms to the defined format within the heartbeat cycle. When generating the heartbeat data packet, the slave adds the information of the business shard instance (such as instance ID, execution status, etc.) to the heartbeat data packet to provide a more detailed system status of the host. The slave uses the established Netty communication channel to send the generated heartbeat data packet to the host. Netty provides an efficient asynchronous communication framework to ensure the stability of communication. By defining the heartbeat data format, the structural consistency of the heartbeat data is ensured, so that the host can accurately parse and process the heartbeat information, and the information of the business shard instance is added to the heartbeat data packet so that the host can understand the execution status of each shard, providing more comprehensive information for task scheduling. By using the Netty communication channel, reliable and real-time communication between the slave and the host is achieved, which helps the host to obtain the status information of the slave in time and realize real-time monitoring and collaborative work of the system.

[0111] The steps to obtain the business type and adjust the shard ratio according to the business type include:

[0112] S601, obtaining a shard manager;

[0113] S602: The shard manager receives the task information and determines the business type of the task, which includes read tasks and write tasks.

[0114] S603: Set the shard ratio according to the business type.

[0115] As in the above steps S601 to S603, there is a shard manager in the system, which is responsible for scheduling and managing the sharding logic of tasks, usually based on the sharding management mechanism of ElasticJob. When the shard manager receives task information, it parses the business type of the task and determines whether the task is a read task or a write task. According to the business type of the task, the shard manager dynamically adjusts the shard ratio. For example, for read tasks, the master node shard ratio can be increased, and for write tasks, the slave node shard ratio can be increased. Obtaining the shard manager enables the system to dynamically adjust the sharding strategy of the task and realize flexible control of task execution. By judging the business type of the task, the shard manager can understand the nature of the task's access to the database, providing a basis for subsequent sharding adjustments. Dynamically adjusting the shard ratio helps the system better adapt to the needs of different business types. By optimizing the shard ratio, the efficiency of task execution and the utilization of database resources are improved.

[0116] The steps to set the shard ratio based on the business type include:

[0117] S6031. Get the service type.

[0118] If the service type is a read task, it indicates that the number of shards and the occupancy ratio of the host executing the service are greater than those of the slave. Increase the number of shards and the occupancy ratio of the host executing the service.

[0119] If the business type is a write task, it indicates that the number of shards and the occupancy ratio of the slave executing the business are greater than those of the master. Increase the number of shards and the occupancy ratio of the slave executing the business.

[0120] As in the above step S6031, the system obtains the business type of the task from the task information. For example, the task is marked as a read task or a write task. The business type is obtained in order to make corresponding shard adjustments according to the nature of the task to optimize the task execution efficiency. When the business type is a read task, the system believes that the master is more suitable for executing the task, so the number and occupancy ratio of the shards executed by the master are increased. Increasing the number and occupancy ratio of the shards executed by the master helps to optimize the execution efficiency of the read task, fully utilize the performance of the master, and improve the overall reading capability of the system. When the business type is a write task, the system believes that the slave is more suitable for executing the task, so the number and occupancy ratio of the shards executed by the slave are increased. Increasing the number and occupancy ratio of the shards executed by the slave helps to optimize the execution efficiency of the write task, fully utilize the performance of the slave, and improve the overall writing capability of the system. By dynamically adjusting the shard ratio of the master and slave machines according to the business type, the system can better adapt to the needs of different types of tasks, improve the efficiency of task execution and the performance of the overall system. This flexible shard adjustment mechanism helps to optimize the system's task scheduling strategy and ensure that the system can run more efficiently in a remote active-active environment.

[0121] And, a device for executing a scheduled task in a remote active-active system, comprising:

[0122] one or more processors;

[0123] a storage device having one or more programs stored thereon;

[0124] When one or more programs are executed by one or more processors, the one or more processors implement a method for executing scheduled tasks in a remote active-active system.

[0125] The foregoing is merely a preferred embodiment of the present invention. It should be noted that those skilled in the art may make various improvements and modifications without departing from the principles of the present invention, and such improvements and modifications are also within the scope of protection of the present invention. Structures, devices, and operating methods not specifically described or explained herein shall, unless otherwise specified or limited, be implemented in accordance with conventional means in the art.

Claims

1. A method for executing scheduled tasks in a remote active-active system, characterized in that: include: Get the master-slave information of the database and distinguish between the master and slave machines; The host and the slave establish a channel through the Netty Server Channel Initializer to achieve circular Periodic heartbeat data and scheduled task sharding information are exchanged, and the host returns an ACK message after receiving the information; If the slave does not sense the heartbeat of the master within the specified time, or in the process of accessing the database at regular intervals If a database master-slave switch is detected, it indicates that the host scheduled task service is abnormal or the database has a master-slave switch. Switch, trigger the main and standby switching of the scheduled task management module; Get the business of creating an Elasticjob scheduled task and mark the read / write type of the task; The host obtains the list of business shard instances, JobInstance, from ZooKeeper; The slave sends heartbeat data; Get the business type and adjust the shard ratio according to the business type; The step of setting the shard ratio according to the business type includes: Get business type; If the service type is a read task, it indicates that the number of shards and the occupancy ratio of the host executing the service are greater than those of the slave. Increase the number of shards and the occupancy ratio of the host executing the service. If the business type is a write task, it indicates that the number of shards and the occupancy ratio of the slave executing the business are greater than those of the master. Increase the number of shards and the occupancy ratio of the slave executing the business.

2. The method for executing scheduled tasks in a remote active-active system according to claim 1, wherein: The step of obtaining the master-slave information of the database and distinguishing between the master and the slave includes: Specify the connection information of the master database and the slave database in the database configuration file; Initialize the system at startup and allow the management module to obtain database configuration information; Based on the configuration information obtained from the database, the management module determines the role of the current node, which includes master and slave. The master is the main node responsible for executing scheduled task management, and the slave is the backup node that can switch to the master in the event of master-slave switching. If a master-slave switch occurs in the database, the management module will synchronize and update the master-slave information in a timely manner.

3. The method for executing scheduled tasks in a remote active-active system according to claim 1, wherein: The steps of establishing a channel between the host and the slave through the Netty Server Channel Initializer to exchange periodic heartbeat data and scheduled task sharding information, and returning an ACK message after the host receives the information, include: Get Netty Server Channel Initializer; Enable the master and slave to establish a channel through the Netty Server Channel Initializer; The slave machine periodically sends heartbeat data and scheduled task sharding information to the master machine; After receiving the heartbeat data and scheduled task slicing information, the host performs task management and scheduling, and returns an ACK message to confirm receipt.

4. The method for executing scheduled tasks in a remote active-active system according to claim 1, wherein: The process of establishing a channel between the host and the slave through the Netty Server Channel Initializer to exchange periodic heartbeat data and scheduled task shard information, and returning an ACK message after the host receives the information, further includes: If the slave does not sense the heartbeat of the master within the specified time, or detects the database master-slave switch during scheduled access to the database, it indicates that the host scheduled task service is abnormal or the database has a master-slave switch, triggering the master-slave switch of the scheduled task management module; If the slave switches to the master state, that is, it becomes the master node capable of executing scheduled task management, the slave sends a switch message to the master, notifying the master of the master-slave switch. After receiving the switch message, the master checks the status of the database; If the master finds that the database has become a slave, the master sends an ACK message agreeing to the switch; If the database is not found to become a slave database, an ACK message rejecting the switch is sent; If the slave does not receive a reply from the master for a long time, that is, the master scheduled task service is abnormal and communication is impossible, the slave will actively switch to the master state; If the scheduled task service corresponding to the master database returns to normal, the slave will switch back under certain conditions.

5. The method for executing scheduled tasks in a remote active-active system according to claim 1, wherein: The steps of creating an Elasticjob scheduled task business and marking the read / write type of the task include: Get the ElasticJob scheduled task business created by the system; Get the interface for setting task attributes in the ElasticJob framework; According to the interface for setting task attributes in the ElasticJob framework, the ElasticJob scheduled tasks for obtaining services are marked, where the marking includes write tasks and read tasks.

6. The method for executing scheduled tasks in a remote active-active system according to claim 1, wherein: The step of the host obtaining a list of job instances from ZooKeeper includes: Get the ZooKeeper path; The host connects to ZooKeeper; The host obtains information about the business shard instance from the ZooKeeper path. The information about the business shard instance obtained includes a list of the business shard instances.

7. The method for executing scheduled tasks in a remote active-active system according to claim 1, wherein: The step of sending heartbeat data from the slave includes: The slave obtains the heartbeat data format, generates a heartbeat data packet, and adds the information of the business shard instance JobInstance on the slave to the heartbeat data packet; Use the established Netty communication channel to send the generated heartbeat data packets to the host.

8. The method for executing scheduled tasks in a remote active-active system according to claim 1, wherein: The step of obtaining the service type and adjusting the shard ratio according to the service type includes: Get the shard manager; The shard manager receives the task information and determines the business type of the task, which includes read tasks and write tasks. Set the shard ratio based on the business type.

9. A device for executing scheduled tasks in a remote active-active system, characterized in that: include: one or more processors; a storage device having one or more programs stored thereon; When the one or more programs are executed by the one or more processors, the one or more processors implement the method for executing a scheduled task in a remote active-active system according to any one of claims 1 to 8.

Images