Broker cluster updating method and device

Abstract

The invention discloses a Broker cluster updating method and device, and relates to the field of big data application, and the method comprises the steps: determining a to-be-updated target Broker cluster; the method comprises the following steps: firstly, analyzing the deployment condition of a target Broker cluster, and determining the type of each Broker node in the target Broker cluster; according to the type of each Broker node in the target Broker cluster, an updating task of the Broker cluster is generated, and the updating task of the Broker cluster comprises a plurality of updating steps; and finally, executing each updating step in the updating task of the Broker cluster to complete the updating of the target Broker cluster. In the scheme, the updating task can be generated according to the deployment condition of the Broker cluster and automatically executed to complete the updating of the target Broker cluster, so that the security of updating the Broker cluster can be guaranteed, the updating time can be shortened, and the operation and maintenance efficiency can be improved.

Description

Technical Field

[0001] The present application relates to the field of big data application technology, and in particular to a Broker cluster update method and device. Background Art

[0002] RocketMQ is a pure Java, distributed, queue-modeled open source message middleware. Broker, as the core component of RocketMQ, is used to implement message storage and transmission between producers and consumers, so that the message middleware can handle message flows in high-concurrency scenarios and process trillions of messages. Generally, a Broker cluster consists of multiple groups of master-slave nodes to achieve high availability of the cluster. In order to achieve reasonable allocation of resources, there are usually multiple Broker clusters. Therefore, the number of Broker nodes within an enterprise ranges from a dozen to hundreds. When administrators operate and maintain Broker clusters, the most common task is to modify certain configurations or modify related codes, and these changes usually require updating the Broker cluster.

[0003] In the prior art, the Broker cluster is usually updated manually. However, facing a large number of Broker nodes, manually updating the Broker cluster is not only time-consuming and laborious, but may also cause unnecessary losses due to manual operation errors.

[0004] Therefore, how to provide an automated Broker cluster update method to ensure the security of updating the Broker cluster, shorten the update time, and improve operation and maintenance efficiency has become a technical problem that needs to be urgently solved by technical personnel in this field. Summary of the invention

[0005] In view of the above problems, this application provides a Broker cluster update method and device to achieve the purpose of ensuring the security of updating the Broker cluster, shortening the update time, and improving operation and maintenance efficiency. The specific solution is as follows:

[0006] The first aspect of the present application provides a Broker cluster update method, comprising:

[0007] Determine the target Broker cluster to be updated;

[0008] Analyze the deployment status of the target Broker cluster and determine the type of each Broker node in the target Broker cluster;

[0009] Generate an update task for the Broker cluster according to the types of each Broker node in the target Broker cluster, where the update task for the Broker cluster includes multiple update steps;

[0010] Execute each update step in the update task for the Broker cluster.

[0011] In a possible implementation, the type of each Broker node in the target Broker cluster is any one of a single master node, a single slave node, and a master-slave node.

[0012] In a possible implementation, the generating the update task for the Broker cluster according to the types of each Broker node in the target Broker cluster includes:

[0013] Generate a single-node update step;

[0014] Generate the update task for the Broker cluster based on the single-node update step according to the types of each Broker node in the target Broker cluster;

[0015] Among them, the single-node update step includes:

[0016] Stop the Broker process and detect whether the Broker process has completely exited;

[0017] After detecting that the Broker process has completely exited, back up the old Broker directory, deploy the new Broker directory, and restore the data in the old Broker directory;

[0018] Start the Broker process and detect whether the Broker process has started successfully.

[0019] In a possible implementation, when the type of each Broker node in the target Broker cluster is a single slave node, the generating the update task for the Broker cluster based on the single-node update step according to the types of each Broker node in the target Broker cluster includes:

[0020] Generate an update task that only includes the single-node update step.

[0021] In a possible implementation, when the type of each Broker node in the target Broker cluster is a single master node, the generating the update task for the Broker cluster based on the single-node update step according to the types of each Broker node in the target Broker cluster includes:

[0022] Generate an update task that includes the following update steps:

[0023] Prohibit writing to the Broker node and detect whether the write traffic of the Broker node has completely stopped;

[0024] If it is detected that the write traffic of the Broker node has completely stopped, execute the single-node update step;

[0025] After the single-node update step is executed, resume writing to the Broker node and detect whether the write traffic of the Broker node has recovered.

[0026] In a possible implementation, when the types of each Broker node in the target Broker cluster are master-slave nodes, generating the update task for the Broker cluster based on the single-node update step according to the types of each Broker node in the target Broker cluster includes:

