CN117336153A

CN117336153A - Disaster recovery and backup dual-activity method, system and device of RocketMQ

Info

Publication number: CN117336153A
Application number: CN202311313459.2A
Authority: CN
Inventors: 梁文君; 田标
Original assignee: Tianyi Digital Life Technology Co Ltd
Current assignee: Tianyi Digital Life Technology Co Ltd
Priority date: 2023-10-10
Filing date: 2023-10-10
Publication date: 2024-01-02

Abstract

The application discloses a disaster recovery dual-activity method, a system and a device of RocketMQ, wherein the method comprises the following steps: sending a data packet to a target cluster at regular time to perform heartbeat detection on the target cluster; if the heartbeat information returned by the target cluster is not received within the set time, judging whether the target cluster has a Broker fault or a NameServer fault; if the target cluster has a Broker fault, removing the Broker with the fault in the routing table or switching the currently used cluster from the target cluster to the disaster recovery cluster; and if the target cluster has NameServer faults, removing the NameServer with faults in the routing table. The method and the device realize automatic switching of the disaster recovery system RocketMQ and the non-perception switching of the user, and can be widely applied to the technical fields of IT and software development.

Description

Disaster recovery and backup dual-activity method, system and device of RocketMQ

Technical Field

The application relates to the technical field of IT and software development, in particular to a disaster recovery dual-activity method, a system and a device of a RocketMQ.

Background

In an enterprise production environment, the mode of the same city or different places is generally adopted to realize the RocketMQ disaster recovery and dual-activity, the disaster recovery node RocketMQ needs to be switched to recover normal service when faults occur, the traditional method is to switch to the disaster recovery node RocketMQ by modifying program configuration, and meanwhile, the service needs to be restarted to be effective after the configuration is modified, so that the service is temporarily unavailable, and the service operation is affected.

Disclosure of Invention

In view of this, the present application provides a method, a system and a device for dual activation of disaster recovery of a dockmq, so as to implement automatic switching of disaster recovery of the dockmq and make a user have no perception of switching.

One aspect of the present application provides a disaster recovery dual-activity method of a dockmq, including:

sending a data packet to a target cluster at regular time to perform heartbeat detection on the target cluster;

if the heartbeat information returned by the target cluster is not received within the set time, judging whether the target cluster has a Broker fault or a NameServer fault;

if the target cluster has a Broker fault, removing the Broker with the fault in the routing table or switching the currently used cluster from the target cluster to the disaster recovery cluster;

and if the target cluster has NameServer faults, removing the NameServer with faults in the routing table.

Optionally, if the target cluster has a Broker fault, removing the Broker with the fault in the routing table or switching the currently used cluster from the target cluster to the disaster recovery cluster, including:

if the target cluster has a Broker fault and a main Broker fault, judging whether the number of main Broker faults exceeds a set number, and if so, switching the currently used cluster from the target cluster to a disaster recovery cluster; if not, rejecting the main Broker with the fault in the routing table and lifting the slave Broker to be a new main Broker;

And if the target cluster has the Broker fault and the main Broker fault does not occur, eliminating the Broker with the fault in the routing table.

Optionally, after the removing the faulty NameServer in the routing table, the method further includes:

sending a heartbeat request to a faulty NameServer at regular time to determine whether the faulty NameServer is recovered to be normal;

if yes, updating the NameServer address after the recovery to the routing table.

Optionally, the method further comprises:

responding to the connection operation of a client, and establishing connection with the client through a plurality of protocols;

receiving a request instruction sent by a client;

sending the request instruction to the target cluster so that a Broker and a NameServer of the target cluster respond to the request instruction;

and receiving response information returned by the target cluster to the request instruction, and sending the response information to the client.

Optionally, the method further comprises:

sending the response information to the disaster recovery cluster so as to enable the disaster recovery cluster to backup the response information;

reading the routing table in real time, and comparing the routing table obtained by reading in real time with the existing routing table; if the routing table obtained by reading in real time is different from the existing routing table, the existing routing table is updated to the routing table obtained by reading in real time, so that load balancing is realized.

Optionally, the method further comprises:

acquiring data of a to-be-newly-built cluster, and sending a command of newly-built cluster to a target host in the data of the to-be-built cluster so as to deploy a new cluster on the target host; after a new cluster is deployed, writing information of the new cluster into a database, outputting a corresponding operation log and storing the operation log;

and/or the number of the groups of groups,

