Shulou(Shulou.com)06/03 Report--

1 RocketMQ network deployment diagram

The RocketMQ network deployment diagram is shown in the following figure:

1.1 RocketMQ network deployment features: NameServer is an almost stateless node that can be deployed in clusters without any information synchronization between nodes. The deployment of Broker is relatively complex. Broker is divided into Master and Slave. A Master can correspond to multiple Slave, but a Slave can only correspond to one Master,Master and Slave. The corresponding relationship between Master,Master and Slave is defined by specifying the same BrokerName and different BrokerId. If BrokerId is 0, it means Master. Non-zero means Slave. Master can also deploy multiple. Each Broker establishes persistent connections with all nodes in the NameServer cluster and registers Topic information to all NameServer on a regular basis. Producer establishes a persistent connection with one of the nodes in the NameServer cluster (randomly selected), periodically takes Topic routing information from the NameServer, establishes a long connection to the Master that provides Topic services, and regularly sends a heartbeat to the Master. Producer is completely stateless and can be deployed in clusters. Consumer establishes a persistent connection with one of the nodes in the NameServer cluster (randomly selected), periodically takes Topic routing information from NameServer, establishes a long connection to Master and Slave that provide Topic services, and regularly sends heartbeats to Master and Slave. Consumer can subscribe to messages from either Master or Slave, and the subscription rules are determined by the Broker configuration. 2 NameServer cluster

The NameServer cluster is as follows:

NameServer Cluster IP address NameServer-1192.168.1.101NameServer-2192.168.1.102

Start separately

Nohup sh mqnamesrv & tail-f-n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/namesrv.log3 RocketMQ configuration file

As we all know, RocketMQ can be deployed in a variety of clusters, and their configuration files are separate, as follows:

[root@rocketmq01 conf] # ls-rlt / usr/local/rocketmq/conftotal 32khokashi rwkashi-1 root root 949 Sep 19 2017 broker.confdrwxr-xr-x 2 root root 60 Sep 19 2017 2m-noslavedrwxr-xr-x 2 root root 118Sep 19 2017 2m-2s-syncdrwxr-xr-x 2 root root 1182m Mustang Sep 19 2017 2m Mustang RWQUA-1 root root 3720 Apr 21 07:56 logback_namesrv.xml-rw-r--r-- 1 root root 3718 Apr 21 07:56 logback_filtersrv.xml-rw-r--r-- 1 root root 15146 Apr 21 07:56 logback_broker.xml-rw-r--r-- 1 root root 3789 Apr 21 07:56 logback_tools.xml

Description:

2m-noslave: multi-Master mode 2m-2s-sync: multi-Master multi-Slave mode, synchronous double-write 2m-2s-async: multi-Master multi-Slave mode, asynchronous replication

The configuration files provided by RocketMQ by default are the most basic, and many configurations are default values, which need to be modified according to the actual situation in the production environment. The sample configuration is as follows:

# brokerClusterName=rocketmq-cluster#broker name of the cluster to which it belongs. Note that different brokerName=broker-an is entered in different configuration files here | broker-b#0 indicates Master, > 0 indicates SlavebrokerId=0#nameServer address, and semicolon is divided into namesrvAddr=192.168.1.101:9876. 192.168.1.102 topic 987mm automatically creates topic that does not exist on the server when sending messages. Whether the number of queues created by default defaultTopicQueueNums=4# allows Broker to automatically create Topic, it is recommended that offline enable, online shutdown autoCreateTopicEnable=true# allows Broker to automatically create subscription groups, recommended offline enable, online shutdown listenPort=10911# external service listening port listenPort=10911# delete file point, default deleteWhen=04# file retention time at 4: 00 a.m. Default 48-hour fileReservedTime=120#commitLog size per file default 1GmapedFileSizeCommitLog=1073741824#ConsumeQueue 30W per file by default Adjust mapedFileSizeConsumeQueue=300000#destroyMapedFileIntervalForcibly=120000#redeleteHangedFileInterval=120000# detection physical file disk space diskMaxUsedSpaceRatio=88# storage path storePathRootDir=/usr/local/alibaba-rocketmq/store#commitLog storage path storePathCommitLog=/usr/local/alibaba-rocketmq/store/commitlog# consumption queue storage path storePathConsumeQueue=/usr/local/alibaba-rocketmq/store/consumequeue# message index storage path storePathIndex=/usr/local/alibaba-rocketmq/store/index#checkpoint file storage path storeCheckpoint=/usr/ Local/alibaba-rocketmq/store/checkpoint#abort file storage path abortFile=/usr/local/alibaba-rocketmq/store/abort# limited message size maxMessageSize=65536#flushCommitLogLeastPages=4#flushConsumeQueueLeastPages=2#flushCommitLogThoroughInterval=10000#flushConsumeQueueThoroughInterval=60000#Broker role #-ASYNC_MASTER asynchronous replication Master#- SYNC_MASTER synchronous double write Master#- SLAVEbrokerRole=ASYNC_MASTER# flush mode #-ASYNC_FLUSH asynchronous flush disk #-SYNC_FLUSH synchronous flush flushDiskType=ASYNC_FLUSH#checkTransactionMessageEnable=false# number of sending thread pool # number of sendMessageThreadPoolNums=128# pull message thread pool # pullMessageThreadPoolNums=1284 Broker cluster deployment

There are several different ways to deploy a Broker cluster. The Slave here is not writable but readable, which is similar to the active / standby mode of MySQL.

4.1 single Master

This method is risky. Once the Broker is restarted or down, the entire service will be unavailable. It is not recommended to use the online environment.

4.2 Multi-Master mode

A cluster has no Slave, and it is all Master, such as 2 Master or 3 Master.

BrokerNamebrokerIdbrokerRoleIP address broker-a0ASYNC_MASTER192.168.1.101broker-b0ASYNC_MASTER192.168.1.102

Advantages:

The configuration is simple, and the downtime or restart maintenance of a single Master will not affect the application. When the disk is configured as RAID10, even if the machine outage is unrecoverable, messages will not be lost because the RAID10 disk is very reliable (a small amount of messages will be lost in asynchronous flushing, and none will be lost in synchronous flushing). The highest performance.

Disadvantages:

During the downtime of a single machine, messages that are not consumed on this machine cannot be subscribed until the machine is restored, and the real-time performance of messages will be affected.

Startup steps:

Step 1: start the NameServer cluster first

Step 2: start the first Master at 192.168.1.101

Nohup sh mqbroker-c $ROCKETMQ_HOME/conf/2m-noslave/broker-a.properties > / dev/null 2 > & 1 & tail-f-n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log

Step 3: start the second Master at 192.168.1.102

Nohup sh mqbroker-c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties > / dev/null 2 > & 1 & tail-f-n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log4.3 multi-Master multi-Slave mode, asynchronous replication

Each Master is configured with a Slave. Multiple pairs of Master-Slave,HA are replicated asynchronously, and the master / slave has a short message delay of millisecond.

BrokerNamebrokerIdbrokerRoleIP address broker-a0ASYNC_MASTER192.168.1.101broker-a1SLAVE192.168.1.102broker-b0ASYNC_MASTER192.168.1.103broker-b1SLAVE192.168.1.104

Advantages: even if the disk is damaged, very few messages are lost, and the real-time performance of messages will not be affected, because after Master downtime, consumers can still consume from Slave, this process is transparent to the application. No human intervention is required. The performance is almost the same as the multi-Master mode.

Disadvantages: Master downtime, disk damage, will lose a small number of messages.

Start step

Step 1: start the NameServer cluster first

Step 2: start the first Master at 192.168.1.101

Nohup sh mqbroker-c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a.properties > $ROCKETMQ_HOME/log/mq.log > / dev/null 2 > & 1 & tail-f-n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log

Step 3: start the first Slave at 192.168.1.102

Nohup sh mqbroker-c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a-s.properties > $ROCKETMQ_HOME/log/mq.log > / dev/null 2 > & 1 & tail-f-n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log

Step 4: start the second Master at 192.168.1.103