[0027] Generate an update task that includes the following update steps:

[0028] Prohibit writing to the master node and detect whether the write traffic of the master node has completely stopped;

[0029] After detecting that the write traffic of the master node has completely stopped, the slave node executes the single-node update step;

[0030] After the slave node finishes executing the single-node update step, disconnect the client link on the master node and detect whether the client link on the master node is disconnected;

[0031] After detecting that the client link on the master node is disconnected, the master node executes the single-node update step;

[0032] After the master node finishes executing the single-node update step, resume the client link on the master node and resume writing to the master node, and detect whether the write traffic of the master node has recovered.

[0033] The second aspect of this application provides a Broker cluster update device, including:

[0034] A determination unit for determining the target Broker cluster to be updated;

[0035] An analysis unit for analyzing the deployment of the target Broker cluster and determining the types of each Broker node in the target Broker cluster;

[0036] An update task generation unit, configured to generate an update task for the Broker cluster according to the types of each Broker node in the target Broker cluster, where the update task for the Broker cluster includes multiple update steps;

[0037] An update task execution unit, configured to execute each update step in the update task for the Broker cluster.

[0038] In a possible implementation, the types of each Broker node in the target Broker cluster are any one of a single master node, a single slave node, and a master-slave node.

[0039] In a possible implementation, the update task generation unit is specifically configured to:

[0040] Generate single-node update steps;

[0041] Generate the update task for the Broker cluster based on the single-node update steps according to the types of each Broker node in the target Broker cluster;

[0042] Among them, the single-node update steps include:

[0043] Stop the Broker process and detect whether the Broker process has completely exited;

[0044] After detecting that the Broker process has completely exited, back up the old Broker directory, deploy the new Broker directory, and restore the data in the old Broker directory;

[0045] Start the Broker process and detect whether the Broker process has started successfully.

[0046] In a possible implementation, when the types of each Broker node in the target Broker cluster are single slave nodes, the update task generation unit is specifically configured to:

[0047] Generate an update task that only includes the single-node update steps.

[0048] In a possible implementation, when the types of each Broker node in the target Broker cluster are single master nodes, the update task generation unit is specifically configured to:

[0049] Generate an update task that includes the following update steps:

[0050] Prohibit writing to the Broker node and detect whether the write traffic of the Broker node has completely stopped;

[0051] If it is detected that the write traffic of the Broker node has completely stopped, then execute the single-node update step;

[0052] After the single-node update step is executed, resume writing to the Broker node and detect whether the write traffic of the Broker node has recovered.

[0053] In a possible implementation, when the types of the Broker nodes in the target Broker cluster are master-slave nodes, the update task generation unit is specifically configured to:

[0054] Generate an update task including the following update steps:

[0055] Prohibit writing to the master node and detect whether the write traffic of the master node has completely stopped;

[0056] After detecting that the write traffic of the master node has completely stopped, the slave node executes the single-node update step;

[0057] After the slave node finishes executing the single-node update step, disconnect the client link on the master node and detect whether the client link on the master node is disconnected;

[0058] After detecting that the client link on the master node is disconnected, the master node executes the single-node update step;

[0059] After the master node finishes executing the single-node update step, resume the client link on the master node and resume writing to the master node, and detect whether the write traffic of the master node has recovered.

[0060] The third aspect of this application provides a computer program product, including computer-readable instructions, which, when running on an electronic device, enable the electronic device to implement the Broker cluster update method of the first aspect or any implementation manner of the first aspect.

[0061] The fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, where:

[0062] The memory is used to store a computer program;

[0063] The processor is used to execute the computer program so that the electronic device can implement the Broker cluster update method of the first aspect or any implementation manner of the first aspect.

[0064] A fifth aspect of the present application provides a computer-readable storage medium carrying one or more computer programs, which, when executed by an electronic device, can enable the electronic device to perform the Broker cluster update method according to the first aspect or any implementation manner of the first aspect above.

[0065] By means of the above technical solution, for the Broker cluster update method and device provided by the present application, after determining the target Broker cluster to be updated, first analyze the deployment situation of the target Broker cluster to determine the types of each Broker node in the target Broker cluster; and generate an update task for the Broker cluster according to the types of each Broker node in the target Broker cluster. The update task of the Broker cluster includes multiple update steps; finally, execute each update step in the update task of the Broker cluster to complete the update of the target Broker cluster. In this solution, an update task can be generated and automatically executed according to the deployment situation of the Broker cluster to complete the update of the target Broker cluster, which can ensure the security of updating the Broker cluster, shorten the update time, and improve the operation and maintenance efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] In combination with the accompanying drawings and with reference to the following specific embodiments, the above and other features, advantages and aspects of the embodiments of the present disclosure will become more obvious. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the original components and elements are not necessarily drawn to scale.