acquiring data of an existing cluster, and sending a data packet to the existing cluster to perform heartbeat detection on the existing cluster; if the existing cluster is determined to have faults according to the heartbeat information returned by the existing cluster, outputting corresponding fault information to remind a user to check the data of the existing cluster; and if the existing cluster is determined to have no fault according to the heartbeat information returned by the existing cluster, writing the information of the existing cluster into a database.

Optionally, the method further comprises:

and monitoring the link call time among all the target clusters, and outputting a monitoring report.

Another aspect of the present application further provides a dual active disaster recovery system of a dockmq, including: client, server and cluster; the clusters comprise a target cluster and a disaster recovery cluster which are currently used;

The client is used for sending a message to the server and/or consuming the message sent by the server;

the server is used for executing the double-active disaster recovery method of the RocketMQ;

the cluster is used for responding to the instruction sent by the server and returning corresponding information to the server.

Another aspect of the present application further provides a disaster recovery dual-active device of a dockmq, including:

the first unit is used for sending data packets to a target cluster at regular time so as to perform heartbeat detection on the target cluster;

the second unit is used for judging whether the target cluster has a Broker fault or a NameServer fault if heartbeat information returned by the target cluster is not received within a set time;

a third unit, configured to reject a failed Broker in the routing table or switch a currently used cluster from the target cluster to a disaster recovery cluster if the target cluster has a Broker failure;

and a fourth unit, configured to reject the failed NameServer in the routing table if the NameServer failure occurs in the target cluster.

Another aspect of the present application also provides an electronic device, including a processor and a memory;

The memory is used for storing programs;

the processor executes the program to implement the method.

Another aspect of the present application also provides a computer-readable storage medium storing a program that is executed by a processor to implement the method.

The application also discloses a computer program product or a computer program comprising computer instructions stored in a computer readable storage medium. The computer instructions may be read from a computer-readable storage medium by a processor of an electronic device, and executed by the processor, cause the electronic device to perform the method described above.

The method and the device can send the data packet to the target cluster at regular time so as to perform heartbeat detection on the target cluster; if the heartbeat information returned by the target cluster is not received within the set time, the target cluster can be considered to have faults, and then whether the target cluster has a Broker fault or a NameServer fault is judged; if the target cluster has a Broker fault, removing the Broker with the fault in the routing table or switching the currently used cluster from the target cluster to the disaster recovery cluster; and if the target cluster has NameServer faults, removing the NameServer with faults in the routing table. According to the method and the device, heartbeat detection is carried out on the target cluster at regular time, after no response of the target cluster is received within a set time, the failed Broker and NameServer are automatically removed, or the disaster recovery cluster is automatically switched to, the cluster is restarted without modifying configuration, automatic disaster recovery is achieved, and a user does not feel.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic flow chart of a disaster recovery dual-activation method of a dockmq provided in an embodiment of the present application;

FIG. 2 is a flowchart illustrating steps for processing a Broker fault according to an embodiment of the present disclosure;

FIG. 3 is a flowchart illustrating steps for NameServer failure handling according to an embodiment of the present application;

fig. 4 and fig. 5 are flowcharts of load balancing implementation steps provided in the embodiments of the present application;

fig. 6 is a flowchart of steps for implementing a trunking nanotube function according to an embodiment of the present application;

FIG. 7 is a block diagram of a dual active disaster recovery system for a RocketMQ provided in an embodiment of the present application;

FIG. 8 is a flowchart illustrating steps for automatically switching disaster recovery/dual-activity functions according to an embodiment of the present application;

fig. 9 is a structural block diagram of a disaster recovery dual-active device of a dockmq provided in an embodiment of the present application;

Fig. 10 is a block diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application.

It should be noted that although functional block division is performed in a device diagram and a logic sequence is shown in a flowchart, in some cases, the steps shown or described may be performed in a different order than the block division in the device, or in the flowchart.

The terms first, second and the like in the description and in the claims and in the above-described figures, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the present application.

In order to realize disaster recovery/dual-activity of the RocketMQ, the embodiment of the application provides a disaster recovery/dual-activity method of the RocketMQ, when a capacity base is opened, heartbeat detection is carried out on a target cluster by timing, and after no response of the target cluster is received within a set time, a failed Broker and NameServer are automatically removed, or the cluster is automatically switched to a disaster recovery cluster, and the problem that the cluster fault needs to be stopped briefly to further influence user experience is solved without modifying configuration and restarting the cluster. The disaster recovery dual-activity method can be applied to the user terminal, the server or an implementation environment formed by the user terminal and the server. In addition, the disaster recovery dual-activity method can also be software running in the user terminal or the server, such as an application program with the disaster recovery dual-activity function, and the like. The user terminal may be, but is not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, etc. The server can be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, and can also be a cloud server for providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, basic cloud computing services such as big data and artificial intelligent platforms and the like.