Nohup sh mqbroker-c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b.properties > $ROCKETMQ_HOME/log/mq.log > / dev/null 2 > & 1 & tail-f-n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log

Step 5: start the second Slave on machine 192.168.1.104

Nohup sh mqbroker-c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b-s.properties > $ROCKETMQ_HOME/log/mq.log > / dev/null 2 > & 1 & 4.4 Multi-Master multi-Slave mode. Each Master is configured with one Slave for synchronous double write. Multiple pairs of Master-Slave,HA are synchronously double written. If both master and backup are successfully written, success is returned to the application.

BrokerNamebrokerIdbrokerRoleIP address broker-a0SYNC_MASTER192.168.1.101broker-a1SLAVE192.168.1.102broker-b0SYNC_MASTER192.168.1.103broker-b1SLAVE192.168.1.104

Advantages: there is no single point of data and service. In the case of Master downtime, there is no message delay, and the service availability and data availability are very high.

Cons: performance is slightly lower than asynchronous replication mode, about 10% lower, and the RT for sending a single message is slightly higher. At present, after the master downtime, the slave cannot be automatically switched to the host, and the automatic switching feature will be supported later.

Startup steps:

Step 1: start the NameServer cluster first

Step 2: start the first Master at 192.168.1.101

Nohup sh mqbroker-c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a.properties > $ROCKETMQ_HOME/log/mq.log > / dev/null 2 > & 1 & tail-f-n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log

Step 3: start the first Slave at 192.168.1.102

Nohup sh mqbroker-c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a-s.properties > $ROCKETMQ_HOME/log/mq.log > / dev/null 2 > & 1 & tail-f-n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log

Step 4: start the second Master at 192.168.1.103

Nohup sh mqbroker-c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b.properties > $ROCKETMQ_HOME/log/mq.log > / dev/null 2 > & 1 & tail-f-n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log

Step 5: start the second Slave at 192.168.1.104

Nohup sh mqbroker-c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b-s.properties > $ROCKETMQ_HOME/log/mq.log > / dev/null 2 > & 1 & tail-f-n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log

Note: the above Broker and Slave pairs are paired by specifying the same brokerName parameters. The BrokerId of Master must be 0 and the BrokerId of Slave must be greater than 0. Multiple Slave can be mounted under another Master, and multiple Slave under the same Master can be distinguished by specifying different BrokerId.

4.5 Summary

1. Summary of asynchronous replication and synchronous double writing

2. Comparison of cluster modes.

Cluster operation and maintenance features: message reliability (master downtime) service availability (master downtime) other characteristics: simple Master structure, convenient capacity expansion, low machine requirements, synchronous flushing messages will not be lost as a whole, and unconsumed messages cannot be obtained, affecting real-time performance up to millisecond asynchronous Master asynchronous loss, synchronous double writes do not lose bad reviews, active and standby can not be automatically switched And the standby machine can only read but not write, which will cause the overall service not to be considered, unless the master-slave switching scheme Master-Slave (asynchronous replication) structure is complex, and the expansion is convenient to lose the overall message availability in case of failure, and the real-time performance affects the millisecond level. This group of services can only read and write performance is very high, suitable for medium message reliability, medium real-time requirements Master-Slave (synchronous double write) structure is complex. The expansion is convenient without losing the overall availability of messages, and does not affect the real-time performance. The performance of this group of services is 10% lower than that of asynchronous, so real-time is not more suitable for higher message reliability than asynchronous mode. 5 high availability exercise scenarios with medium real-time and low performance requirements

RocketMQ High availability walkthrough scenario

In the process of project sending message sending message receiving consumption message deactivating one namesrv does not affect communication deactivating all namesrv affects communication does not affect communication. Starting arbitrary namesrv resumes deactivating a single master broker does not affect communication deactivation all master broker affects communication. Unable to restore affect communication deactivate one slave broker does not affect communication disable all slave broker does not affect communication, recovery in seconds does not affect communication, recovery in seconds does not affect communication

The following is my official account QR code, welcome to follow. If the article is reproduced, please indicate the source www.leexide.com.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.