[0067] Figure 1 It is a schematic flowchart of a Broker cluster update method provided by an embodiment of the present application;

[0068] Figure 2 It is a schematic diagram of a Broker cluster update task provided by an embodiment of the present application;

[0069] Figure 3 It is a schematic diagram of the state transition of a Broker cluster update task provided by an embodiment of the present application;

[0070] Figure 4 It is a schematic diagram of the state transition of an update step provided by an embodiment of the present application;

[0071] Figure 5 It is a schematic diagram of an example of a partial page of a Web page provided by an embodiment of the present application;

[0072] Figure 6 It is a schematic diagram of an example of a partial page of a Web page provided by an embodiment of the present application;

[0073] Figure 7 Schematic structural diagram of a Broker cluster update device provided by an embodiment of the present application;

[0074] Figure 8 Schematic structural diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0075] To facilitate the understanding of the present application, first, the relevant technical terms of the present application are explained as follows:

[0076] RocketMQ: An open-source distributed message middleware by Alibaba.

[0077] Broker: The core component of RocketMQ, used for message storage and reading.

[0078] Broker master node: The broker node responsible for reading and writing.

[0079] Broker slave node: Used to synchronize the data of the master node and ensure high availability together with the master node.

[0080] Broker cluster: An architecture composed of multiple groups of Broker master-slave nodes.

[0081] Consumer: The client program that consumes messages from RocketMQ.

[0082] Producer: The client program that sends messages to RocketMQ.

[0083] Client: A general term for producers and consumers.

[0084] NameServer: The routing discovery component of RocketMQ. After a Broker registers with NameServer, the client can discover the Broker from NameServer.

[0085] Next, the embodiments of the present application are described with reference to the accompanying drawings in the embodiments of the present application. The terms used in the implementation part of the present application are only for explaining the specific embodiments of the present application and are not intended to limit the present application.

[0086] Next, the embodiments of the present application are described with reference to the accompanying drawings. Those skilled in the art know that with the development of technology and the emergence of new scenarios, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.

[0087] In the description and claims of this application, as well as in the above-mentioned drawings, terms such as "first" and "second" are used to distinguish similar objects and do not necessarily describe a specific order or sequence. It should be understood that such terms can be interchanged under appropriate circumstances, which is merely a way of distinguishing objects with the same attributes when describing the embodiments of this application. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, so that a process, method, system, product or device comprising a series of units does not have to be limited to those units, but may include other units that are not clearly listed or are inherent to these processes, methods, products or devices.

[0088] As an open-source message middleware with a pure Java, distributed, and queue model, Broker, as the core component of this message middleware, is used to implement message storage and transmission between producers (Producers) and consumers (Consumers), so that this message middleware can handle message flows in high-concurrency scenarios and process messages at the trillion level. Generally, a Broker cluster consists of multiple groups of master-slave nodes to achieve high availability of the cluster. And to achieve reasonable resource allocation, there are usually multiple Broker clusters. Therefore, there are at least a dozen or up to hundreds of Broker nodes within an enterprise. When administrators operate and maintain a Broker cluster, the most common tasks are to modify certain configurations or relevant codes, and these changes usually require updating the Broker cluster.

[0089] In the prior art, the method of manually updating the Broker cluster is usually adopted. However, in the face of a large number of Broker nodes, when manually updating the Broker cluster, it is not only time-consuming and laborious, but also may cause unnecessary losses due to manual operation errors.

[0090] To solve the above problems, an automated mechanism is required for Broker cluster updates to ensure the security of updating the Broker cluster, shorten the update time, and improve the operation and maintenance efficiency.

[0091] In view of this, the embodiments of this application provide a method for updating a Broker cluster. This method for updating a Broker cluster can detect various deployment situations of the Broker cluster, generate an automatic update task, and this task will execute the update operation in the order of the update steps and support detecting the update result. Therefore, it can ensure the security of updating the Broker cluster, shorten the update time, and improve the operation and maintenance efficiency. The method for updating a Broker cluster in the embodiments of this application will be introduced in detail below with reference to the accompanying drawings.

[0092] Refer to Figure 1 ,Figure 1 This is a schematic flowchart of a method for updating a Broker cluster provided by an embodiment of the present application. As Figure 1 shown, a method for updating a Broker cluster provided by an embodiment of the present application may include the following steps, and these steps will be described in detail below.