Referring to fig. 1, an embodiment of the present application provides a disaster recovery dual-activation method of a dockmq, including steps S100 to S130, which specifically includes the following steps:

s100: and sending a data packet to a target cluster at regular time to perform heartbeat detection on the target cluster.

Specifically, the disaster recovery dual-activity method in this embodiment may be applied to a server, so that the server may send a data packet to the target cluster Broker, nameServer at regular time to perform heartbeat detection.

Optionally, the target cluster may be a cluster of a middleware RocketMQ, so this embodiment may provide an application disaster recovery and dual-activity environment RocketMQ, which is used to solve the problem that the middleware RocketMQ is relatively complicated to operate in the disaster recovery and dual-activity environments.

S110: if the heartbeat information returned by the target cluster is not received within the set time, judging whether the target cluster has a Broker fault or a NameServer fault.

Specifically, in this embodiment, the server may start a thread to continuously detect the response of the target cluster, and if the response of the target cluster is not received within a set time, the server may consider that the target cluster has a fault, and further determine whether the target cluster has a Broker fault or a NameServer fault according to heartbeat information returned by the target cluster.

The server can continuously update the state according to the heartbeat of the target cluster, and the server makes a further strategy according to different states. If yes, executing step S120; if the NameServer fails, step S130 is performed.

S120: if the target cluster has a Broker fault, removing the Broker with the fault in the routing table or switching the currently used cluster from the target cluster to the disaster recovery cluster.

Specifically, different coping strategies can be adopted according to the types and the number of the fault broaders in this step, for example, the broaders of the faults in the routing table are removed or the currently used cluster is switched from the target cluster to the disaster recovery cluster.

Further, referring to fig. 2, step S120 may include:

s121: if the target cluster has a Broker fault and a main Broker fault, judging whether the number of main Broker faults exceeds a set number, and if so, switching the currently used cluster from the target cluster to a disaster recovery cluster; if not, the master Broker with the fault in the routing table is removed and the slave Broker is lifted to be a new master Broker.

If more than the set number of master Broker faults occur, as an optional implementation manner, in this embodiment, if more than half of the Broker masters are found to be faulty at the same time through heartbeat detection, the server may automatically trigger the disaster recovery mechanism to update the master node information to the slave node information, thereby implementing the cluster disaster recovery automatic switching function.

If the number of the main Broker faults does not exceed the set number, the main node faults of the cluster Broker are found through heartbeat, the server can forcedly lift the slave Broker into the main Broker through remote execution of an electric master command, remove the faulty Broker from the routing table, and simultaneously can constantly send a heartbeat request to the faulty Broker at regular time, after the faulty Broker is recovered to be normal, the faulty Broker can be re-added into the cluster to be the slave Broker, and the server can automatically re-update the faulty Broker into the routing table.

S122: and if the target cluster has the Broker fault and the main Broker fault does not occur, eliminating the Broker with the fault in the routing table.

Specifically, in this embodiment, the server may remove the faulty spoke from the routing table, and may also send a heartbeat request to the faulty spoke constantly at regular time, and after the faulty spoke is recovered to be normal, the faulty spoke may be rejoined into the cluster to be a slave spoke, and the server may automatically update the faulty spoke into the routing table again.

S130: and if the target cluster has NameServer faults, removing the NameServer with faults in the routing table.

Specifically, the server detects the failure of the NameServer cluster through heartbeat, and the server can update the cluster routing table and reject the failure NameServer out of the routing.

Further, after the removing the NameServer that fails in the routing table, referring to FIG. 3, the method may further include:

s131: sending a heartbeat request to a faulty NameServer at regular time to determine whether the faulty NameServer is recovered to be normal;

s132: if yes, updating the NameServer address after the recovery to the routing table.

Specifically, the server may also send heartbeat requests to the failed NameServer at regular intervals, and automatically update the failed NameServer into the routing table again after the heartbeat requests are recovered to be normal.

When a node is in fault, if the node is switched through manual automatic judgment, a certain operation time is needed, and certain service is not available in the period, the method of the embodiment has the automatic switching function of the disaster recovery environment and the dual-activity environment, can avoid service faults caused by the fact that the operation is not completed in the fault, and ensures that the use of a client is still unaware in the fault period, and the normal operation of the application is not influenced.

Further, referring to fig. 4, the present application may further include a load balancing function, and specific implementation steps may include steps S140 to S170, as follows:

S140: in response to a connection operation of a client, a connection is established with the client through a number of protocols.

Specifically, the producer and consumer of the application in the client do not need to register with the clustered NameServer, the above functions can be implemented in the server, and the server can interact with the clustered NameServer. To meet various traffic scenarios, a number of different protocols may be adapted, such as: gRPC, HTTP, etc.

S150: and receiving a request instruction sent by the client.

Specifically, after the client establishes connection with the server by using different protocols, the server communicates and operates with Broker, nameServer of the cluster uniformly, so that the effect of simplifying the client is achieved.

Alternatively, the request instruction may include sending a message, creating a Topic, etc. The server can automatically create topics in batches according to the request instruction.

S160: and sending the request instruction to the target cluster so that a Broker and a NameServer of the target cluster respond to the request instruction.

S170: and receiving response information returned by the target cluster to the request instruction, and sending the response information to the client.

Referring to fig. 5, further, the present embodiment may further include:

S180: and sending the response information to the disaster recovery cluster so as to enable the disaster recovery cluster to backup the response information.

Specifically, the server may send the data generated in the target cluster to the disaster recovery cluster, and then the disaster recovery cluster may store the data in the local disk, so as to achieve data synchronization between the target cluster and the disaster recovery cluster.

S190: reading the routing table in real time, and comparing the routing table obtained by reading in real time with the existing routing table; if the routing table obtained by reading in real time is different from the existing routing table, the existing routing table is updated to the routing table obtained by reading in real time, so that load balancing is realized.

The embodiment may further include a step of monitoring the cluster operation condition, which specifically includes the following steps:

Specifically, the server side outputs a monitoring report according to the monitored link calling time, and the operation and maintenance personnel can analyze the service and cluster operation conditions according to the monitoring report, so that the next optimization is conveniently carried out.

In order to meet the requirements of various services in different scenes, the embodiment can also respectively process the new cluster and the old cluster, and if the new cluster is created, a user can realize the deployment of the new cluster by using a one-key deployment mode through a server; if the cluster is the existing cluster, the server can acquire the existing cluster information input by the user to complete the cluster nano tube. Referring to fig. 6, the step of implementing the cluster nanotube function may include S601 and/or S602 as follows:

S601: acquiring data of a to-be-newly-built cluster, and sending a command of newly-built cluster to a target host in the data of the to-be-built cluster so as to deploy a new cluster on the target host; after a new cluster is deployed, writing information of the new cluster into a database, outputting a corresponding operation log and storing the operation log.

Specifically, the user may select "new cluster" or "existing cluster of nanotubes" on the interactive interface of the server, and if "new cluster" is selected, the server may obtain relevant information that the user fills in and selects on the interactive page, for example: deploying a host and a host account password thereof, selecting a version of the RocketMQ to be deployed, a deployment mode, an environment to which the host belongs, and selecting whether to adopt a disaster recovery or dual-activity deployment mode; after the server side obtains the related information, a new cluster deployment can be completed on a corresponding host computer remotely through a script SSH, after the deployment is successful, cluster information (such as a routing table, node information, a belonged environment and the like) is written into a MySQL database to be stored, and meanwhile, an operation log is output to a local disk to be stored.

S602: acquiring data of an existing cluster, and sending a data packet to the existing cluster to perform heartbeat detection on the existing cluster; if the existing cluster is determined to have faults according to the heartbeat information returned by the existing cluster, outputting corresponding fault information to remind a user to check the data of the existing cluster; and if the existing cluster is determined to have no fault according to the heartbeat information returned by the existing cluster, writing the information of the existing cluster into a database.

Specifically, the existing cluster is a currently existing cluster, if a user selects 'nano tube existing cluster', a server side can acquire existing cluster information (such as a selected version of a deployed RocketMQ, a deployed mode, an environment of the user and a selected mode of disaster recovery or double-activity deployment) input on an interactive page by the user, after the server side acquires the information, heartbeat detection can be remotely carried out on the input cluster through a script SSH, and if node health check is not carried out in the cluster, the user is prompted to recheck the cluster information; after the heartbeat detection is passed, the cluster information is written into a MySQL database for storage. The health check is that the node does not return the response information of the heartbeat detection data packet sent by the server side to the node within the set time.

