WO2023280127A1 - 一种消息通信方法和装置 - Google Patents
一种消息通信方法和装置 Download PDFInfo
- Publication number
- WO2023280127A1 WO2023280127A1 PCT/CN2022/103745 CN2022103745W WO2023280127A1 WO 2023280127 A1 WO2023280127 A1 WO 2023280127A1 CN 2022103745 W CN2022103745 W CN 2022103745W WO 2023280127 A1 WO2023280127 A1 WO 2023280127A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- message
- proxy server
- node
- broker
- primary
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 87
- 238000004891 communication Methods 0.000 title claims abstract description 43
- 230000001360 synchronised effect Effects 0.000 claims description 28
- 238000004590 computer program Methods 0.000 claims description 25
- 238000003860 storage Methods 0.000 claims description 10
- 230000008569 process Effects 0.000 abstract description 32
- 239000002699 waste material Substances 0.000 abstract description 11
- 238000010586 diagram Methods 0.000 description 20
- 230000005540 biological transmission Effects 0.000 description 16
- 230000006870 function Effects 0.000 description 7
- 238000012545 processing Methods 0.000 description 7
- 230000004044 response Effects 0.000 description 7
- 238000011084 recovery Methods 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 230000009471 action Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000003672 processing method Methods 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000004806 packaging method and process Methods 0.000 description 2
- 238000004366 reverse phase liquid chromatography Methods 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- 238000005303 weighing Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/547—Messaging middleware
Definitions
- the present application relates to the technical field of communication, and in particular to a message communication method and a message communication device.
- a distributed system is a software system built on the network. For users, it can be equivalent to a single related system, but in fact it is a collection of several independent computers. Among them, the independent computers used to form the system It can be geographically dispersed, and the functions of the entire system can be realized by dispersing on each node.
- Message queue middleware (such as Rocket MQ (Rocket Message Queue, refers to an open source message middleware), ONS (Open Notification Service, open message service, based on the open source message middleware Rocket MQ), Kafka (an Open source distributed high-concurrency message middleware) etc.) are important components in distributed systems, which are mainly used to solve the problem of message transmission between distributed systems.
- Message broker is an architecture for message verification, transformation, and routing
- Broker which is a proxy server in the message system and can have the logic of sending and receiving messages with message producers and message consumers.
- each Broker monopolizes a message proxy service.
- the standby proxy server only needs to synchronize messages from the main proxy server, and its resource utilization is at a low level most of the time. This leads to a certain degree of waste of resources.
- the embodiments of the present application are proposed to provide a message communication method and a corresponding message communication device that overcome the above problems or at least partially solve the above problems.
- the embodiment of the present application discloses a message communication method, which is applied to a message system.
- the message system includes a producer, a message broker service cluster, and a consumer.
- the message broker service cluster includes multiple nodes, and each node includes a Replicas, and including a master proxy server and at least one secondary proxy server belonging to different replica groups, the method includes:
- the main proxy server of a node After the main proxy server of a node receives the message sent by the producer, it synchronizes the message with the secondary proxy server of at least one other node;
- the primary proxy server sends messages to consumers, or another node's secondary server sends messages to consumers.
- message synchronization with the sub-proxy server of at least one other node includes:
- synchronizing the message sent by the producer to at least one secondary proxy server belonging to the same replica group as the primary proxy server includes:
- the messages sent by the producer are synchronized to the proxy servers belonging to the same replica group.
- the method also includes:
- the secondary proxy server of another node synchronizes the current metadata with the primary proxy server.
- the secondary proxy server of another node synchronizes the current metadata with the primary proxy server, including:
- the secondary server of another node sends a message to the consumer, including:
- the secondary proxy server of another node sends a message to the consumer when the primary proxy server fails.
- the sub-proxy server of another node sends a message to the consumer, including:
- Messages are sent to consumers through a secondary proxy that belongs to the same replica group as the primary proxy.
- the embodiment of the present application also discloses a message communication device, which is applied to a message system.
- the message system includes a producer, a message broker service cluster, and a consumer.
- the message broker service cluster includes multiple nodes, and each node includes A replica, and includes a primary proxy server and at least one sub-proxy server belonging to different replica groups, the device includes:
- the message synchronization module is located at the main proxy server of one node, and is used to perform message synchronization with the secondary proxy server of at least one other node after receiving the message sent by the producer;
- the first message sending module is located at the main proxy server and is used to send messages to consumers;
- the second message sending module is located in the secondary server of another node, and is used to send messages to consumers.
- the message synchronization module includes:
- the message synchronization sub-module is used to synchronize messages with at least one sub-proxy server belonging to the same copy group as the main proxy server; wherein, the sub-proxy servers and the main proxy server belonging to the same copy group are located at different nodes.
- the message synchronization submodule includes:
- the proxy server quantity configuration unit is used to configure the proxy server quantity for message synchronization with the main proxy server;
- the message synchronization unit is used to synchronize the messages sent by the producer to the proxy servers belonging to the same copy group according to the configured number of proxy servers.
- the device includes:
- the metadata reverse synchronization module is located in the secondary proxy server of another node, and is used to synchronize the current metadata with the primary proxy server.
- the metadata reverse synchronization module includes:
- the metadata reverse synchronization sub-module is used for synchronizing the current metadata with the primary proxy server after the failure of the primary proxy server is repaired through a secondary proxy server belonging to the same replica group as the primary proxy server.
- the second message sending module includes:
- the message sending sub-module is located in the secondary proxy server of another node, and is used to send messages to consumers when the primary proxy server fails.
- the embodiment of the present application also discloses an electronic device, including: a processor, a memory, and a computer program stored on the memory and capable of running on the processor.
- a computer program stored on the memory and capable of running on the processor.
- the embodiment of the present application also discloses a computer-readable storage medium.
- a computer program is stored on the computer-readable storage medium.
- the steps of any message communication method are implemented.
- the embodiment of the present application also discloses a computer program.
- the computer program When the computer program is executed by a processor, the electronic device is made to execute the steps of any message communication method.
- a message processing method applied to a message system is proposed, mainly through the nodes of the message broker service cluster to realize message transmission with producers and consumers, wherein each node in the message broker service cluster can It includes a copy of each copy group, and includes a primary proxy server and at least one secondary proxy server belonging to different copy groups.
- the primary proxy server of a node receives the message sent by the producer, it can communicate with at least one other node.
- the secondary proxy server performs message synchronization, and its primary proxy server or another node's secondary proxy server can send messages to consumers.
- each node including a primary proxy server and at least one sub-proxy server, it realizes multiple Brokers on a single point, improves the utilization rate of nodes in the message proxy service cluster, and reduces the waste of node resources; and because each Each node includes a primary proxy server, which can ensure that the capabilities of each node are equal, and through the message synchronization of the primary and secondary proxy servers between different nodes, it can realize node message transmission under the premise of ensuring the consistency of each node message , especially the no-election master process in case of node failure.
- FIGS. 1A to 1C are schematic diagrams of the structure of the message queue middleware in the related art
- Fig. 2 is a schematic diagram of the architecture of the message queue middleware in the embodiment of the present application.
- Fig. 3 is a flow chart of the steps of an embodiment of a message communication method of the present application.
- FIG. 4 is a flowchart of steps of another message communication method embodiment of the present application.
- Fig. 5 is a schematic diagram of the process of data synchronization in the embodiment of the present application.
- FIG. 6 is an application scenario diagram of a message communication method in an embodiment of the present application.
- FIG. 7 is a flow chart of the steps of another message communication method embodiment of the present application.
- FIG. 8 is an application scenario diagram of another message communication in the embodiment of the present application.
- FIG. 9 is a schematic diagram of the process of metadata reverse synchronization in the embodiment of the present application.
- Fig. 10 is a schematic framework diagram of the message communication system in the embodiment of the present application.
- Fig. 11 is a structural block diagram of an embodiment of a message communication device of the present application.
- Topic is an abstract classification of a group of messages. Producers can publish messages through Topic, and consumers can subscribe to messages through Topic to realize message transmission;
- Message can refer to the combination of messages and (optional) attributes sent by the producer to the Topic and finally delivered to the consumer;
- Producer The producer and/or sender of the message, that is, the sender of the message, which can be a single server or a server cluster;
- the consumer of the message that is, the requesting party, which can also be a single server or a server cluster;
- the proxy server in the message system (that is, the message middleware server), which can have a message sending and consuming interface externally, and message producers and consumers can interact with it to complete the core message sending and receiving logic;
- Master/Leader Broker The main proxy server, which undertakes the function of providing external services under normal circumstances;
- the secondary proxy server is actually a copy of the primary proxy server. It can have all the messages on the primary proxy server and can provide external services when the primary proxy server is offline;
- Commit Log The message storage component of the message queue middleware, which is used to save all the messages received by the message queue middleware;
- Metadata Messages used to record consumption and sending status in the message queue middleware, such as consumption location, timing message playback location, etc.
- Message queuing middleware (such as Rocket MQ, ONS, Kafka, etc.) is an important component in a distributed system, which is mainly used to solve the problem of message delivery between distributed systems.
- FIGs 1A to 1C it shows Schematic diagram of the architecture of the message queue middleware, which mainly relates to the communication architecture adopted by the Broker cluster (that is, the message broker service cluster) in the message system.
- M is used to represent the master proxy server Master Broker
- S is used to represent the secondary proxy server Slave Broker.
- the communication architecture adopted by the Broker cluster is an active-standby architecture, which only supports one active and one standby, and can support multiple message replication modes to achieve message synchronization, but it adopts cold standby (standby unreadable) Deployment method, that is, the secondary proxy server is only used to synchronize the messages of the primary proxy server, but cannot provide external read and write services; and when the Master Broker fails, it needs to manually switch between the active and standby, and there are relatively large resources in large-scale scenarios. waste and operating costs.
- the communication architecture adopted by the Broker cluster is an active-standby architecture based on ZK (Zoo Keeper, distributed coordination kernel), which can support one master and multiple backups, but the deployment method adopted is also cold standby (standby Unreadable) mode, that is, the secondary proxy server is only used to synchronize the messages of the primary proxy server, but cannot provide external read and write services; it can coordinate services based on an additional Zoo Keeper cluster, realize the function of automatically selecting the master, and support the emergence of Master Broker In the event of a failure, the Slave is automatically switched to the Master to provide services, but the failover takes a long time, and it takes about 10 seconds to complete the master selection.
- ZK Zero Keeper, distributed coordination kernel
- the communication architecture adopted by the Broker cluster is the Leader-Follower architecture based on the Raft protocol (referring to the distributed consensus protocol), which can support one master and multiple backups, and can be based on the Follower provided by the Raft protocol.
- the secondary proxy server Slave Broker i.e. the secondary proxy server Slave Broker
- the Leader i.e. the main proxy server Master Broker
- the strongly consistent Raft protocol does not yet support a dynamic downgrade strategy, making it impossible to flexibly balance availability and reliability.
- each Broker will monopolize a node in the message broker service cluster, and in the copy group (referring to a group of Brokers with the same message, usually composed of one master and N standby)
- the node where the Master Broker is located undertakes all read and write services, while the node where the Slave Broker is located does not have read and write services, and only needs to synchronize messages from the Master Broker, so that the resource utilization rate of the node where the Slave Broker is located is at most of the time.
- a lower level leads to a certain degree of waste of node resources.
- each node includes a copy of each copy group, and includes a primary proxy server and at least one secondary proxy server belonging to different copy groups, so that Any node in the message broker service cluster can have the full amount of data of the cluster, realize single-point multi-Broker, improve the utilization rate of nodes in the message broker service cluster, and reduce the waste of node resources; and because each node includes a master
- the proxy server can ensure that the capabilities of each node are equal (both have read and write services), and through the message synchronization of the primary and secondary proxy servers between different nodes, the node message can be realized under the premise of ensuring the consistency of each node message. When transmitting, especially in the case of node failure, there is no master election process.
- each node in the message proxy service cluster can Nodes are configured with a primary proxy server and a secondary proxy server at the same time.
- each node can include a primary proxy server and at least one secondary proxy server to achieve single-point multi-Broker and reduce node resource waste.
- FIG. 2 it shows a schematic diagram of the architecture of the message queue middleware in the embodiment of the present application.
- the message broker service cluster using the message queue middleware architecture may include multiple nodes, such as node 1, node 2 and node 3 , each node can include multiple Brokers.
- node 1 node 1
- node 2 node 2
- node 3 each node can include multiple Brokers.
- each Broker in the existing high-availability architecture will exclusively occupy one node, and nine nodes are required to complete the deployment. Only 3 nodes are needed to complete the deployment, reducing the loss of node resources.
- each node can add or delete Broker through Broker Container (for Broker management process), and manage network request distribution and resource scheduling of all Brokers in the process.
- the added Broker can provide read and write services
- a Broker Container corresponds to manage a node, and each node can include a primary proxy server and at least one secondary proxy server. And the included proxy servers do not belong to the same copy group, that is, the messages synchronized between each sub-proxy server and between each sub-proxy server and the primary proxy server are different.
- node 1 includes active Broker_a, standby Broker_b, and Broker_c
- node 2 includes active Broker_b, standby Broker_a, and Broker_c
- node 3 includes active Broker_c, standby Broker_a, and Broker_b.
- the copy group can refer to a group of Brokers with the same message, which can usually be composed of one master and N standby.
- Other sub-proxy servers synchronize messages, and when the main proxy server fails and goes down, the rest of the sub-proxy servers can provide read services.
- the proxy servers included in each node do not belong to the same copy group, that is, the messages synchronized between the sub-proxy servers located under the same node and between the sub-proxy servers and the primary proxy server different, each node has a copy in each copy group when each copy group (for example, one primary Broker_a, two standby Broker_a, one primary Broker_b, two standby Broker_b, and one primary Broker_c, two standby Broker_c) works normally, Indicates that any node has the full amount of messages of the message broker service cluster. Under this framework, as long as one of the nodes (such as node 1, node 2 or node 3) of the message broker service cluster is in a normal working state, no Message lost.
- each node includes a master proxy server Master Broker, which can provide read and write services to ensure that the capabilities of each node are equal.
- this architecture can be applied to the core base of the second-level RTO (Recovery Time Objective) architecture of message middleware.
- RTO Reflecty Time Objective
- RTO reflects the timeliness index of data center service recovery, which can be used to indicate the time required for service from interruption to recovery. The smaller the RTO value, the stronger the data recovery capability of the disaster recovery system.
- the nodes in the message broker service cluster can refer to an environment with independent resources such as computing, memory, storage, and network, which can be physical machines, virtual machines, or containers, and realize the communication between producers and consumers.
- message transmission; and all Brokers in the same node are in the same process, that is, the Broker Container process, which is responsible for managing the Broker and serving as a shared network layer for all Brokers (all RPCs (Remote Procedure Call, Remote Procedure Call, It is a remote procedure call, and the HTTP request itself can also be regarded as a specific form of RPC) All requests need to be processed through the network layer of the Broker Container.
- FIG. 3 it shows a flow chart of the steps of an embodiment of a message communication method of the present application, which is applied to a message system.
- the message system includes a producer, a message broker service cluster and a consumer, and the message broker service cluster includes multiple nodes. Specifically, the following steps may be included:
- Step 301 after the main proxy server of a node receives the message sent by the producer, it synchronizes the message with the secondary proxy server of at least one other node;
- the message broker service cluster can realize the message transmission between the producer and the consumer.
- the nodes included in the message broker service cluster can receive the message sent by the producer and respond to the message sent by the consumer.
- the message consumption request is implemented by sending a message to the consumer.
- each node of the message proxy service cluster includes a primary proxy The server and at least one secondary proxy server do not belong to the same copy group, that is, the messages synchronized between the secondary proxy servers under the same node, and between the secondary proxy server and the primary proxy server are different.
- the primary proxy server can synchronize the message with the sub-proxy server of at least one other node to ensure that each node contains a copy of each copy group, so that each node has this message
- the agent serves the full amount of messages of the cluster to ensure the message consistency of each node.
- the master Broker_a of node 1 can perform message synchronization with the slave Broker_a of node 2 and the slave Broker_a of node 3, and the master Broker_b of node 2 can synchronize with the node
- the standby Broker_b in node 1 and the standby Broker_b in node 3 perform message synchronization
- the active Broker_c of node 3 can perform message synchronization with the standby Broker_c in node 1 and the standby Broker_c in node 3.
- step 302 the main proxy server sends a message to the consumer, or the secondary server of another node sends a message to the consumer.
- the message After the message is synchronized by each node of the message broker service cluster, the message can be sent to the consumer through the nodes of the message broker service cluster, so as to realize the message transmission between the producer and the consumer.
- each node in the message proxy service cluster may include a primary proxy server and at least one sub-proxy server.
- the primary proxy server of a certain node may send messages to the consumer The sender sends a message, or the secondary server of another node sends a message to the consumer.
- the message when the working status of a certain node is in the normal working state, the message can be sent directly to the consumer through the main proxy server of a certain node;
- the secondary server of another node In the machine state, the secondary server of another node can be used to send messages to consumers, and the secondary server of another node and the primary proxy server of a certain node belong to the same copy group, so that the process of message transmission without primary selection can be realized.
- a message processing method applied to a message system is proposed, mainly through the nodes of the message broker service cluster to realize message transmission with producers and consumers, wherein each node in the message broker service cluster can It includes a copy of each copy group, and includes a primary proxy server and at least one secondary proxy server belonging to different copy groups.
- the primary proxy server of a node receives the message sent by the producer, it can communicate with at least one other node.
- the secondary proxy server performs message synchronization, and its primary proxy server or another node's secondary proxy server can send messages to consumers.
- each node includes a master proxy server belonging to a different copy group and at least one sub-proxy server, it can realize single-point multi-Broker, improve the utilization rate of nodes in the message proxy service cluster, and reduce the resource consumption of nodes. waste; and because each node includes a master proxy server, it can ensure that the capabilities of each node are equal, and through the message synchronization of the master and sub-proxy servers between different nodes, under the premise of ensuring the consistency of each node's messages, It can realize node message transmission, especially the non-election process in the case of node failure.
- FIG. 4 shows a flow chart of the steps of another embodiment of the message communication method of the present application, which is mainly the case where each node in the message broker service cluster is in a normal working state to process the message. Specifically, it can be Including the following steps:
- Step 401 after the primary proxy server of a node receives the message sent by the producer, it synchronizes the message with at least one secondary proxy server belonging to the same copy group as the primary proxy server;
- each node of the message proxy service cluster includes a primary proxy server and at least one secondary proxy server that do not belong to the same copy group, that is, between the secondary proxy servers under the same node, and the secondary proxy server
- the messages synchronized between the server and the main proxy server are different.
- the main proxy server in the message proxy service node can communicate with the secondary proxy server of at least one other node after receiving the message sent by the producer.
- Message synchronization is carried out so that each node has the full amount of messages of the message broker service cluster to ensure the message consistency of each node.
- the message consistency may refer to that the message consistency of each copy in the copy group can be achieved through an agreed mechanism in the copy group.
- message synchronization can be performed with at least one secondary proxy server that the primary proxy server belongs to the same replica group, wherein, the primary proxy server belonging to the same replica group
- Each sub-proxy server and the primary proxy server of the group are located on different nodes.
- message synchronization between agents belonging to the same copy group may refer to data synchronization, and the data may include Commit Log, topic, subscription relationship, metadata, etc.
- FIG. 5 it shows a schematic diagram of the process of data synchronization in the embodiment of the present application.
- the message synchronization of each replica group can be realized through the data synchronization flow between each node.
- the master proxy server Master Broker of Broker_a when the master proxy server Master Broker of Broker_a is performing real-time data synchronization to the secondary proxy server Slave Broker, it can be synchronized to the standby Broker_a located in nodes 2 and 3 through the data synchronization flow from the master Broker_a located in node 1 data.
- the replica group relies on this link to achieve message consistency within the replica group.
- the copy group can also support changing the configuration to determine the consistency guarantee strength to support the dynamic downgrade strategy, which can trade off between availability and consistency, and realize the message consistency strength Configuration, which can be implemented based on the number of proxy servers configured to synchronize messages.
- the consistency configuration can refer to when the producer sends a message to a master proxy server, how many Brokers need to ensure that the message is sent successfully, that is, the strong consistency configuration and the weak consistency configuration can be It is the condition when the message received by the producer sends a successful response.
- Configure message consistency strength In the first case, when the configuration is strong consistency configuration, it means that each copy group in the message broker service cluster does not allow message inconsistency, that is, the producer is in the When sending a message to a master proxy server, the master proxy server needs to synchronize the message with all the sub-proxy servers in its copy group, and only after ensuring that the message is synchronized to all the sub-proxy servers in the copy group will it send the message to the producer The sender returns a successful response, indicating that the message has been sent successfully; if some sub-proxy servers in the copy group of the primary proxy server fail to synchronize the message or there is no sub-proxy server that successfully synchronizes the message, it means that the message has failed to be sent. The sender will automatically retry sending until the sender receives a successful response or the sender reaches the threshold of retry sending times.
- each copy group includes 1 master and 2 backups.
- the current configuration requires 3 proxy servers to synchronize messages, that is, 1 master and 2 slaves in the copy group Both need to perform message synchronization.
- each message sent to Broker_a Master in Node 1 needs to wait for the message to be synchronized to the two Slave brokers in Node 2 and Node 3. The message is considered to have been sent successfully.
- each copy group in the message broker service cluster allows message inconsistency, that is, when the producer sends a message to a master proxy server , the primary proxy server can synchronize messages to some of the sub-proxy servers in its copy group, and after ensuring that the message is synchronized to some of the configured sub-proxy servers, it can return a successful response to the sender in the producer, indicating that this Message sent successfully.
- each message sent to Broker_a Master can only be synchronized to one sub-proxy server, or even zero sub-proxy servers can be considered as successfully sent.
- this weak consistency configuration mode If a node goes down, it may cause message loss, and the strong consistency of messages in the replica group cannot be guaranteed.
- this mode of weak consistency configuration even if some nodes jitter and cause synchronization failure, it can be considered Sent successfully with higher availability.
- weak consistency configuration does not mean that only some sub-proxy servers will receive message synchronization, but that the main proxy server only needs to wait for some sub-proxy servers before returning a successful response to the sender. Synchronization is successful. At this time, the message synchronization of other sub-proxy servers remaining in its copy group is still in progress asynchronously.
- each copy group includes 1 master and 2 backups.
- the current configuration requires 3 proxy servers that need to synchronize messages.
- the current configuration requires proxy servers that need to synchronize messages The number is 1, that is, one master in the replica group needs to perform message synchronization. As long as the Master receives the message, it can immediately return a successful response without waiting for the message synchronization to complete.
- This configuration has high availability (even if the two Slaves are both A failure does not affect message sending), but the consistency of the message is low (the sender receives a successful response only to ensure that the Master has received the message, but cannot confirm that the message has been synchronized to other Slaves, or in other words, assuming that synchronization has occurred Failure, it may cause a message to exist only in the Master, but not in a Slave, that is, message inconsistency occurs).
- the above configuration can be changed at any time and takes effect in real time, and does not limit the timing of consistent configuration, and the configuration can be adjusted after weighing availability and consistency according to actual service scenarios.
- the configuration of strong consistency of messages can ensure the strong consistency of messages in the replica group, but the availability is weak, while the configuration of weak consistency of messages cannot guarantee the strong consistency of messages in the replica group. However, its availability is very high.
- the automatic downgrade mode can also be configured at this time to further support the dynamic downgrade strategy and flexibly balance availability and reliability.
- the configured auto-degradation mode can mean that the master proxy server can calculate how many Brokers a message needs to be synchronized to before it is considered successful according to the synchronization status of the current replica group and a configurable synchronization number threshold.
- the strong consistency synchronization mode is used, that is, the message needs to be synchronized to all slaves before it is considered to be sent successfully.
- the automatic Downgrade to weak consistency mode so that the message can be considered as successfully sent when it is synchronized to some Slaves, that is, enabling the automatic downgrade strategy can accept that when some Brokers experience jitter, sacrifice consistency in exchange for availability, and the synchronization number threshold is used for The lower limit of acceptable consistency loss is specified, which can ensure availability on the basis of strong message consistency.
- the automatic downgrade configuration is also changed at any time and takes effect in real time, and the timing of the automatic downgrade configuration is not limited.
- each copy group includes 1 master and 2 backups.
- the current configured mode is a strong consistency configuration, that is, 1 master and 2 slaves in the copy group
- the synchronization number threshold is set to 2
- the calculated final number of Brokers to be synchronized can be 3 (both Slaves and Master are in Real-time synchronization status), can also be 2 (when a Slave synchronization progress lags behind the Master too much), but cannot be 1 (when it is 1, generally both Slave synchronization progress lags behind the Master too much, but because the synchronization number is configured
- the threshold is 2, so in this case, sending a message will directly return failure).
- Step 402 send a message to the consumer through the main proxy server.
- a message can be sent to the consumer based on the working status of the node.
- each node in the message broker service cluster is in a normal working Send a message to the consumer to complete the message transmission between the producer and the consumer.
- the node when each node in the message broker service cluster is in a normal working state, the node can receive the message sent by the producer and respond to the message consumption request sent by the consumer.
- the master proxy server sends messages to consumers, that is, the producer only sends messages to the Master of each replica group, and the consumer only consumes messages from the Master of each replica group.
- different Brokers in the same node can be distinguished by different port numbers, that is, different brokers in the same node can listen to different port numbers, and by combining the node IP and port number, it is possible to determine which Broker to send the request to , specifically, you can specify the address IP:Port when sending the request to decide which broker to send the request to.
- the message consumption request received by the message broker service cluster may include the node communication address and the proxy service port number.
- the target node can be determined according to the node communication address, and then the target node can be determined from the target node according to the proxy service port number. Proxy server, so that the target proxy server sends the target message to the consumer.
- each node includes a primary proxy server and at least one secondary proxy server
- single-point multi-Broker is realized
- the utilization rate of nodes in the message proxy service cluster is improved, and the number of nodes is reduced. waste of resources; and since each node includes a primary proxy server belonging to a different copy group, it can ensure that the capabilities of each node are equal, and through the message synchronization of the primary and secondary proxy servers between different nodes, it is guaranteed that each node Under the premise of message consistency, it is possible to realize the no-election process of node message transmission, especially in the case of node failure.
- FIG. 7 it shows a flow chart of the steps of another message communication method embodiment of the present application, which is mainly for processing messages when a certain node in the message broker service cluster fails and goes down, and may specifically include follow the steps below:
- Step 701 after the primary proxy server of a node receives the message sent by the producer, it synchronizes the message with at least one secondary proxy server belonging to the same copy group as the primary proxy server;
- each node of the message proxy service cluster includes a primary proxy server and at least one secondary proxy server that do not belong to the same copy group, that is, between the secondary proxy servers under the same node, and the secondary proxy server
- the messages synchronized between the server and the main proxy server are different.
- the main proxy server in the message proxy service node can communicate with the secondary proxy server of at least one other node after receiving the message sent by the producer.
- Message synchronization is carried out so that each node has the full amount of messages of the message broker service cluster to ensure the message consistency of each node.
- the message consistency may refer to that the message consistency of each copy in the copy group can be achieved through an agreed mechanism in the copy group.
- message synchronization can be performed with at least one secondary proxy server that the primary proxy server belongs to the same replica group, wherein, the primary proxy server belonging to the same replica group
- Each sub-proxy server and the primary proxy server of the group are located on different nodes.
- message consistency configuration for message synchronization can be implemented based on the number of proxy servers configured to synchronize messages, including strong consistency configuration, weak consistency configuration, and automatic downgrade mode. Specifically, availability and consistency can be adjusted according to actual service scenarios. Adjust this configuration after making trade-offs. It should be noted that the configuration can be changed at any time and takes effect in real time, and the timing of configuration is not limited.
- Step 702 the secondary proxy server of another node sends a message to the consumer when the primary proxy server fails.
- a message can be sent to the consumer based on the working status of the node.
- a message can be sent to the consumer through the sub-proxy server of another node to complete the message transmission between the producer and the consumer.
- the secondary proxy server that sends messages to the consumer may be a secondary proxy server that belongs to the same copy group as the primary proxy server.
- the primary proxy server of the node can also be reverse-synchronized, that is, the secondary proxy server belonging to the same replica group on another node It can have the function of reverse synchronization of metadata, that is, reverse synchronization of metadata, where the synchronized metadata can refer to various stateful data used to record consumption and sending status of messages in the server, such as consumption location, consumption progress, timing message playback location, etc., to ensure the message consistency of each node.
- the message consistency may refer to that the message consistency of each copy in the copy group can be achieved through an agreed mechanism in the copy group.
- the sub-proxy server of another node may perform reverse synchronization of metadata with the primary proxy server after the failure of the primary proxy server is repaired.
- FIG. 9 it shows a schematic diagram of the metadata reverse synchronization process in the embodiment of the present application.
- the metadata direction synchronization of each copy group is also realized through the metadata reverse synchronization flow between each node.
- the metadata reverse synchronization chain The road generally occurs when a node goes down and comes back online for data synchronization. As an example, assuming node 1 fails and goes down, the consumer can switch to Broker_a Slave in node 2 for consumption.
- the metadata generated by consumption can be reversely synchronized to Broker_a in node 1 Master, so that when the consumption traffic is switched back to Broker_a Master, it can be consumed according to the current consumption progress, that is, when consumers consume Broker_a Master in the re-online node 1, it can prevent the re-online Broker_a Master from following the original failure Consume according to the recorded consumption progress to avoid repeated consumption.
- metadata reverse synchronization can be achieved by packaging metadata into messages.
- Broker_a Slave in Node 2 performs metadata reverse synchronization process for Broker_a Master in Node 1 after the fault recovery can be as follows:
- Broker_a Slave in node 2 can package metadata into a message and write it to Broker_b Master; (2) Then Broker_b Master in node 2 can synchronize the message to node 1 through the message synchronization link in a above and the Broker_b Slave of node 3; (3) Broker_a Master in node 1 and Broker_a Slave in node 3 can respectively read the message from the Broker_b Slave of their respective nodes and parse out the metadata to be synchronized, update it locally, and complete Reverse synchronization of metadata.
- the reverse synchronization of metadata can be done by packaging the metadata into a message and writing it to the Broker_b Master of the same node.
- the way to determine the metadata that needs to be synchronized can be realized through the Topic of the message.
- the metadata that requires reverse synchronization that is, the message packaged into the metadata can have a special Topic, and the message can be synchronized to the Broker_b Slave of node 1 and the Broker_b Slave of node 3 through the data synchronization link.
- Broker_a Master and Broker_a Slave will monitor the number of messages of this special topic on other Brokers on the same node. When the number of messages changes, they can consume new messages and parse them into metadata, and then update them to their own messages to realize metadata reverse synchronization.
- each node includes a primary proxy server and at least one secondary proxy server
- single-point multi-Broker is realized
- the utilization rate of nodes in the message proxy service cluster is improved, and the number of nodes is reduced. Waste of resources; and because each node includes a master proxy server, it can ensure that the capabilities of each node are equal, and through the message synchronization of the master and sub-proxy servers between different nodes, the premise of ensuring the consistency of each node's messages Under this condition, it is possible to realize the non-election master process when the node message is transmitted, especially when the node fails.
- the message system may adopt a distributed system.
- a distributed message system there may be multiple servers that produce messages and consume messages.
- Multiple servers may form a server cluster, that is, producers may refer to production
- a consumer cluster may refer to a consumer cluster.
- the message system may include a producer cluster 1001 (Producer cluster), a message broker service cluster 1002 (Broker cluster), a domain name server cluster 1003 (Name Server cluster) ) and consumer cluster 1004 (Consumer cluster), wherein each message broker service cluster may include a plurality of nodes, each node includes a copy of each copy group, and includes a master proxy server belonging to a different copy group and at least A proxy server.
- the Producer cluster 1001 can be used to produce and send messages, which mainly sends data to consumers through Topic;
- the Broker cluster 1002, as a proxy server in the messaging system, can provide external messages
- the sending interface and consumption interface that is, as the intermediary between the Producer cluster and the Consumer cluster;
- the Name Server cluster 1003 is mainly used for the management of source data, including the management of Topic and routing information, which can be used to provide Topic-Broker Relational data, and each message proxy server Broker needs to register with the Name Server when it starts, and the Producer cluster 1001 can obtain the routing information of the corresponding message proxy server Broker from the Name Server 1003 according to the topic corresponding to the message before sending the message, and the Consumer cluster 1004 It is also possible to regularly obtain the routing information of the Topic, so as to realize the message forwarding of the message proxy server Broker through the relational data of the Topic-Broker; the Consumer cluster 1004 is used to obtain the messages produced by the Producer cluster, which can be realized by subscribing to the Topic.
- the message processing process of the message system can receive the message sent by the producer cluster through the node of the message proxy server Broker.
- the messages synchronized between each secondary proxy server and the primary proxy server in the same node are different, that is, each secondary proxy Different from the messages synchronized between the main proxy servers and each sub-proxy server, at this time the node can respond to the message consumption request sent by the consumer cluster, and send the target message to the consumer cluster through the target proxy server of the message proxy service node.
- the primary proxy server of a node after the primary proxy server of a node receives the message sent by the producer cluster, it can synchronize the message with the secondary proxy server of at least one other node; the primary proxy server sends a message to the consumer cluster, or another node The secondary server sends messages to the consumer cluster.
- each node includes a primary proxy server and at least one secondary proxy server
- single-point multi-Broker is realized
- the utilization rate of nodes in the message proxy service cluster is improved, and the number of nodes is reduced. Waste of resources; and because each node includes a master proxy server, it can ensure that the capabilities of each node are equal, and through the message synchronization of the master and sub-proxy servers between different nodes, the premise of ensuring the consistency of each node's messages Under this condition, it is possible to realize the non-election master process when the node message is transmitted, especially when the node fails.
- the message system includes a producer, a message broker service cluster, and a consumer.
- the message broker service cluster includes multiple nodes, and each node includes each A copy of the copy group, and includes a master proxy server and at least one secondary proxy server belonging to different copy groups, specifically may include the following modules:
- the message synchronization module 1101 is located at the main proxy server of a node, and is used to perform message synchronization with the secondary proxy server of at least one other node after receiving the message sent by the producer;
- the first message sending module 1102, located in the main proxy server, is used to send messages to consumers;
- the second message sending module 1103 is located at the secondary server of another node, and is used to send messages to consumers.
- the message synchronization module 1101 may include the following submodules:
- the message synchronization sub-module is used to synchronize messages with at least one sub-proxy server belonging to the same copy group as the main proxy server; wherein, the sub-proxy servers and the main proxy server belonging to the same copy group are located at different nodes.
- the message synchronization submodule may include the following units:
- the proxy server quantity configuration unit is used to configure the proxy server quantity for message synchronization with the main proxy server;
- the message synchronization unit is used to synchronize the messages sent by the producer to the proxy servers belonging to the same copy group according to the configured number of proxy servers.
- the device may also include the following modules:
- the metadata reverse synchronization module is located in the secondary proxy server of another node, and is used to synchronize the current metadata with the primary proxy server.
- the metadata reverse synchronization module may include the following submodules:
- the metadata reverse synchronization sub-module is used for synchronizing the current metadata with the primary proxy server after the failure of the primary proxy server is repaired through a secondary proxy server belonging to the same replica group as the primary proxy server.
- the second message sending module may include the following submodules:
- the message sending sub-module is located in the secondary proxy server of another node, and is used to send messages to consumers when the primary proxy server fails.
- the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment.
- the embodiment of the present application also provides an electronic device, including: a processor, a memory, and a computer program stored on the memory and capable of running on the processor.
- a processor a memory
- a computer program stored on the memory and capable of running on the processor.
- the embodiment of the present application also discloses a computer program.
- the computer program When the computer program is executed by a processor, the electronic device is made to execute the steps of any message communication method.
- the embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each process of the above message communication method embodiment is realized, and the same technical effect can be achieved , to avoid repetition, it will not be repeated here.
- embodiments of the embodiments of the present application may be provided as methods, devices, or computer program products. Therefore, the embodiment of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
- computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
- Embodiments of the present application are described with reference to flowcharts and/or block diagrams of methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor or processor of other programmable message processing terminal equipment to produce a machine such that the instructions executed by the computer or other programmable message processing terminal equipment processor Produce means for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.
- These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable message processing terminal to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the The instruction means implements the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Hardware Redundancy (AREA)
Abstract
本申请提供了一种消息通信方法和装置,方法包括:在一节点的主代理服务器接收到生产者发送的消息后,与另外至少一节点的副代理服务器进行消息同步;主代理服务器向消费者发送消息,或另外一个节点的副服务器向消费者发送消息。通过提出每个节点包括一主代理服务器以及至少一副代理服务器的新型消息队列高可用架构,实现单点多Broker,提高消息代理服务集群中节点的利用率,减少节点资源的浪费;且由于每个节点均包括一主代理服务器,能够保证每个节点的能力对等,以及通过不同节点间主、副代理服务器的消息同步,在保证每个节点消息一致性的前提下,能够实现节点消息传输时,特别是节点出现故障情况下的无选主过程。
Description
本申请要求于2021年07月09日提交中国专利局、申请号为202110781013.7、申请名称为“一种消息通信方法和装置”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
本申请涉及通信技术领域,特别是涉及一种消息通信方法和一种消息通信装置。
分布式***(Distributed System)是一种建立在网络之上的软件***,对于用户而言其可以相当于单个相关***,但实际上是若干独立计算机的集合,其中,用于组成***的独立计算机在地域上可以是分散的,且整个***的功能可以通过分散在各个节点上实现。
消息队列中间件(例如Rocket MQ(Rocket Message Queue,指的是一种开源的消息中间件)、ONS(Open Notification Service,开放消息服务,基于开源消息中间件Rocket MQ实现)、Kafka(是一种开源分布式高并发消息中间件)等)是分布式***中重要的组件,其主要用于解决分布式***之间消息传递的问题,消息代理是一种用于消息验证、变换、路由的架构模式,虽然不同的消息中间件架构和实现各不相同,但是大部分都实现了Broker,其为消息***中的代理服务器,可以具有与消息生产者和消息消费者进行消息收发的逻辑。目前所实现的中间件架构中,各个Broker均独占一个消息代理服务,在Broker正常运行时,备用代理服务器仅需从主代理服务器同步消息,其资源利用率在大部分时间都处于较低水平,从而导致一定程度的资源浪费。
发明内容
鉴于上述问题,提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种消息通信方法和相应的一种消息通信装置。
本申请实施例公开了一种消息通信方法,应用于消息***,消息***包括生产者、消息代理服务集群和消费者,消息代理服务集群包括多个节 点,每个节点包括每个副本组的一个副本,且包括属于不同副本组的一主代理服务器以及至少一副代理服务器,方法包括:
在一节点的主代理服务器接收到生产者发送的消息后,与另外至少一节点的副代理服务器进行消息同步;
主代理服务器向消费者发送消息,或另外一个节点的副服务器向消费者发送消息。
可选地,与另外至少一节点的副代理服务器进行消息同步,包括:
向与主代理服务器属于同一副本组的至少一个副代理服务器进行消息同步;其中,属于同一副本组的各个副代理服务器以及主代理服务器之间位于不同节点。
可选地,向与主代理服务器属于同一副本组的至少一个副代理服务器同步生产者发送的消息,包括:
配置与主代理服务器进行消息同步的代理服务器数量;
按照所配置的代理服务器数量,向属于同一副本组的代理服务器同步生产者发送的消息。
可选地,方法还包括:
另外一节点的副代理服务器向主代理服务器同步当前元数据。
可选地,另外一节点的副代理服务器向主代理服务器同步当前元数据,包括:
通过与主代理服务器属于同一副本组的一副代理服务器,在主代理服务器故障修复后,向主代理服务器同步当前元数据。
可选地,另外一个节点的副服务器向消费者发送消息,包括:
另外一节点的副代理服务器,在主代理服务器故障时,向消费者发送消息。
可选地,另外一节点的副代理服务器向消费者发送消息,包括:
通过与主代理服务器属于同一副本组的一副代理服务器,向消费者发送消息。
本申请实施例还公开了一种消息通信装置,应用于消息***,消息***包括生产者、消息代理服务集群和消费者,消息代理服务集群包括多个节点,每个节点包括每个副本组的一个副本,且包括属于不同副本组的一主代理服务器以及至少一副代理服务器,装置包括:
消息同步模块,位于一节点的主代理服务器,用于接收到生产者发送的消息后,与另外至少一节点的副代理服务器进行消息同步;
第一消息发送模块,位于主代理服务器,用于向消费者发送消息;
第二消息发送模块,位于另外一个节点的副服务器,用于向消费者发送消息。
可选地,消息同步模块包括:
消息同步子模块,用于向与主代理服务器属于同一副本组的至少一个副代理服务器进行消息同步;其中,属于同一副本组的各个副代理服务器以及主代理服务器之间位于不同节点。
可选地,消息同步子模块包括:
代理服务器数量配置单元,用于配置与主代理服务器进行消息同步的代理服务器数量;
消息同步单元,用于按照所配置的代理服务器数量,向属于同一副本组的代理服务器同步生产者发送的消息。
可选地,装置包括:
元数据反向同步模块,位于另外一节点的副代理服务器,用于向主代理服务器同步当前元数据。
可选地,元数据反向同步模块包括:
元数据反向同步子模块,用于通过与主代理服务器属于同一副本组的一副代理服务器,在主代理服务器故障修复后,向主代理服务器同步当前元数据。
可选地,第二消息发送模块包括:
消息发送子模块,位于另外一节点的副代理服务器,用于在主代理服务器故障时,向消费者发送消息。
本申请实施例还公开了一种电子设备,包括:处理器、存储器及存储在存储器上并能够在处理器上运行的计算机程序,计算机程序被处理器执行时实现任一项消息通信方法的步骤。
本申请实施例还公开了一种计算机可读存储介质,计算机可读存储介质上存储计算机程序,计算机程序被处理器执行时实现任一项消息通信方法的步骤。
本申请实施例还公开了一种计算机程序,计算机程序被处理器执行时,使得电子设备执行任一项消息通信方法的步骤。
本申请实施例包括以下优点:
在本申请实施例中,提出了应用于消息***的消息处理方法,主要通过消息代理服务集群的节点实现与生产者、消费者之间的消息传输,其中消息代理服务集群中的每个节点可以包括每个副本组的一个副本,且包括属于不同副本组的一主代理服务器以及至少一副代理服务器,在一节点的主代理服务器接收到生产者发送的消息后,可以与另外至少一节点的副代理服务器进行消息同步,其主代理服务器或另一个节点的副代理服务器可以向消费者发送消息。通过提出每个节点包括一主代理服务器以及至少一副代理服务器的新型消息队列高可用架构,实现单点多Broker,提高消息代理服务集群中节点的利用率,减少节点资源的浪费;且由于每个节点均包括一主代理服务器,能够保证每个节点的能力对等,以及通过不同节点 间主、副代理服务器的消息同步,在保证每个节点消息一致性的前提下,能够实现节点消息传输时,特别是节点出现故障情况下的无选主过程。
图1A至1C是相关技术中消息队列中间件的架构示意图;
图2是本申请实施例中消息队列中间件的架构示意图;
图3是本申请的一种消息通信方法实施例的步骤流程图;
图4是本申请的另一种消息通信方法实施例的步骤流程图;
图5是本申请实施例中数据同步的过程示意图;
图6是本申请实施例中一种消息通信方法的应用场景图;
图7是本申请的又一种消息通信方法实施例的步骤流程图;
图8是本申请实施例中另一种消息通信的应用场景图;
图9是本申请实施例中元数据反向同步的过程示意图;
图10是本申请实施例中消息通信***的框架示意图;
图11是本申请的一种消息通信装置实施例的结构框图。
为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。
为便于本领域技术人员进一步理解本申请提出的消息处理方法,下面对本申请下述各实施例中涉及到的术语或名词做出解释:
Topic:主题,是对一组消息的抽象分类,生产者可以通过Topic进行消息发布,且消费者可通过Topic进行消息订阅,实现消息的传输;
消息:可以指的是生产者向Topic发送并最终传送给消费者的消息和(可选)属性的组合;
Producer:消息的生产者和/或发送方,即发送消息方,其可以是单个服务器或服务器集群;
Consumer:消息的消费方,即请求消息方,其同样可以是单个服务器或服务器集群;
Broker:消息***中的代理服务器(即消息中间件服务器),其可以对外具有消息的发送和消费接口,消息的生产者和消费者能够与其交互完成核心消息的收发逻辑;
Master/Leader Broker:主代理服务器,承担在正常情况下对外提供服务的功能;
Slave/Follower Broker:副代理服务器,实际上为主代理服务器的副本,其可以拥有主代理服务器上的全量消息,能够在主代理服务器下线时实现 对外提供服务;
Commit Log:消息队列中间件的消息存储组件,用于保存消息队列中间件接收到的所有消息;
元数据:消息队列中间件中用于记录消费、发送状态的消息,如消费位点、定时消息重放位点等。
消息队列中间件(例如Rocket MQ、ONS、Kafka等)是分布式***中重要的组件,其主要用于解决分布式***之间消息传递的问题,参照图1A至1C,示出了相关技术中消息队列中间件的架构示意图,其主要是涉及到消息***中Broker集群(即消息代理服务集群)所采用的通信架构。其中,M用于表示主代理服务器Master Broker,S用于表示副代理服务器Slave Broker。
如图1A所示,Broker集群所采用的通信架构为主备架构,其仅支持一主一备,能够支持多种消息复制模式,实现消息同步,但所采取的是冷备(备不可读)的部署方式,即副代理服务器仅用于同步主代理服务器的消息,而不能对外提供读写服务;以及在Master Broker出现故障时需要手动进行主备切换,在大规模场景下有较大的资源浪费以及运维成本。
如图1B所示,Broker集群所采用的通信架构为基于ZK(Zoo Keeper,分布式协调内核)的主备架构,其可支持一主多备,但所采取的部署方式同样是冷备(备不可读)方式,即副代理服务器仅用于同步主代理服务器的消息,而不能对外提供读写服务;可以基于额外的Zoo Keeper集群进行协调服务,实现自动选主的功能,支持在Master Broker出现故障时,自动将Slave切换成Master提供服务,但故障转移时间较长,大概需要10秒左右完成选主。
如图1C所示,Broker集群所采用的通信架构为基于Raft协议(指的是分布式一致性协议)的Leader-Follower架构,其可支持一主多备,且能够基于Raft协议所提供的Follower(即副代理服务器Slave Broker)重定向到Leader(即主代理服务器Master Broker)实现自动选主,无需依赖额外的Zoo Keeper集群,但由于故障时仍需等待选主,整个故障转移时间较长,而强一致的Raft协议暂未支持动态降级策略,导致无法灵活权衡可用性和可靠性。
在以上三种消息队列中间件的架构,每个Broker都将独占消息代理服务集群中的一个节点,在副本组(指的是一组拥有相同消息的Broker,通常可由一主N备组成)处于正常工作状态时,Master Broker所在的节点承担所有的读写服务,而Slave Broker所在节点不具有读写服务,仅需从Master Broker同步消息,使得Slave Broker所在节点的资源利用率在大部分时间处于较低水平,导致一定程度的节点资源浪费。
本申请实施例的核心思想之一在于通过提出每个节点包括每个副本组 的一个副本,且包括属于不同副本组的一主代理服务器以及至少一副代理服务器的新型消息队列高可用架构,使得消息代理服务集群中的任意一节点都可以拥有该集群的全量数据,实现单点多Broker,提高消息代理服务集群中节点的利用率,减少节点资源的浪费;且由于每个节点均包括一主代理服务器,能够保证每个节点的能力对等(均具有读写服务),以及通过不同节点间主、副代理服务器的消息同步,在保证每个节点消息一致性的前提下,能够实现节点消息传输时,特别是节点出现故障情况下的无选主过程。
在本申请实施例中,为了提高消息代理服务器集群中节点的利用率,此时可以对消息代理服务集群所采用的消息队列中间件的通信架构进行处理,具体可以在消息代理服务集群的每个节点中同时配置主代理服务器和副代理服务器,例如每个节点可以包括一主代理服务器以及至少一副代理服务器,实现单点多Broker,减少节点的资源浪费。
具体的,参照图2,示出了本申请实施例中消息队列中间件的架构示意图,采用该消息队列中间件架构的消息代理服务集群可以包括多个节点,例如节点1、节点2与节点3,每个节点可以包括多个Broker,对于3主6备的消息代理服务集群而言,现有的高可用架构中每个Broker都将独占一个节点,则需要9个节点才能完成部署,其只需3个节点即可完成部署,减少对节点资源的损耗。
在实际应用中,每个节点可以通过Broker Container(为Broker管理进程)实现Broker的添加或删除,以及管理进程内所有Broker的网络请求分发与资源调度,所添加的Broker可以是可提供读写服务的主代理服务器Master Broker,和仅提供读服务的副代理服务器Slave Broker,在本申请实施例中,一个Broker Container对应管理一个节点,每个节点可以包括一主代理服务器以及至少一副代理服务器,且所包括的代理服务器均不属于同一副本组,即各个副代理服务器之间,以及各个副代理服务器与主代理服务器之间所同步的消息不同。
作为一种示例,节点1包括主Broker_a、备Broker_b以及Broker_c,节点2包括主Broker_b、备Broker_a以及Broker_c,而节点3包括主Broker_c、备Broker_a以及Broker_b。
其中,副本组可以指的是一组拥有相同消息的Broker,通常可由一主N备组成,在副本组正常工作时,可以由主代理服务器提供消息的读写服务,并可以向同一副本组内的其他副代理服务器同步消息,而在主代理服务器出现故障宕机时,可以由其余副代理服务器提供读服务。
在本申请实施例中,每个节点所包括的代理服务器均不属于同一副本组,即位于位于同一节点下的各个副代理服务器之间,以及副代理服务器与主代理服务器之间所同步的消息不同,那么在每个副本组(例如一主 Broker_a二备Broker_a、一主Broker_b二备Broker_b,以及一主Broker_c二备Broker_c)正常工作时,每个节点都拥有每个副本组中的一个副本,表示任意一节点均拥有该消息代理服务集群的全量消息,在此架构下,只要保证该消息代理服务集群其中一节点(例如节点1或节点2或节点3)处于正常工作状态,即可保证无消息丢失。
另外,每个节点都包含有一个主代理服务器Master Broker,即均可提供读写服务,保证每个节点的能力对等。
在实际应用中,该架构可以应用于消息中间件秒级RTO(Recovery Time Objective,复原时间目标)架构的核心底座。其中,RTO反映的是数据中心服务恢复的及时性指标,其可以用于表示服务从中断到恢复正常所需的时间,RTO数值越小,代表容灾***的数据恢复能力越强。
需要说明的是,消息代理服务集群中的节点可以指的是一个拥有独立计算、内存、存储、网络等资源的环境,其可以为物理机、虚拟机或容器,实现生产者与消费者之间的消息传输;且同一节点内的所有Broker处于同一进程,即Broker Container进程,该进程负责管理Broker并作为所有Broker的共享网络层(所有发往Broker,或从Broker发出的RPC(Remote Procedure Call,是一种远程过程调用,HTTP请求本身也可以看作是RPC的一种具体形式)请求均需要通过Broker Container的网络层进行处理。
参照图3,示出了本申请的一种消息通信方法实施例的步骤流程图,应用于消息***,消息***包括生产者、消息代理服务集群和消费者,消息代理服务集群包括多个节点,具体可以包括如下步骤:
步骤301,在一节点的主代理服务器接收到生产者发送的消息后,与另外至少一节点的副代理服务器进行消息同步;
在本申请实施例中,消息代理服务集群可以实现生产者与消费者之间的消息传输,具体可以通过消息代理服务集群中所包含的节点接收生产者所发送的消息,以及响应消费者所发送的消息消费请求向消费者发送消息实现。
在实现生产者与消费者之间的消息传输的过程中,首先需要对消息进行同步,以实现在分布式消息***中的消息传输,避免由于故障导致的消息传输失败,为消息***提供故障转移能力。
在本申请的一种实施例中,在进行消息同步的过程中,需要通过主代理服务器向同一副本组内的其他副代理服务器同步消息,而消息代理服务集群的每个节点所包括一主代理服务器以及至少一副代理服务器均不属于同一副本组,即位于同一节点下的各个副代理服务器之间,以及副代理服务器与主代理服务器之间所同步的消息不同,此时消息代理服务节点中的主代理服务器在接收到生产者发送的消息之后,可以与另外至少一节点的副代理服务器进行消息同步,保证每个节点都包含每个副本组的一个副本, 使得每个节点均具有此消息代理服务集群的全量消息,保证每个节点的消息一致性。
作为一种示例,对于3主6备的消息代理服务集群而言,节点1的主Broker_a可以与节点2中的备Broker_a以及节点3中的备Broker_a进行消息同步,节点2的主Broker_b可以与节点1中的备Broker_b以及节点3中的备Broker_b进行消息同步,以及节点3的主Broker_c可以与节点1中的备Broker_c以及节点3中的备Broker_c进行消息同步。
步骤302,主代理服务器向消费者发送消息,或另外一个节点的副服务器向消费者发送消息。
在通过消息代理服务集群的每个节点对消息进行同步后,可以通过消息代理服务集群的节点向消费者发送消息,实现生产者与消费者之间的消息传输。
具体的,消息代理服务集群中的每个节点可以包括一主代理服务器以及至少一副代理服务器,在进行消息发送的过程中,可以基于节点的工作状态,通过某个节点的主代理服务器向消费者发送消息,或另外一个节点的副服务器向消费者发送消息。
在一种情况下,当某个节点的工作状态处于正常工作状态时,可以直接通过某个节点的主代理服务器向消费者发送消息;在另一种情况下,当某个节点出现故障处于宕机状态时,可以采用另外一个节点的副服务器向消费者发送消息,其中,另外一个节点的副服务器与某个节点的主代理服务器属于同一副本组,即可实现消息的无选主传输过程。
在本申请实施例中,提出了应用于消息***的消息处理方法,主要通过消息代理服务集群的节点实现与生产者、消费者之间的消息传输,其中消息代理服务集群中的每个节点可以包括每个副本组的一个副本,且包括属于不同副本组的一主代理服务器以及至少一副代理服务器,在一节点的主代理服务器接收到生产者发送的消息后,可以与另外至少一节点的副代理服务器进行消息同步,其主代理服务器或另一个节点的副代理服务器可以向消费者发送消息。通过提出每个节点包括属于不同副本组的一主代理服务器以及至少一副代理服务器的新型消息队列高可用架构,实现单点多Broker,提高消息代理服务集群中节点的利用率,减少节点资源的浪费;且由于每个节点均包括一主代理服务器,能够保证每个节点的能力对等,以及通过不同节点间主、副代理服务器的消息同步,在保证每个节点消息一致性的前提下,能够实现节点消息传输时,特别是节点出现故障情况下的无选主过程。
参照图4,示出了本申请的另一种消息通信方法实施例的步骤流程图,其主要为消息代理服务集群中的每个节点均处于正常工作状态下对消息进行处理的情况,具体可以包括如下步骤:
步骤401,在一节点的主代理服务器接收到生产者发送的消息后,向与主代理服务器属于同一副本组的至少一个副代理服务器进行消息同步;
在本申请实施例中,消息代理服务集群的每个节点所包括一主代理服务器以及至少一副代理服务器均不属于同一副本组,即位于同一节点下的各个副代理服务器之间,以及副代理服务器与主代理服务器之间所同步的消息不同,在进行消息同步的过程中,消息代理服务节点中的主代理服务器在接收到生产者发送的消息之后,可以与另外至少一节点的副代理服务器进行消息同步,使得每个节点均具有此消息代理服务集群的全量消息,保证每个节点的消息一致性。
其中,消息一致性可以指的是副本组内可通过约定的机制实现副本组内各副本的消息一致。具体的,在一节点的主代理服务器与另外至少一节点的副代理服务器进行消息同步的过程中,可以向主代理服务器属于同一副本组的至少一个副代理服务器进行消息同步,其中,属于同一副本组(即同一副本组)的各个副代理服务器以及主代理服务器之间位于不同节点。
在本申请实施例中,属于同一副本组内的代理器间所进行的消息同步可以指的是数据同步,该数据可以包括Commit Log、topic、订阅关系、元数据等。参照图5,示出了本申请实施例中数据同步的过程示意图,各个副本组的消息同步可以通过各个节点之间的数据同步流实现。作为一种示例,当Broker_a的主代理服务器Master Broker在向副代理服务器Slave Broker进行实时数据同步时,可以通过位于节点1的主Broker_a通过数据同步流向位于节点2和节点3中的备Broker_a实时同步数据。
其中,在大多数情况下,副本组依赖此链路实现副本组内的消息一致性。
在一种优选的实施例中,副本组同时可以支持通过更改配置,来决定一致性的保证强度,以支持动态降级策略,能够在可用性和一致性中进行权衡,其中,实现消息一致性强度的配置,可以基于配置同步消息的代理服务器数量实现。
具体的,可以配置与主代理服务器进行消息同步的代理服务器数量,然后按照所配置的代理服务器数量,向属于同一副本组的代理服务器同步生产者发送的消息,基于所配置的代理服务器数量实现消息的强一致性和/或弱一致性同步。其中,一致性配置可以指的是当生产者将一条消息发送到某个主代理服务器时,需要确保同步至多少个Broker方可认为该消息发送成功,即强一致性配置与弱一致性配置可以表现在生产者接收到的消息发送成功响应时的条件。
进行消息一致性强度的配置,在第一种情况下,当配置为强一致性配置时,表示此时在消息代理服务集群中的每个副本组不允许出现消息不一致的情况,即生产者在向某个主代理服务器发送消息时,主代理服务器需 要向其副本组内的所有副代理服务器进行消息同步,在确保消息被同步至副本组内的所有副代理服务器后才会向生产者中的发送端返回发送成功的响应,表示此消息已发送成功;若主代理服务器的副本组内有部分副代理服务器同步消息失败或不存在消息同步成功的副代理服务器,表示此消息发送失败,此时发送端将会自动进行重试发送,直至发送端接收到发送成功的响应或发送端达到重试发送次数阈值为止。
然而在这种强一致性配置的模式下,任意一条消息都会同时保存在副本组内所有的消息代理服务器上,可以实现很强的消息一致性,但在任一代理服务器出现故障时,将出现发送不可用的现象,例如当某个节点发生抖动导致同步失败时,此次发送请求将直接失败,降低了可用性。
作为一种示例,对于3主6备的消息代理服务集群而言,每个副本组包括1主2备,假设当前配置需要同步消息的代理服务器数量为3,即副本组内的1主2被均需要进行消息同步,当前处于强一致性配置的情况,例如每一条被发送至节点1中Broker_a Master的消息,都需要等待该消息同步至节点2和节点3中的两个Slave broker后,才被视为该消息发送成功。
在第二种情况下,当配置为弱一致性配置时,表示此时在消息代理服务集群中的每个副本组允许出现消息不一致的情况,即生产者在向某个主代理服务器发送消息时,主代理服务器可以向其副本组内的部分副代理服务器进行消息同步,在确保该消息被同步至配置的部分副代理服务器后,可以向生产者中的发送端返回发送成功的响应,表示此消息已发送成功。
在这种情况下,每条发送至Broker_a Master的消息,可以只需同步至一个副代理服务器,甚至0个副代理服务器即可视为发送成功,然而在这种弱一致性配置的模式下,若某个节点发生宕机,则可能导致消息丢失,不能保证副本组内消息的强一致性,但在这种弱一致性配置的模式下,即使有个别节点发生抖动导致同步失败,也可认为发送成功,具有更高的可用性。
需要说明的是,使用弱一致性配置,并不是表示只有部分副代理服务器才会收到消息同步,而指的是主代理服务器在向发送端返回发送成功的响应前仅需等待部分副代理服务器同步成功即可,此时在其副本组内剩余的其他副代理服务器的消息同步还在异步进行中。
作为一种示例,对于3主6备的消息代理服务集群而言,每个副本组包括1主2备,假设当前配置需要同步消息的代理服务器数量为3,假设当前配置需要同步消息的代理服务器数量为1,即副本组内的1主需要进行消息同步,则只要Master收到消息后就可以立刻返回发送成功的响应,无需等待消息同步完成,这种配置可用性很高(即使2个Slave均发生故障也不影响消息发送),但消息的一致性较低(发送端收到成功的响应只 能确保Master收到了消息,而无法确认消息被同步到了其他的Slave,或者说,假设发生了同步失败,就可能导致某条消息只存在于Master,而不存在于某个Slave,也即发生了消息不一致)。
需要说明的是,上述的配置可随时更改,实时生效,并不限定一致性配置的时机,且可以根据实际服务场景对可用性和一致性进行权衡后调整该配置。
在一种可选的实施例中,消息强一致性的配置能够保证副本组内消息的强一致性,但可用性弱,而消息弱一致性的配置虽然不能保证副本组内消息的强一致性,但其可用性很高,那么除了上述消息强一致性模式和消息弱一致性模式的配置,此时还可以配置自动降级模式,进一步支持动态降级策略,能够灵活权衡可用性和可靠性。
所配置的自动降级模式可以指的是主代理服务器可以根据当前副本组的同步状态,以及一个可配置的同步数量阈值来计算出某条消息需要同步至多少个Broker才视为发送成功。
在实际应用中,当副本组同步状态良好时,在使用强一致性同步模式,即消息需要同步至所有Slave才视为发送成功,然而在副本组发生抖动或宕机导致同步失败时,可以自动降级至弱一致性模式,使得消息在同步至部分Slave即可视为发送成功,即开启自动降级策略可以接受当某些Broker发生抖动时,牺牲一致性来换取可用性,而同步数量阈值则用于规定可接受的一致性的损失下限,能够尽量在消息强一致性的基础上保证可用性。
需要说明的是,自动降级配置也是随时更改,实时生效,并不限定自动降级配置的时机。
作为一种示例,对于3主6备的消息代理服务集群而言,每个副本组包括1主2备,假设当前所配置的模式为强一致性配置,即副本组内的1主2被均需要进行消息同步的情况,在开启自动降级模式之后,假设同步数量阈值配置为2,则根据当前副本组的同步状态,所计算出的最终需同步Broker数量可为3(两Slave与Master均处于实时同步状态),也可以为2(当某一Slave同步进度落后于Master过多),但不可为1(为1时一般是两个Slave同步进度均落后Master过多,但因为配置了同步数量阈值为2,所以这种情况下,发送消息将直接返回失败)。
步骤402,通过主代理服务器向消费者发送消息。
在通过消息代理服务集群的每个节点对消息进行同步后,可以基于节点的工作状态向消费者发送消息,在消息代理服务集群中的每个节点均处于正常工作状态下,可以通过主代理服务器向消费者发送消息,完成生产者与消费者之间的消息传输。
具体的,如图6所示,在消息代理服务集群中的每个节点均处于正常工作状态下,可以通过节点接收生产者发送的消息,并响应消费者所发送 的消息消费请求,通过节点的主代理服务器向消费者发送消息,即生产者只向每个副本组的Master发送消息,且消费者只从每个副本组的Master消费消息。
在实际应用中,同一节点内的不同Broker可通过不同的端口号进行区分,即同一节点内的不同broker可监听不同的端口号,通过结合节点IP和端口号即可决定请求发向哪一个Broker,具体的可以在发送请求时指定地址IP:Port即可决定将请求发向哪一个broker。
在具体实现中,消息代理服务集群所接收到的消息消费请求可以包括节点通信地址和代理服务端口号,此时可以根据节点通信地址确定目标节点,再根据代理服务端口号从目标节点中确定目标代理服务器,以使目标代理服务器向消费者发送目标消息。
在本申请实施例中,通过提出每个节点包括一主代理服务器以及至少一副代理服务器的新型消息队列高可用架构,实现单点多Broker,提高消息代理服务集群中节点的利用率,减少节点资源的浪费;且由于每个节点均包括属于不同副本组的一主代理服务器,能够保证每个节点的能力对等,以及通过不同节点间主、副代理服务器的消息同步,在保证每个节点消息一致性的前提下,能够实现节点消息传输时,特别是节点出现故障情况下的无选主过程。
参照图7,示出了本申请的又一种消息通信方法实施例的步骤流程图,其主要为消息代理服务集群中的某个节点出现故障宕机时对消息进行处理的情况,具体可以包括如下步骤:
步骤701,在一节点的主代理服务器接收到生产者发送的消息后,向与主代理服务器属于同一副本组的至少一个副代理服务器进行消息同步;
在本申请实施例中,消息代理服务集群的每个节点所包括一主代理服务器以及至少一副代理服务器均不属于同一副本组,即位于同一节点下的各个副代理服务器之间,以及副代理服务器与主代理服务器之间所同步的消息不同,在进行消息同步的过程中,消息代理服务节点中的主代理服务器在接收到生产者发送的消息之后,可以与另外至少一节点的副代理服务器进行消息同步,使得每个节点均具有此消息代理服务集群的全量消息,保证每个节点的消息一致性。
其中,消息一致性可以指的是副本组内可通过约定的机制实现副本组内各副本的消息一致。具体的,在一节点的主代理服务器与另外至少一节点的副代理服务器进行消息同步的过程中,可以向主代理服务器属于同一副本组的至少一个副代理服务器进行消息同步,其中,属于同一副本组(即同一副本组)的各个副代理服务器以及主代理服务器之间位于不同节点。
在实际应用中,消息同步的消息一致性配置可以基于配置同步消息的代理服务器数量实现,包括强一致性配置、弱一致性配置以及开启自动降 级模式,具体可以根据实际服务场景对可用性和一致性进行权衡后调整该配置。需要说明的是,配置可随时更改,实时生效,并不限定配置的时机。
步骤702,另外一节点的副代理服务器,在主代理服务器故障时,向消费者发送消息。
在通过消息代理服务集群的每个节点对消息进行同步后,可以基于节点的工作状态向消费者发送消息,在消息代理服务集群中的某个节点的主代理服务器处于故障宕机的情况下,可以通过另外一节点的副代理服务器向消费者发送消息,完成生产者与消费者之间的消息传输。
具体的,向消费者发送消息的副代理服务器可以是与主代理服务器属于同一副本组的一副代理服务器。
具体的,如图8所示,假设节点1宕机,Producer停止向Broker_a Master发送消息,此时Consumer自动切换原来发送至Broker_a Master的消费请求至节点2上的Broker_a Slave,由于Broker_a Slave拥有Broker_a Master的全量消息,故在节点1宕机的情况下,依然保证了服务的可用性,且该过程无需进行选主。
在一种优选的实施例中,在出现故障宕机的某个节点被修复后,还可以对该节点的主代理服务器进行反向同步,即在另一节点上属于同一副本组的副代理服务器可以具有元数据反向同步的功能,即对元数据进行反向同步,其中,所同步的元数据可以指的消息在服务器中的各种用于记录消费、发送状态的状态性数据,比如消费位点、消费进度、定时消息重放位点等,保证每个节点的消息一致性。
其中,消息一致性可以指的是副本组内可通过约定的机制实现副本组内各副本的消息一致。具体的,另外一节点的副代理服务器,可以在主代理服务器故障修复后,向主代理服务器进行元数据反向同步。
参照图9,示出了本申请实施例中元数据反向同步的过程示意图,各个副本组的元数据方向同步同样通过各个节点之间的元数据反向同步流实现,元数据反向同步链路一般出现于某一节点宕机后重新上线的数据同步。作为一种示例,假设节点1出现故障宕机,消费端可以切换至节点2中的Broker_a Slave消费,此时消费所产生的元数据,如消费进度等,可以反向同步至节点1中的Broker_a Master,使得当消费流量回切至Broker_a Master时可按照当前消费进度进行消费,即能够使得消费者在对重新上线的节点1中的Broker_a Master进行消费时,防止重新上线的Broker_a Master按照原来故障前所记录的消费进度进行消费,避免重复消费。
在具体实现中,在新的消息队列中间件的架构中,并无存在备代理服务器Slave Broker直接向主代理服务器Master Broker发送消息的链路,架构中所实现的反向元数据同步链路可以如图9所示。
其中,元数据反向同步可以通过将元数据包装成消息的形式反向同步 实现。
假设节点1出现故障宕机,消费端可以切换至节点2中的Broker_a Slave消费,此时节点2中的Broker_a Slave对故障恢复后的节点1中Broker_a Master进行元数据反向同步的过程可以如下:
(1)首先节点2中的Broker_a Slave可以将元数据包装成一条消息写入Broker_b Master;(2)然后节点2中的Broker_b Master通过上述a中的消息同步链路可以将该消息同步至节点1和节点3的Broker_b Slave;(3)节点1中的Broker_a Master和节点3中的Broker_a Slave可以分别从各自节点的Broker_b Slave将该消息读出并解析出需同步的元数据,更新至本地,完成元数据的反向同步。
在实际应用中,元数据的反向同步可以通过把元数据包装成一条消息写入同节点的Broker_b Master来完成,对于Broker_b Master而言,判定此时存在需要反向同步的元数据的方式以及确定所需同步的元数据的方式可以通过消息的Topic实现。
具体的,所需反向同步的元数据,即对元数据包装成的消息可以具有一个特殊的Topic,该消息可以通过数据同步链路同步至节点1的Broker_b Slave和节点3的Broker_b Slave中,而Broker_a Master和Broker_a Slave将会监听这个特殊Topic在同节点其他Broker的消息数量,当消息数量发生变化时,可以将新消息消费出来并解析成元数据,然后更新到自身消息中,实现元数据的反向同步。
在本申请实施例中,通过提出每个节点包括一主代理服务器以及至少一副代理服务器的新型消息队列高可用架构,实现单点多Broker,提高消息代理服务集群中节点的利用率,减少节点资源的浪费;且由于每个节点均包括一主代理服务器,能够保证每个节点的能力对等,以及通过不同节点间主、副代理服务器的消息同步,在保证每个节点消息一致性的前提下,能够实现节点消息传输时,特别是节点出现故障情况下的无选主过程。
在本申请实施例中,消息***可以采用分布式***,在分布式消息***中,可以存在多个生产消息以及消费消息的服务器,多个服务器可以构成服务器集群,即生产者可以指的是生产者集群,消费者可以指的是消费者集群。
参照图10,示出了本申请实施例中消息通信***的框架示意图,消息***可以包括生产者集群1001(Producer集群)、消息代理服务集群1002(Broker集群)、域名服务器集群1003(Name Server集群)和消费者集群1004(Consumer集群),其中,每个消息代理服务集群可以包括多个节点,每个节点包括每个副本组的一个副本,且包括属于不同副本组的一主代理服务器以及至少一副代理服务器。
在该消息***中,Producer集群1001可以用于生产消息和发送消息, 其主要是通过Topic向消费者发送最终传送给消费者的数据;Broker集群1002作为消息***中的代理服务器,能够对外提供消息的发送接口和消费接口,即作为Producer集群和Consumer集群的中间媒介;Name Server集群1003主要是用于对源数据的管理,包括对Topic和路由信息的管理,其可以用于提供Topic-Broker的关系数据,且每个消息代理服务器Broker在启动时需要在Name Server进行注册,Producer集群1001在发送消息前可以根据消息所对应的Topic到Name Server1003获取相应消息代理服务器Broker的路由信息,Consumer集群1004同样也能够定时获取Topic的路由信息,以便通过Topic-Broker的关系数据,实现消息代理服务器Broker的消息转发;Consumer集群1004用于获取Producer集群生产的消息,具体可以通过订阅Topic实现。
具体的,消息***的消息处理过程,可以通过消息代理服务器Broker的节点接收生产者集群发送的消息,同一节点内的各个副代理服务器以及主代理服务器之间同步的消息不同,即各个副代理服务与主代理服务器之间,以及各个副代理服务器之间同步的消息不同,此时节点可以响应消费者集群发送的消息消费请求,通过消息代理服务节点的目标代理服务器向消费者集群发送目标消息。
在实际应用中,在一节点的主代理服务器接收到生产者集群发送的消息后,可以与另外至少一节点的副代理服务器进行消息同步;主代理服务器向消费者集群发送消息,或另外一个节点的副服务器向消费者集群发送消息。
在本申请实施例中,通过提出每个节点包括一主代理服务器以及至少一副代理服务器的新型消息队列高可用架构,实现单点多Broker,提高消息代理服务集群中节点的利用率,减少节点资源的浪费;且由于每个节点均包括一主代理服务器,能够保证每个节点的能力对等,以及通过不同节点间主、副代理服务器的消息同步,在保证每个节点消息一致性的前提下,能够实现节点消息传输时,特别是节点出现故障情况下的无选主过程。
需要说明的是,对于方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请实施例并不受所描述的动作顺序的限制,因为依据本申请实施例,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作并不一定是本申请实施例所必须的。
参照图11,示出了本申请的一种消息通信装置实施例的结构框图,消息***包括生产者、消息代理服务集群和消费者,消息代理服务集群包括多个节点,每个节点包括每个副本组的一个副本,且包括属于不同副本组的一主代理服务器以及至少一副代理服务器,具体可以包括如下模块:
消息同步模块1101,位于一节点的主代理服务器,用于接收到生产者发送的消息后,与另外至少一节点的副代理服务器进行消息同步;
第一消息发送模块1102,位于主代理服务器,用于向消费者发送消息;
第二消息发送模块1103,位于另外一个节点的副服务器,用于向消费者发送消息。
在本申请的一种实施例中,消息同步模块1101可以包括如下子模块:
消息同步子模块,用于向与主代理服务器属于同一副本组的至少一个副代理服务器进行消息同步;其中,属于同一副本组的各个副代理服务器以及主代理服务器之间位于不同节点。
在本申请的一种实施例中,消息同步子模块可以包括如下单元:
代理服务器数量配置单元,用于配置与主代理服务器进行消息同步的代理服务器数量;
消息同步单元,用于按照所配置的代理服务器数量,向属于同一副本组的代理服务器同步生产者发送的消息。
在本申请的一种实施例中,装置还可以包括如下模块:
元数据反向同步模块,位于另外一节点的副代理服务器,用于向主代理服务器同步当前元数据。
在本申请的一种实施例中,元数据反向同步模块可以包括如下子模块:
元数据反向同步子模块,用于通过与主代理服务器属于同一副本组的一副代理服务器,在主代理服务器故障修复后,向主代理服务器同步当前元数据。
在本申请的一种实施例中,第二消息发送模块可以包括如下子模块:
消息发送子模块,位于另外一节点的副代理服务器,用于在主代理服务器故障时,向消费者发送消息。
对于装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本申请实施例还提供了一种电子设备,包括:处理器、存储器及存储在存储器上并能够在处理器上运行的计算机程序,该计算机程序被处理器执行时实现上述消息通信方法实施例的各个过程,且能达到相同的技术效果,为避免重复,这里不再赘述。
本申请实施例还公开了一种计算机程序,计算机程序被处理器执行时,使得电子设备执行任一项消息通信方法的步骤。
本申请实施例还提供了一种计算机可读存储介质,计算机可读存储介质上存储计算机程序,计算机程序被处理器执行时实现上述消息通信方法实施例的各个过程,且能达到相同的技术效果,为避免重复,这里不再赘述。
说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明 的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白,本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此,本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请实施例是参照根据本申请实施例的方法、终端设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程消息处理终端设备的处理器以产生一个机器,使得通过计算机或其他可编程消息处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程消息处理终端设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程消息处理终端设备上,使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括要素的过程、方法、物品 或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种消息通信方法和一种消息通信装置,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上,本说明书内容不应理解为对本申请的限制。
Claims (11)
- 一种消息通信方法,其特征在于,应用于消息***,所述消息***包括生产者、消息代理服务集群和消费者,所述消息代理服务集群包括多个节点,每个节点包括每个副本组的一个副本,且包括属于不同副本组的一主代理服务器以及至少一副代理服务器,所述方法包括:在一节点的主代理服务器接收到生产者发送的消息后,与另外至少一节点的副代理服务器进行消息同步;所述主代理服务器向消费者发送消息,或另外一个节点的副服务器向消费者发送消息。
- 根据权利要求1所述的方法,其特征在于,所述与另外至少一节点的副代理服务器进行消息同步,包括:向与所述主代理服务器属于同一副本组的至少一个副代理服务器进行消息同步;其中,属于同一副本组的各个副代理服务器以及主代理服务器之间位于不同节点。
- 根据权利要求2所述的方法,其特征在于,所述向与所述主代理服务器属于同一副本组的至少一个副代理服务器同步所述生产者发送的消息,包括:配置与所述主代理服务器进行消息同步的代理服务器数量;按照所配置的代理服务器数量,向属于同一副本组的代理服务器同步所述生产者发送的消息。
- 根据权利要求1所述的方法,其特征在于,所述方法还包括:另外一节点的副代理服务器向所述主代理服务器同步当前元数据。
- 根据权利要求4所述的方法,其特征在于,所述另外一节点的副代理服务器向所述主代理服务器同步当前元数据,包括:通过与所述主代理服务器属于同一副本组的一副代理服务器,在所述主代理服务器故障修复后,向所述主代理服务器同步当前元数据。
- 根据权利要求1所述的方法,其特征在于,所述另外一个节点的副服务器向消费者发送消息,包括:另外一节点的副代理服务器,在所述主代理服务器故障时,向消费者发送消息。
- 根据权利要求6所述的方法,其特征在于,所述另外一节点的副代理服务器向消费者发送消息,包括:通过与所述主代理服务器属于同一副本组的一副代理服务器,向所述消费者发送消息。
- 一种消息通信装置,其特征在于,应用于消息***,所述消息***包括生产者、消息代理服务集群和消费者,所述消息代理服务集群包括多 个节点,每个节点包括每个副本组的一个副本,且包括属于不同副本组的一主代理服务器以及至少一副代理服务器,所述装置包括:消息同步模块,位于一节点的主代理服务器,用于接收到生产者发送的消息后,与另外至少一节点的副代理服务器进行消息同步;第一消息发送模块,位于所述主代理服务器,用于向消费者发送消息;第二消息发送模块,位于另外一个节点的副服务器,用于向消费者发送消息。
- 一种电子设备,其特征在于,包括:处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序,所述计算机程序被所述处理器执行时实现如权利要求1-7中任一项所述消息通信方法的步骤。
- 一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储计算机程序,所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述消息通信方法的步骤。
- 一种计算机程序,其特征在于,所述计算机程序被处理器执行时,使得电子设备执行如权利要求1至7中任一项所述消息通信方法的步骤。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110781013.7A CN113641511B (zh) | 2021-07-09 | 2021-07-09 | 一种消息通信方法和装置 |
CN202110781013.7 | 2021-07-09 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023280127A1 true WO2023280127A1 (zh) | 2023-01-12 |
Family
ID=78417043
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2022/103745 WO2023280127A1 (zh) | 2021-07-09 | 2022-07-04 | 一种消息通信方法和装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN113641511B (zh) |
WO (1) | WO2023280127A1 (zh) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113641511B (zh) * | 2021-07-09 | 2024-06-04 | 阿里云计算有限公司 | 一种消息通信方法和装置 |
CN114422591B (zh) * | 2021-12-22 | 2023-01-10 | 广州市玄武无线科技股份有限公司 | 点对点通信方法、数据通信***、计算机设备、存储介质 |
CN114338343B (zh) * | 2021-12-30 | 2023-12-12 | 海能达通信股份有限公司 | 通信方法及集群服务*** |
CN114598593B (zh) * | 2022-02-16 | 2023-08-29 | 阿里巴巴(中国)有限公司 | 消息处理方法、***、计算设备及计算机存储介质 |
CN114745393B (zh) * | 2022-03-31 | 2024-06-21 | 阿里云计算有限公司 | 会话同步***及其方法、云计算中心和云计算设备 |
CN115086153B (zh) * | 2022-05-20 | 2024-05-28 | 阿里巴巴(中国)有限公司 | 消息处理***、消息处理方法、设备和存储介质 |
CN115334155B (zh) * | 2022-08-12 | 2024-04-19 | 中国建设银行股份有限公司 | 一种消息队列代理方法和装置 |
CN115914246A (zh) * | 2022-10-08 | 2023-04-04 | 广州市玄武无线科技股份有限公司 | 离线消息的点对点通信方法、***、装置及存储介质 |
CN116893914A (zh) * | 2023-09-11 | 2023-10-17 | 中移(苏州)软件技术有限公司 | 消息处理的方法、消息队列***、客户端和电子设备 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5941999A (en) * | 1997-03-31 | 1999-08-24 | Sun Microsystems | Method and system for achieving high availability in networked computer systems |
CN107465735A (zh) * | 2017-07-31 | 2017-12-12 | 杭州多麦电子商务股份有限公司 | 分布式消息*** |
US10362131B1 (en) * | 2008-06-18 | 2019-07-23 | Amazon Technologies, Inc. | Fault tolerant message delivery |
CN111818112A (zh) * | 2019-04-11 | 2020-10-23 | ***通信集团四川有限公司 | 一种基于Kafka***的发送消息的方法和装置 |
CN112769924A (zh) * | 2020-12-31 | 2021-05-07 | 平安科技(深圳)有限公司 | RocketMQ的分布式部署方法、装置、设备及介质 |
CN113641511A (zh) * | 2021-07-09 | 2021-11-12 | 阿里云计算有限公司 | 一种消息通信方法和装置 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108306941A (zh) * | 2018-01-05 | 2018-07-20 | 上海你我贷互联网金融信息服务有限公司 | 一种分布式消息*** |
CN110601903B (zh) * | 2019-09-25 | 2022-04-01 | 广州荔支网络技术有限公司 | 一种基于消息队列中间件的数据处理方法及装置 |
CN112527520A (zh) * | 2020-12-01 | 2021-03-19 | 中国建设银行股份有限公司 | 一种部署消息中间件的方法和装置 |
-
2021
- 2021-07-09 CN CN202110781013.7A patent/CN113641511B/zh active Active
-
2022
- 2022-07-04 WO PCT/CN2022/103745 patent/WO2023280127A1/zh active Application Filing
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5941999A (en) * | 1997-03-31 | 1999-08-24 | Sun Microsystems | Method and system for achieving high availability in networked computer systems |
US10362131B1 (en) * | 2008-06-18 | 2019-07-23 | Amazon Technologies, Inc. | Fault tolerant message delivery |
CN107465735A (zh) * | 2017-07-31 | 2017-12-12 | 杭州多麦电子商务股份有限公司 | 分布式消息*** |
CN111818112A (zh) * | 2019-04-11 | 2020-10-23 | ***通信集团四川有限公司 | 一种基于Kafka***的发送消息的方法和装置 |
CN112769924A (zh) * | 2020-12-31 | 2021-05-07 | 平安科技(深圳)有限公司 | RocketMQ的分布式部署方法、装置、设备及介质 |
CN113641511A (zh) * | 2021-07-09 | 2021-11-12 | 阿里云计算有限公司 | 一种消息通信方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
CN113641511B (zh) | 2024-06-04 |
CN113641511A (zh) | 2021-11-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2023280127A1 (zh) | 一种消息通信方法和装置 | |
KR100575497B1 (ko) | 내고장성 컴퓨터 시스템 | |
US9769110B2 (en) | Message delivery in messaging networks | |
US9612928B2 (en) | Memory-mirroring control apparatus and memory-mirroring control method | |
US20100235431A1 (en) | Datacenter synchronization | |
CN102088490B (zh) | 数据存储方法、设备和*** | |
CN111917846A (zh) | 一种Kafka集群切换方法、装置、***、电子设备及可读存储介质 | |
EP1410197A2 (en) | Scaleable message system | |
CN105493474A (zh) | 用于支持用于同步分布式数据网格中的数据的分区级别日志的***及方法 | |
CN108390919B (zh) | 一种用于高可靠双机热备的消息同步***及方法 | |
CN111913837A (zh) | 大数据环境下实现分布式中间件消息恢复策略管理的*** | |
CN111400065B (zh) | 一种分离全局zookeeper的pulsar消息异地多活方法及*** | |
CN112052104A (zh) | 基于多机房实现的消息队列的管理方法及电子设备 | |
CN111708843A (zh) | 一种基于MGR的跨数据中心MySQL多活实现方法 | |
US10348817B2 (en) | Optimizing latency and/or bandwidth of large client requests for replicated state machines | |
CN114598593B (zh) | 消息处理方法、***、计算设备及计算机存储介质 | |
CN107070977B (zh) | 一种能够减少延时的数据传输方法 | |
CN111865632B (zh) | 分布式数据存储集群的切换方法及切换指令发送方法和装置 | |
CN112822285B (zh) | 对象存储分布式服务质量的优化***、方法、设备和介质 | |
Jia et al. | A classification of multicast mechanisms: implementations and applications | |
TW201828087A (zh) | 分布式儲存系統的服務節點切換方法及裝置 | |
Ji et al. | RocketHA: A High Availability Design Paradigm for Distributed Log-Based Storage System | |
CN115632947A (zh) | 一种配置下发方法及装置 | |
CN111865632A (zh) | 分布式数据存储集群的切换方法及切换指令发送方法和装置 | |
JP6100135B2 (ja) | フォールトトレラントシステム及びフォールトトレラントシステム制御方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 22836878 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 22836878 Country of ref document: EP Kind code of ref document: A1 |