[0093] S101: Determine the target Broker cluster to be updated;

[0094] In the present application, the target Broker cluster to be updated may be any one or more Broker clusters within an enterprise.

[0095] S102: Analyze the deployment of the target Broker cluster and determine the types of each Broker node in the target Broker cluster;

[0096] In the present application, a Broker cluster analyzer may be preset, and the Broker cluster analyzer analyzes the deployment of the target Broker cluster, and then determines the types of each Broker node in the target Broker cluster.

[0097] It should be noted that no matter how complex a Broker cluster is, it is composed of Broker nodes of the following three roles:

[0098] 1. A single master node.

[0099] 2. A single slave node.

[0100] 3. Master-slave nodes.

[0101] Therefore, the types of each Broker node in the target Broker cluster are any one of a single master node, a single slave node, and master-slave nodes.

[0102] S103: Generate an update task for the Broker cluster according to the types of each Broker node in the target Broker cluster, and the update task of the Broker cluster includes multiple update steps;

[0103] For ease of understanding, refer to Figure 2 , Figure 2 This is a schematic diagram of a Broker cluster update task provided by an embodiment of the present application. As Figure 2As shown in the figure, BrokerAutoUpdate represents a Broker cluster update task, which contains two attributes: cluster_id and status. Among them, the attribute cluster_id is the identifier of the Broker cluster to be updated, used to indicate which Broker cluster this Broker cluster update task is for, and the attribute status is used to indicate the status of this Broker cluster update task.

[0104] This Broker cluster update task contains multiple BrokerAutoUpdateStep, and each BrokerAutoUpdateStep represents an update step, which contains three attributes: action, order, and status. Among them, the attribute action is used to indicate the operation that the update step needs to execute, the attribute order is used to indicate the order of the update step, and the attribute status is used to indicate the status of the update step.

[0105] Next, the status of the Broker cluster update task and the status of the update steps will be described in detail.

[0106] In a possible implementation, the status of the Broker cluster update task includes the following:

[0107] 1. Initial state: It represents a newly created task that has not started execution yet.

[0108] 2. Ready state: It represents waiting for execution.

[0109] 3. In progress: It represents that the task is being executed.

[0110] 4. Paused: Because the update takes too long, it is necessary to support pausing.

[0111] 5. Success: The task has been executed and executed successfully.

[0112] 6. Failure: The task has been executed and executed failed.

[0113] 7. Manually ended: For tasks that have not been executed completely, it is possible to support ending them manually in advance to cope with unexpected situations.

[0114] For the convenience of understanding, in this application, a state transition diagram of the Broker cluster update task is also disclosed. For details, please refer to Figure 3 . Such as Figure 3As shown, the Broker cluster update task in the initial state can be started or ended manually. The Broker cluster update task in the ready state can only be automatically executed and changes to in progress. The in-progress Broker cluster update task can be paused manually. The in-progress Broker cluster update task will eventually succeed, fail, or be ended manually.

[0115] In a possible implementation, the states of the update steps include the following:

[0116] 1. Initial state: Indicates a newly created step that has not started execution yet.

[0117] 2. In progress: Indicates that the step is being automatically executed.

[0118] 3. Success: The step has been executed and the status check is OK.

[0119] 4. Failure: The step execution has failed.

[0120] 5. End manually: For steps in the initial state, they can be ended manually to skip the execution of the step.

[0121] For ease of understanding, in this application, a state transition diagram of the update steps is also disclosed. For details, please refer to Figure 4 . As Figure 4 shown, the update steps in the initial state can be ended manually or be automatically executed. The in-progress update steps can be ended manually or be automatically executed successfully or fail. The failed update steps can be manually re-executed.

[0122] It should be noted that the update steps not only have states but also operation behaviors. In a possible implementation, the operation behaviors of the update steps include the following:

[0123] 1. Stop writing: The Broker stops writing.

[0124] 2. Deregister: The Broker no longer sends heartbeats to the NameServer.

[0125] 3. Shutdown: Shutdown the Broker process.

[0126] 4. Backup data: Back up the entire deployment directory of the Broker.

[0127] 5. Deploy Broker: Download the RocketMQ build and deploy it to the new Broker.

[0128] 6. Restore data: Move the backed-up Broker data to the newly deployed Broker.

[0129] 7. Startup: Start the Broker process.

[0130] 8. Registration: The Broker will send a heartbeat to the NameServer.

[0131] 9. Resume Writing: The Broker enables the write permission.

[0132] S104: Execute each update step in the update task of the Broker cluster.