The application provides a dual-active disaster recovery method of a RocketMQ, which solves the problem that the RocketMQ of a middleware is complicated to operate in disaster recovery and dual-active environments. According to the method and the system, automatic switching of the main and standby clusters and automatic load balancing of the client can be achieved, multiple functions including one-key deployment of new clusters, existing clusters of nanotubes, automatic switching of disaster recovery, fault node isolation, automatic load balancing and the like can be achieved, meanwhile, the concept and the call of NameServer, broker are shielded, the functions of message sending, receiving, scheduling control, automatic switching, fault isolation, data synchronization and the like are provided by a service end in a unified convergence mode, and therefore the running stability of the service is improved.

Referring to fig. 7, the present application further provides a dual active disaster recovery system of a dockmq, including: client, server and cluster; the clusters comprise a target cluster and a disaster recovery cluster which are currently used;

The specific implementation of the service end in the disaster recovery dual-activity system is basically the same as the specific embodiment of the disaster recovery dual-activity method, and is not described herein.

In order to facilitate a clearer understanding of the present application, the present application will be described below in terms of one complete alternative example.

Specifically, the core of the method is a complete system which can be used for the management of the RocketMQ cluster, the automatic switching of the disaster recovery and the automatic load balancing of the client, and the method can realize multiple functions including one-key deployment of a new cluster, the existing cluster of a nano tube, the automatic switching of the disaster recovery, fault node isolation, automatic load balancing and the like, and the method of the embodiment specifically can comprise the following 3 functional modules:

a) Cluster nanotube function:

in order to meet the requirements of various services in different scenes, when the method of the embodiment is used for the first time, the server can respectively process new and old clusters, if a new cluster is established, a user can use a one-key deployment mode to realize the deployment of the new cluster; if the cluster is an existing cluster, the user is required to manually input the existing cluster information to complete the cluster nanotubes. The main processing steps are as follows:

1) Selecting a new cluster/existing nanotube cluster;

2) Selecting a new cluster, and enabling a user to fill in and select related information on an interaction page, such as: filling in a deployment host and a host account password thereof, selecting a deployment RocketMQ version, a deployment mode, an environment, and selecting whether disaster recovery or dual-activity deployment mode is adopted; after the relevant information is filled in/selected, a new cluster deployment is completed on a corresponding host computer remotely through a script SSH, after the deployment is successful, cluster information (such as a routing table, node information, an affiliated environment and the like) is written into a MySQL database to be stored, and meanwhile, an operation log is output to a local disk to be stored;

3) Selecting "existing cluster of nanotubes", and letting the user supplement the existing cluster information (e.g.: selecting a version of the deployed RocketMQ, a deployment mode, an affiliated environment, and selecting whether disaster recovery or double-activity deployment mode is adopted, after filling relevant information, remotely performing heartbeat detection on the input cluster through a script SSH, and if the health of nodes in the cluster is checked, prompting a user to re-check cluster information; after the heartbeat detection is passed, the cluster information is written into a MySQL database for storage.

b) Automatic switching disaster recovery/double articulation point function:

referring specifically to FIG. 8, wherein a Broker-master fault represents a master Broker fault, a salve node represents a slave Broker, and a master node represents a master Broker.

When a node is in fault, if the node is switched through manual automatic judgment, a certain operation time is needed, and certain service is not available in the period, the embodiment has the automatic switching function of the disaster recovery environment and the dual-activity environment, so that service faults caused by the fact that the operation is not completed in the fault time can be avoided, the fact that the use of the client is still unaware in the fault time is ensured, and the normal operation of the client application is not influenced. The main processing steps are as follows:

1) The server sends a data packet to the target cluster Broker, nameServer at regular time, and then starts a thread to continuously detect the response of the target cluster, and if the response of the target cluster is not received within a set time, the target cluster is considered to have a fault. The server side continuously updates the state according to the heartbeat of the target cluster, and meanwhile, the server side makes a further strategy according to different states;

2) The method comprises the steps that a master node of a cluster is found out through heartbeat, a server can forcedly lift a slave reader to the master reader through remote execution of an electric master command, the faulty reader is removed from a server routing table, a heartbeat request is sent to the faulty reader constantly at fixed time, the faulty reader can be rejoined into the cluster to be the slave reader after the faulty reader is recovered to be normal, and the server automatically renews the faulty reader into the routing table;

3) The cluster NameServer fault is found through heartbeat, the server can update the cluster routing table, the fault NameServer is removed from the routing, and meanwhile, a heartbeat request is sent to the fault NameServer constantly at regular time, and after the fault NameServer is recovered to be normal, the fault NameServer is automatically updated into the routing table again;

4) And the server can automatically trigger the disaster recovery mechanism to update the master node information into the slave node information by finding out that more than half of the brooker masters have faults at the same time through heartbeat, thereby realizing the automatic switching function of cluster disaster recovery.

