RocketMQ enterprise deployment solution

Background

Many businesses of the company are using RocketMQ, and the early business volume is small, there is no problem, and they do not pay much attention to the availability of the cluster, so the whole company's business shares a cluster. With the increase of the company's business volume, the business relies more and more heavily on the RocketMQ cluster, and begins to think about cluster split and risk sharing. At first, we want to divide each department into one cluster, but there is a need for data exchange between departments through RocketMQ. This will lead to the problem that an application needs to connect two RocketMQ clusters and the business side needs to change the code. In the case that the developer does not need to change the code, how can the cluster have no single point and risk sharing, and the cluster can be expanded horizontally in the future? our plan is as follows:

Cluster deployment planning

The whole cluster is divided into three layers, namely, application access layer, Nameserver cluster and Broker cluster. These three parts are described below:

Access layer

The access layer is actually the address where the application connects to the MQ cluster. In the current production environment, we directly connect to the IP address of nameserver. If the nameserver capacity is expanded or the server is changed, you need to modify the configuration and restart the service to update the new nameserver address. Although the probability of this is relatively low, it is still troublesome if it happens, so our new access solution is load balancer + domain name. Configure the address to connect to the MQ in the program as BLB:9876,nameserver1.chj.cloud:9876,nameserver2.chj.cloud:9876, so that both the load balancer and the domain name are insured. If the load balancer fails, the application will retry to connect the domain name.

Nameserver cluster

Nameserver itself is stateless and basically has no pressure, so we plan to deploy two units first; later, when we need to expand capacity, we need to restart broker in order to register broker with the new nameserver.

Broker cluster

Broker is responsible for the storage of messages. There are many modes of Broker deployment. We will deploy two architectures according to business requirements: multi-master and multi-slave (synchronous replication and synchronous flushing), and multi-master and multi-slave (asynchronous replication and asynchronous flushing). Clusters can also be expanded horizontally.

Broker naming convention: odd number is asynchronous replication + asynchronous flushing disk type, and even number is synchronous replication + synchronous flushing disk type, such as: broker-1,broker-2

Architecture diagram

Topic management

According to the business scenario, we create Topic on different Broker clusters. The business scenario is divided into two situations: one is to ensure that messages are not lost, but the throughput requirements are not high, such as order-related information. For example, the TopicA in the figure below is used to store the order-related Topic. Then we create this Topic on the Broker cluster with roles such as synchronous replication and synchronous flushing. The other is that the throughput is very high, but the message allows a small amount of loss, such as the monitoring-related information reported by the vehicle. For example, the TopicB in the figure below is the Topic used to store the monitoring-related information reported by the vehicle. Then we create this Topic on the Broker cluster with roles such as asynchronous replication and asynchronous disk flushing.