[0133] In this application, each update step in the update task of the Broker cluster can be executed in sequence. When executing an update step, the update step can be detected to check whether it is executed successfully. Only when the update step is executed successfully, the next update step is executed. It should be noted that in this application, different detections can be made for different update steps. Specifically, different update steps can use different detection conditions, which will be elaborated later.

[0134] It should be noted that when executing each update step in the update task of the Broker cluster, the execution status and time consumption of the update task of the Broker cluster can be recorded, or the execution status and time consumption of each update step can also be recorded.

[0135] In this application, a Web page can be developed so that managers can visually monitor the execution status and time consumption of the update task of the Broker cluster, and operate on the update task of the Broker cluster. Example schematic diagrams of some pages of the Web page are as Figure 5 shown. A Web page can also be developed so that managers can visually monitor the execution status and time consumption of each update step in the update task of the Broker cluster, and operate on each update step. Example schematic diagrams of some pages of the Web page are as Figure 6 shown.

[0136] The Broker cluster update method provided in this embodiment, after determining the target Broker cluster to be updated; first analyzes the deployment situation of the target Broker cluster to determine the types of each Broker node in the target Broker cluster; and generates an update task for the Broker cluster according to the types of each Broker node in the target Broker cluster. The update task of the Broker cluster includes multiple update steps; finally, each update step in the update task of the Broker cluster is executed to complete the update of the target Broker cluster. In this solution, an update task can be generated and automatically executed according to the deployment situation of the Broker cluster to complete the update of the target Broker cluster, which can ensure the security of updating the Broker cluster, shorten the update time, and improve the operation and maintenance efficiency.

[0137] In the subsequent embodiments of this application, the update tasks in various different deployment situations are described in detail as follows:

[0138] In a possible implementation, a single-node update step can be generated first in this application. The single-node update step includes:

[0139] S201: Stop the Broker process and detect whether the Broker process has completely exited;

[0140] In this application, a stop instruction can be sent to the Broker process, and the Broker process executes the Broker stop instruction to stop the Broker process. After the Broker process executes the stop instruction, the Broker process does not immediately exit because when the Broker process exits, it will perform operations such as resource destruction and data flushing to disk. Only after the Broker process has completely exited can subsequent steps be executed, otherwise data incompleteness may occur. Therefore, it is necessary to detect whether the Broker process has completely exited and execute subsequent steps after detecting that the Broker process has completely exited.

[0141] S202: After detecting that the Broker process has completely exited, back up the old Broker directory, deploy a new Broker directory, and restore the data in the old Broker directory;

[0142] In this application, regardless of the role of the Broker node, its deployment structure is usually similar to the following:

[0143] Broker directory

[0144] |-- bin / / Executable file directory for starting the Broker

[0145] |-- conf / / Configuration file directory of the Broker

[0146] |-- data / / The data directory of the Broker

[0147] |-- lib / / The compiled code directory of the Broker

[0148] |-- logs / / The log directory during the operation of the Broker

[0149] Generally, when updating the Broker node, it is necessary to first back up the old Broker directory, then deploy a new Broker directory, and finally restore the data in the backed-up old Broker directory.

[0150] In a possible implementation, backing up the old Broker directory can be achieved by renaming the old Broker directory. For example, rename the old Broker directory to Broker.bak.

[0151] In a possible implementation, deploying the new Broker directory specifically refers to deploying (directly unzipping) the new RocketMQ build (usually a zip package) as the new Broker directory.

[0152] In a possible implementation, restoring the data in the old Broker directory means copying the data directory in the old Broker directory to the data directory in the new Broker directory.

[0153] S203: Start the Broker process and detect whether the Broker process is successfully started.

[0154] In this application, a start instruction can be sent to the Broker process, and the Broker process executes the Broker start instruction to start the Broker process. If the data volume of the Broker is very large, such as T level, since the Broker needs to verify and load data, then the Broker startup will be a very time-consuming process. It is necessary to wait until the Broker is fully started and can communicate normally before it can be considered successfully started. Therefore, in this application, after starting the Broker process, it is necessary to detect whether the Broker process is successfully started. After the Broker process is successfully started, the single-node update step is completed.

[0155] Based on the above single-node update steps, generating the update task for the Broker cluster according to the types of each Broker node in the target Broker cluster includes: generating the update task for the Broker cluster based on the single-node update steps according to the types of each Broker node in the target Broker cluster.

[0156] In a possible implementation, when the types of the Broker nodes in the target Broker cluster are single slave nodes, generating the update task of the Broker cluster according to the types of the Broker nodes in the target Broker cluster and based on the single-node update step includes: generating an update task that only includes the single-node update step.