c) Load balancing function:

the producer and consumer of the client application do not need to register with the clustered NameServer, and this part of the functionality is implemented in the server, which interacts with the clustered NameServer. To meet various service scenarios, the server may adapt to various protocols, such as: gRPC, HTTP, etc., the client establishes connection with the server by using different protocols, and the server communicates and operates with the Broker, nameServer of the cluster uniformly, thereby achieving the effect of simplifying the client. Meanwhile, the server can automatically create Topic in batches and monitor the link call time between clusters, thereby being beneficial to optimizing the service and cluster parameters. The main processing steps are as follows:

1) The producer and the consumption of the client are registered to the server;

2) The client sends a relative instruction to the server; the relative instructions may include instructions to request creation of a Topic or to send a message, among other optional instructions;

3) The server receives the request of the client, performs interactive communication with the cluster Broker, nameServer uniformly, and realizes data synchronization between the master node and the disaster recovery node;

4) The server side automatically reads a server side routing table through a timing script, and performs differential comparison with the existing routing table, and if the two routing tables have differences, a new routing table of the reading system is updated to load balancing; if there is no difference in the routing tables, no update of the load balancing configuration is required.

The beneficial effects of the embodiment are that the method capable of rapidly recovering the RocketMQ disaster recovery/dual-activity is provided, the concept and the call of NameServer, broker are shielded, the service end is responsible for providing functions of message sending, receiving, scheduling control, automatic switching, fault isolation, data synchronization and the like in a unified convergence manner, and therefore the running stability of the service is improved.

The present application may also provide another embodiment, specifically as follows:

the client performs the following steps:

1) The application service registers the service to the service end by configuring the service end IP;

2) The application service communicates and operates with the cluster Broker, nameServer through the server.

The server executes the following steps:

1) The server side issues commands and operations to the RocketMQ cluster;

2) The control console of the server performs heartbeat detection on the cluster, and executes corresponding switching functions and updates a corresponding routing table according to actual conditions;

3) The control console updates the IP of load balancing according to the change of the routing table, so as to solve the node abnormality;

4) The server side can analyze the cluster running condition according to the log, and locate and solve the problem;

5) The server can monitor the overlong time consumption of the link and output a monitoring report, and operation and maintenance personnel analyze the service and cluster operation conditions according to the monitoring report, so that the next optimization is convenient.

Referring to fig. 9, an embodiment of the present application provides a disaster recovery dual-active device of a dockmq, including:

The specific implementation of the disaster recovery dual-activity device is basically the same as the specific embodiment of the disaster recovery dual-activity method, and is not described herein.

The embodiment of the application can also provide another implementation mode, and the application software for executing the method of the application can comprise a control controller and a proxy;

the control controller executes the double-active disaster recovery method of the RocketMQ;

proxy is a software load balancing function like ngix and the control is core code.

The embodiments of the present application further provide a computer device, including a memory and a processor, where the memory stores a computer program, and the computer program when executed by the processor causes the processor to perform the method described in the foregoing embodiments.

Specifically, the computer device may be a user terminal or a server.

In this embodiment, taking a computer device as an example, the computer device is a user terminal, the specific steps are as follows:

as shown in fig. 10, the computer device 1000 may include RF (Radio Frequency) circuitry 1010, memory 1020 including one or more computer-readable storage media, an input unit 1030, a display unit 1040, a sensor 1050, audio circuitry 1060, a short-range wireless transmission module 1070, a processor 1080 including one or more processing cores, and a power supply 1090. It will be appreciated by those skilled in the art that the device structure shown in fig. 10 is not limiting of the electronic device and may include more or fewer components than shown, or may combine certain components, or a different arrangement of components.

The RF circuit 1010 may be used for receiving and transmitting signals during a message or a call, and in particular, after receiving downlink information of a base station, the downlink information is processed by one or more processors 1080; in addition, data relating to uplink is transmitted to the base station. Typically, RF circuitry 1010 includes, but is not limited to, an antenna, at least one amplifier, a tuner, one or more oscillators, a Subscriber Identity Module (SIM) card, a transceiver, a coupler, an LNA (Low Noise Amplifier ), a duplexer, and the like. In addition, the RF circuitry 1010 may also communicate with networks and other devices via wireless communications. The wireless communication may use any communication standard or protocol including, but not limited to, GSM (Global System of Mobile communication, global system for mobile communications), GPRS (General Packet Radio Service ), CDMA (Code Division Multiple Access, code division multiple access), WCDMA (Wideband Code Division Multiple Access ), LTE (Long Term Evolution, long term evolution), email, SMS (Short Messaging Service, short message service), and the like.