[0157] In a possible implementation, when the types of the Broker nodes in the target Broker cluster are single master nodes, generating the update task of the Broker cluster according to the types of the Broker nodes in the target Broker cluster and based on the single-node update step includes:

[0158] Generating an update task that includes the following update steps:

[0159] S301: Prohibit writing to the Broker node and detect whether the write traffic of the Broker node has completely stopped;

[0160] In this application, when a single master node is being updated, writing needs to be prohibited because it is necessary to ensure that the client can send and consume messages normally during the update. Therefore, in this application, a write prohibition instruction needs to be sent to the Broker node, and the client will perceive through the NameServer that the Broker node is not writable, so it will no longer send messages to this Broker. After prohibiting writing to the Broker node, it is necessary to wait until no client writes messages anymore before performing the update, otherwise the write may fail. Therefore, it is necessary to detect whether the write traffic of the Broker node has completely stopped. In a possible implementation, it can be determined whether the write traffic of the Broker node has completely stopped by detecting whether the write traffic of the Broker node is 0.

[0161] S302: If it is detected that the write traffic of the Broker node has completely stopped, then execute the single-node update step;

[0162] S303: After the single-node update step is executed, resume writing to the Broker node and detect whether the write traffic of the Broker node has recovered.

[0163] In this application, it is necessary to wait until the read and write traffic of the client has recovered to indicate that the update of the Broker cluster is complete. Therefore, in this application, a writable instruction needs to be sent to the Broker node to resume writing to the Broker node. In a possible implementation, it can be determined whether the write traffic of the Broker node has recovered by detecting whether the write traffic of the Broker node is greater than 0.

[0164] In a possible implementation, when the types of the Broker nodes in the target Broker cluster are master-slave nodes, generating the update task for the Broker cluster based on the types of the Broker nodes in the target Broker cluster and based on the single-node update step includes:

[0165] Generating an update task including the following update steps:

[0166] S401: Prohibit writing to the master node and detect whether the write traffic of the master node has completely stopped;

[0167] In this application, writing needs to be prohibited when the master node is updated because the data of the slave nodes is synchronized from the master node. If the master node does not stop writing, directly updating the slave nodes may cause data loss. Therefore, in this application, it is necessary to prohibit writing to the master node and detect whether the write traffic of the master node has completely stopped. In a possible implementation, it can be known whether the write traffic of the master node has completely stopped by detecting whether the write traffic of the master node is 0.

[0168] S402: After detecting that the write traffic of the master node has completely stopped, the slave nodes execute the single-node update step;

[0169] After detecting that the write traffic of the master node has completely stopped, the slave nodes then execute the single-node update step, which can avoid data loss.

[0170] S403: After the slave nodes complete the single-node update step, disconnect the client connections on the master node and detect whether the client connections on the master node are disconnected;

[0171] In this application, although the master node has stopped writing, there may still be clients consuming from the master node. If the update is forced without waiting for the consumption to finish, it may cause duplicate consumption by the clients. Therefore, after the slave nodes execute the single-node update step, it is necessary to disconnect the client connections on the master node. A deregistration instruction can be sent to the master node, and the master node deregisters from the NameServer. After the master node deregisters, the clients will perceive that the Broker node is offline through routing and will disconnect the underlying connection with the Broker node. In a possible implementation, it can be known whether the client connections on the master node are disconnected by detecting whether the number of client connections on the master node is 0.

[0172] S404: After detecting that the client connections on the master node are disconnected, the master node executes the single-node update step;

[0173] S405: After the single-node update step is completed on the master node, restore the client connections on the master node and resume writing to the master node, and detect whether the write traffic of the master node has been restored.

[0174] In this application, it is necessary to restore the client connections on the master node and wait for the client read / write traffic to be restored to indicate that the Broker cluster update is completed. Therefore, in this application, a writable instruction needs to be sent to the master node to resume writing to the master node. In a possible implementation, a registration instruction can be sent to the master node, and the master node registers with the NameServer to restore the client connections on the master node. In a possible implementation, it can be determined whether the write traffic of the master node has been restored by detecting whether the write traffic of the master node is greater than 0.

[0175] It should be noted that for the Broker cluster update when the type of each Broker node is a master-slave node, it is necessary to first stop writing to the master node, then update the slave nodes, and then perform the update of the master node. The entire update process is to ensure that the client message sending and receiving are not affected during the update.

[0176] The above introduces a Broker cluster update method provided by an embodiment of this application. The following will introduce an apparatus for executing the above Broker cluster update method.