Memory 1020 may be used to store software programs and modules. Processor 1080 executes various functional applications and data processing by executing software programs and modules stored in memory 1020. The memory 1020 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required for at least one function, and the like; the storage data area may store data (such as audio data, phonebooks, etc.) created according to the use of the device 1000, etc. In addition, memory 1020 may include high-speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state memory device. Accordingly, memory 1020 may also include a memory controller to provide processor 1080 and input unit 1030 with access to memory 1020. While fig. 10 shows RF circuit 1010, it is to be understood that it is not an essential component of device 1000 and may be omitted entirely as desired within the scope of not changing the essence of the invention.

The input unit 1030 may be used for receiving input numeric or character information and generating keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control. In particular, the input unit 1030 may include a touch-sensitive surface 1031 and other input devices 1032. The touch-sensitive surface 1031, also referred to as a touch display screen or touch pad, may collect touch operations thereon or thereabout by a user (e.g., operations of the user on the touch-sensitive surface 1031 or thereabout using any suitable object or accessory such as a finger, stylus, etc.), and actuate the corresponding connection device according to a pre-set program. Alternatively, the touch sensitive surface 1031 may comprise two parts, a touch detection device and a touch controller. The touch detection device detects the touch azimuth of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device and converts it into touch point coordinates, which are then sent to the processor 1080 and can receive commands from the processor 1080 and execute them. In addition, the touch sensitive surface 1031 may be implemented in a variety of types, such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch-sensitive surface 1031, the input unit 1030 may include other input devices 1032. In particular, other input devices 1032 may include, but are not limited to, one or more of a physical keyboard, function keys (e.g., volume control keys, switch keys, etc.), a track ball, a mouse, a joystick, etc.

The display unit 1040 may be used to display information input by a user or information provided to a user and various graphical user interfaces of the control 1000, which may be composed of graphics, text, icons, video and any combination thereof. The display unit 1040 may include a display panel 1041, and alternatively, the display panel 1041 may be configured in the form of an LCD (Liquid Crystal Display ), an OLED (Organic Light-Emitting Diode), or the like. Further, the touch sensitive surface 1031 may be overlaid on the display panel 1041, and upon detection of a touch operation thereon or thereabout by the touch sensitive surface 1031, the touch sensitive surface is communicated to the processor 1080 to determine a type of touch event, and the processor 1080 then provides a corresponding visual output on the display panel 1041 based on the type of touch event. Although in fig. 10 the touch-sensitive surface 1031 and the display panel 1041 are implemented as two separate components for input and output functions, in some embodiments the touch-sensitive surface 1031 may be integrated with the display panel 1041 to implement the input and output functions.

The computer device 1000 may also include at least one sensor 1050, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor that may adjust the brightness of the display panel 1041 according to the brightness of ambient light, and a proximity sensor that may turn off the display panel 1041 and/or the backlight when the device 1000 moves to the ear. As one of the motion sensors, the gravity acceleration sensor can detect the acceleration in all directions (generally three axes), and can detect the gravity and the direction when the mobile phone is stationary, and can be used for applications of recognizing the gesture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer gesture calibration), vibration recognition related functions (such as pedometer and knocking), and the like; other sensors such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc. that may also be configured with the device 1000 are not described in detail herein.

Audio circuitry 1060, a speaker 1061, and a microphone 1062 may provide an audio interface between a user and the device 1000. Audio circuit 1060 may transmit the received electrical signal after audio data conversion to speaker 1061 for conversion by speaker 1061 into an audio signal output; on the other hand, microphone 1062 converts the collected sound signals into electrical signals, which are received by audio circuit 1060 and converted into audio data, which are processed by audio data output processor 1080 for transmission to another control device via RF circuit 1010 or for output to memory 1020 for further processing. Audio circuitry 1060 may also include an ear bud jack to provide communication of peripheral headphones with device 1000.

The short-range wireless transmission module 1070 may be a WIFI (wireless fidelity ) module, a bluetooth module, an infrared module, or the like. The device 1000 may communicate information with a wireless transmission module provided on the combat device via the short-range wireless transmission module 1070.

Processor 1080 is a control center of device 1000 and connects the various parts of the overall control device using various interfaces and lines to perform various functions of device 1000 and process data by running or executing software programs and/or modules stored in memory 1020 and invoking data stored in memory 1020 to thereby monitor the control device as a whole. Optionally, processor 1080 may include one or more processing cores; alternatively, processor 1080 may integrate an application processor primarily handling operating systems, user interfaces, applications, etc., with a modem processor primarily handling wireless communications. It will be appreciated that the modem processor described above may not be integrated into processor 1050.