[0177] Please refer to Figure 7 , Figure 7 which is a schematic structural diagram of a Broker cluster update apparatus provided by an embodiment of this application. As Figure 7 shown, the Broker cluster update apparatus includes:

[0178] A determination unit 11, configured to determine a target Broker cluster to be updated;

[0179] An analysis unit 12, configured to analyze the deployment of the target Broker cluster and determine the types of each Broker node in the target Broker cluster;

[0180] An update task generation unit 13, configured to generate an update task for the Broker cluster according to the types of each Broker node in the target Broker cluster, where the update task for the Broker cluster includes multiple update steps;

[0181] An update task execution unit 14, configured to execute each update step in the update task for the Broker cluster.

[0182] In a possible implementation, the types of each Broker node in the target Broker cluster are any one of a single master node, a single slave node, and a master-slave node.

[0183] In a possible implementation, the update task generation unit is specifically configured to:

[0184] Generate a single-node update step;

[0185] Based on the types of each Broker node in the target Broker cluster, generate an update task for the Broker cluster based on the single-node update step;

[0186] Wherein, the single-node update step includes:

[0187] Stop the Broker process and detect whether the Broker process has completely exited;

[0188] After detecting that the Broker process has completely exited, back up the old Broker directory, deploy the new Broker directory, and restore the data in the old Broker directory;

[0189] Start the Broker process and detect whether the Broker process has been successfully started.

[0190] In a possible implementation, when the type of each Broker node in the target Broker cluster is a single slave node, the update task generation unit is specifically configured to:

[0191] Generate an update task that only includes the single-node update step.

[0192] In a possible implementation, when the type of each Broker node in the target Broker cluster is a single master node, the update task generation unit is specifically configured to:

[0193] Generate an update task that includes the following update steps:

[0194] Prohibit writing to the Broker node and detect whether the write traffic of the Broker node has completely stopped;

[0195] If it is detected that the write traffic of the Broker node has completely stopped, execute the single-node update step;

[0196] After the single-node update step is executed, resume writing to the Broker node and detect whether the write traffic of the Broker node has been restored.

[0197] In a possible implementation, when the type of each Broker node in the target Broker cluster is a master-slave node, the update task generation unit is specifically configured to:

[0198] Generate an update task that includes the following update steps:

[0199] Prohibit writing to the master node and detect whether the write traffic of the master node has completely stopped;

[0200] After detecting that the write traffic of the master node has completely stopped, the slave node executes the single-node update step;

[0201] After the slave node finishes executing the single-node update step, disconnect the client link on the master node and detect whether the client link on the master node is disconnected;

[0202] After detecting that the client link on the master node is disconnected, the master node executes the single-node update step;

[0203] After the master node finishes executing the single-node update step, restore the client link on the master node and resume writing to the master node, and detect whether the write traffic of the master node is restored.

[0204] An electronic device is also provided in an embodiment of the present application. Refer to Figure 8 As shown, it shows a schematic structural diagram of an electronic device suitable for implementing the electronic device in an embodiment of the present application. The electronic device in an embodiment of the present application may include, but is not limited to, fixed terminals such as mobile phones, laptop computers, PDAs (Personal Digital Assistants), PADs (Tablet Computers), desktop computers, and the like. Figure 8 The electronic device shown is only an example and should not bring any limitations to the functions and usage scopes of the embodiments of the present application.

[0205] As Figure 8 As shown, the electronic device may include a processing device (such as a central processing unit, a graphics processing unit, etc.) 601, which may execute various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 into a random access memory (RAM) 603. When the electronic device is powered on, various programs and data required for the operation of the electronic device are also stored in the RAM 603. The processing device 601, the ROM 602, and the RAM 603 are connected to each other through a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0206] Generally, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 608 including, for example, a memory card, a hard disk, etc.; and a communication device 609. The communication device 609 may allow the electronic device to communicate with other devices wirelessly or wiredly to exchange data. AlthoughFigure 8 An electronic device having various devices is shown, but it should be understood that it is not required to implement or have all the shown devices. Instead, more or fewer devices may be implemented or had.

[0207] An embodiment of the present application also provides a computer program product including computer-readable instructions, which, when running on an electronic device, enable the electronic device to implement any one of the Broker cluster update methods provided by the embodiments of the present application.

[0208] An embodiment of the present application also provides a computer-readable storage medium carrying one or more computer programs, which, when executed by an electronic device, can enable the electronic device to implement any one of the Broker cluster update methods provided by the embodiments of the present application.