The device 1000 also includes a power source 1090 (e.g., a battery) for powering the various components, which can be logically connected to the processor 1080 by a power management system, such as to perform charge, discharge, and power management functions. The power source 1090 may also include one or more of any of a direct current or alternating current power source, a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator, and the like.

Although not shown, the device 1000 may further include a camera, a bluetooth module, etc., which will not be described herein. The embodiment of the application also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program realizes the disaster recovery dual-activity method when being executed by a processor.

The memory, as a non-transitory computer readable storage medium, may be used to store non-transitory software programs as well as non-transitory computer executable programs. In addition, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory optionally includes memory remotely located relative to the processor, the remote memory being connectable to the processor through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The present application also discloses a computer program product or a computer program comprising computer instructions stored in a computer readable storage medium. The computer instructions may be read by a processor of an electronic device from a computer-readable storage medium and executed by the processor to cause the electronic device to perform the method shown in fig. 1.

In some alternative embodiments, the functions/acts noted in the block diagrams may occur out of the order noted in the operational illustrations. 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/acts involved. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example in order to provide a more thorough understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed, and in which sub-operations described as part of a larger operation are performed independently.

Furthermore, while the present application is described in the context of functional modules, it should be appreciated that, unless otherwise indicated, one or more of the described functions and/or features may be integrated in a single physical device and/or software module or one or more functions and/or features may be implemented in separate physical devices or software modules. It will also be appreciated that a detailed discussion of the actual implementation of each module is not necessary to an understanding of the present application. Rather, the actual implementation of the various functional modules in the apparatus disclosed herein will be apparent to those skilled in the art from consideration of their attributes, functions and internal relationships. Thus, those of ordinary skill in the art will be able to implement the present application as set forth in the claims without undue experimentation. It is also to be understood that the specific concepts disclosed are merely illustrative and are not intended to be limiting upon the scope of the application, which is to be defined by the appended claims and their full scope of equivalents.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing an electronic device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Logic and/or steps represented in the flowcharts or otherwise described herein, e.g., a ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic device) having one or more wires, a portable computer diskette (magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). In addition, the computer readable medium may even be paper or other suitable medium on which the program is printed, as the program may be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.

It is to be understood that portions of the present application may be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, the various steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, may be implemented using any one or combination of the following techniques, as is well known in the art: discrete logic circuits having logic gates for implementing logic functions on data signals, application specific integrated circuits having suitable combinational logic gates, programmable Gate Arrays (PGAs), field Programmable Gate Arrays (FPGAs), and the like.

In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiments or examples. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

While embodiments of the present application have been shown and described, it will be understood by those of ordinary skill in the art that: many changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the application, the scope of which is defined by the claims and their equivalents.

While the preferred embodiment of the present invention has been described in detail, the present invention is not limited to the embodiment, and those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention, and the equivalent modifications or substitutions are included in the scope of the present invention as defined in the appended claims.

Claims

1. The disaster recovery dual-activity method of the RocketMQ is characterized by comprising the following steps of:

2. The dual-active disaster recovery method of claim 1, wherein if a Broker fault occurs in the target cluster, removing the Broker with the fault in the routing table or switching the currently used cluster from the target cluster to the disaster recovery cluster comprises:

3. The method for disaster recovery dual activity of a dockmq according to claim 1, further comprising, after said rejecting a failed NameServer in the routing table:

4. The dual live disaster recovery method of dockmq of claim 1, further comprising:

receiving a request instruction sent by a client;

5. The method for dual active disaster recovery as defined in claim 4, further comprising:

6. A dual active disaster recovery method for a dockmq according to any one of claims 1 to 5, further comprising:

and/or the number of the groups of groups,

7. A dual active disaster recovery method for a dockmq according to any one of claims 1 to 5, further comprising:

8. A dual active disaster recovery system of a dockmq comprising: client, server and cluster; the clusters comprise a target cluster and a disaster recovery cluster which are currently used;

the server is configured to execute a dual-active disaster recovery method of a dockmq according to any one of claims 1 to 7;

9. A disaster recovery dual-activity device of a dockmq, comprising:

10. An electronic device comprising a processor and a memory;

the memory is used for storing programs;

execution of the program by the processor implements a double liveness disaster recovery method of a dockmq as claimed in any one of claims 1 to 7.