[0209] In addition, it should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, in the attached drawings of the device embodiments provided by the present application, the connection relationships between the modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines.

[0210] Through the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software plus necessary general hardware, and of course, it can also be implemented by dedicated hardware including application-specific integrated circuits, dedicated CPUs, dedicated memories, dedicated components, etc. Generally, functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structures for implementing the same function can also be various, such as analog circuits, digital circuits or dedicated circuits. However, for the present application, in more cases, software program implementation is a better implementation method. Based on such an understanding, the technical solution of the present application, in essence or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a readable storage medium, such as a floppy disk, a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disc of a computer, including several instructions for enabling a computer device (which may be a personal computer, a training device, or a network device, etc.) to execute the methods described in the various embodiments of the present application.

[0211] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product.

[0212] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another, for example, the computer instructions may be transmitted from a website, computer, training device, or data center to another website, computer, training device, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that includes one or more integrated available media. The available medium may be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (SSD)).

Claims

1. A method for updating a Broker cluster, characterized in that Including: Determine the target Broker cluster to be updated; Analyze the deployment of the target Broker cluster and determine the types of each Broker node in the target Broker cluster; Generate an update task for the Broker cluster according to the types of each Broker node in the target Broker cluster, and the update task of the Broker cluster includes multiple update steps; Execute each update step in the update task of the Broker cluster.

2. The method according to claim 1, wherein The types of each Broker node in the target Broker cluster are any one of a single master node, a single slave node, and a master-slave node.

3. The method according to claim 2, wherein The generating the update task of the Broker cluster according to the types of each Broker node in the target Broker cluster includes: Generate single-node update steps; Generate the update task of the Broker cluster based on the single-node update steps according to the types of each Broker node in the target Broker cluster; Among them, the single-node update steps include: Stop the Broker process and detect whether the Broker process has completely exited; After detecting that the Broker process has completely exited, back up the old Broker directory, deploy the new Broker directory, and restore the data in the old Broker directory; Start the Broker process and detect whether the Broker process has started successfully.

4. The method according to claim 3, characterized in that When the types of each Broker node in the target Broker cluster are single slave nodes, the generating the update task of the Broker cluster based on the single-node update steps according to the types of each Broker node in the target Broker cluster includes: Generate an update task that only includes the single-node update steps.

5. The method according to claim 3, wherein When the types of each Broker node in the target Broker cluster are single master nodes, the generating the update task of the Broker cluster based on the single-node update steps according to the types of each Broker node in the target Broker cluster includes: Generate an update task that includes the following update steps: Prohibit writing to the Broker node and detect whether the write traffic of the Broker node has completely stopped; If it is detected that the write traffic of the Broker node has completely stopped, execute the single-node update steps; After the single-node update steps are executed, resume writing to the Broker node and detect whether the write traffic of the Broker node has resumed.

6. The method according to claim 3, wherein When the types of each Broker node in the target Broker cluster are master-slave nodes, the generating the update task of the Broker cluster based on the single-node update steps according to the types of each Broker node in the target Broker cluster includes: Generate an update task that includes the following update steps: Prohibit writing to the master node and detect whether the write traffic of the master node has completely stopped; After detecting that the write traffic of the master node has completely stopped, the slave node executes the single-node update step; After the slave node finishes executing the single-node update step, disconnect the client link on the master node and detect whether the client link on the master node is disconnected; After detecting that the client link on the master node is disconnected, the master node executes the single-node update step; After the master node finishes executing the single-node update step, restore the client link on the master node and resume writing to the master node, and detect whether the write traffic of the master node is restored.

7. A Broker cluster update device, characterized in that, Comprising: A determination unit for determining the target Broker cluster to be updated; An analysis unit for analyzing the deployment of the target Broker cluster and determining the types of each Broker node in the target Broker cluster; An update task generation unit for generating an update task for the Broker cluster according to the types of each Broker node in the target Broker cluster, where the update task for the Broker cluster includes multiple update steps; An update task execution unit for executing each update step in the update task for the Broker cluster.

8. A computer program product, characterized in that, Comprising computer-readable instructions, when the computer-readable instructions run on an electronic device, enabling the electronic device to implement the Broker cluster update method according to any one of claims 1 to 6.

9. An electronic device, characterized in that, Comprising at least one processor and a memory connected to the processor, wherein: The memory is used for storing a computer program; The processor is used for executing the computer program so that the electronic device can implement the Broker cluster update method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The storage medium carries one or more computer programs, when the one or more computer programs are executed by an electronic device, enabling the electronic device to implement the Broker cluster update method according to any one of claims 1 to 6.

Images