ROCKETMQ (ii)--cluster deployment

Cluster deployment mode single Master multi Master mode multi-master multi-slave mode asynchronous replication multi-master multi-slave mode synchronous double write physical deployment structure dual Master Cluster Deployment server environment Configure IP map upload unzip create storage path modify configuration file Replace with the following modification date Log configuration file modify startup script Parameters start Deployment console Data Cleansing PS

In the metaq1.x/2.x version, the distributed coordination uses the zookeeper, and Rocketmq himself implements a nameserver, so ROCKETMQ starts with the corresponding nameserver first. How to deploy a cluster

ROCKETMQ deployment is more flexible and recommends several ways to deploy broker clusters. 1. Single Master

Obviously, this is a risky approach that, once the broker restarts or goes down, will cause the entire service to be unavailable and not recommended for use on the online environment. 2. Multi-Master Mode

A cluster without slave, all master, such as 2 master or 3 master advantages : Simple configuration, a single master outage or restart maintenance has no effect on the application, when the disk is configured as RAID10, even if the machine is not recoverable in the case of a Because the RAID10 disk is very reliable, the message is not lost (the asynchronous brush disk loses a small number of messages, the Sync brush disk does not lose). Highest performance. cons : During a single machine outage, messages that are not consumed on this machine are not subscribed until the machine resumes, and the real-time nature of the messages is affected. 3. Multi-master multi-slave mode, asynchronous replication

Each master configures a Slave, there are many pairs of master-slave,ha with asynchronous replication, the main has a short message delay, millisecond level. Advantage : Even if the disk is damaged, the message is lost very little, and the message real-time is not affected, because after master goes down, the consumer can still consume from slave, this process is transparent to the application and does not require human intervention. Performance is almost the same as multi-master mode. cons : Master down, disk corruption, a small number of messages will be lost. 4. Multi-master multi-slave mode, synchronous double write

Each master configuration of a Slave, there are many pairs of master-slave,ha with synchronous double write, master and standby are written successfully, to the application return success. Pros : There is no single point in data and services, and in the case of master downtime, there is no delay in message, and service availability and data availability are very high. Disadvantage : performance is slightly lower than asynchronous replication mode, approximately 10% lower, and the RT sending a single message is slightly higher. Physical Deployment Structure

Take the multi-master multi-slave model as an example and look at the ROCKETMQ physical deployment structure:

NameServer

NameServer is an almost stateless node that can be deployed in a cluster with no information synchronization between nodes. Broker

The broker deployment is relatively complex, the broker is divided into master and slave, and one master can correspond to multiple slave, but a slave can only correspond to one master,master and slave by specifying the same brokername , different brokerid are defined, Brokerid is 0 for master, and non-0 represents slave. Master can also deploy multiple. Each broker establishes a long connection with all nodes in the NameServer cluster, registering Topic information to all NameServer on a timed basis. Producer

Producer establishes a long connection with one of the nodes in the nameserver cluster (randomly selected), periodically takes topic routing information from the nameserver, and establishes a long connection to master that provides the topic service, and periodically sends a heartbeat to master. The producer is completely stateless and can be deployed in a cluster. Consumer

Consumer establishes a long connection with one of the nodes in the nameserver cluster (randomly selected), periodically takes topic routing information from the nameserver, and establishes a long connection to the master and topic that provide the slave service, and timing to master, Slave sends a heartbeat. Consumer can either subscribe to messages from master or subscribe to messages from slave, and the subscription rules are determined by the broker configuration. Dual-Master cluster deployment

This is a two-master cluster, for example, to build. (Dual-master cluster will be deployed, multi-master or multi-master multi-Slave also naturally no problem) 1. Server Environment

If the conditions allow, nameserver and broker are deployed on separate machines, I am using my own computer to build virtual machines, deployed in virtual machines, limited to their own computer configuration, nameserver and broker are placed on a single machine.

Serial Number	IP	role	Mode
1	192.168.2.222	Nameserver1,brokerserver1	Master1
1	192.168.2.223	Nameserver2,brokerserver2	Master2

2. Configure IP mapping

In fact, it is not worthy, for the sake of deployment convenience, I configured anyway. In the following file, configure:

IP	NAME
192.168.2.222	Ocketmq-nameserver-1
192.168.2.222	Rocketmq-master-1
192.168.2.223	Rocketmq-nameserver-2
192.168.2.223	Rocketmq-master-2

3. Upload and unzip

This is not the latest version of the ROCKETMQ, but rather the classic version 3.2.6, the two machines perform the same operation.
First upload the alibaba-rocketmq-3.2.6.tar.gz file to/usr/local, and then unzip it. For ease of operation, a soft connection is established here:

# TAR-ZXVF Alibaba-rocketmq-3.2.6.tar.gz-c/usr/local
# mv ALIBABA-ROCKETMQ alibaba-rocketmq-3.2.6
# ln-s Alib aba-rocketmq-3.2.6 ROCKETMQ

4. Create a storage path

The two machines perform the same operation:

# Mkdir-p Rocketmq/store/{commitlog,consumequeue,index}

5. Modify the configuration file (replace with the following content)

The two machines perform the same operation, and note that the value of the brokername is consistent with the configuration file:

# vim/usr/local/rocketmq/conf/2m-noslave/broker-a.properties
# vim/usr/local/rocketmq/conf/2m-noslave/ Broker-b.properties

Here the commonly used parameter configuration is listed basically, the specific meaning in the note:

#所属集群名字 Brokerclustername=rocketmq-cluster #broker名字, note that there are different configuration files filled in differently Brokername=broker-a|broker-b #0 represents Master, >0 represents Slave brokerid=0 #nameServer地址, semicolon split namesrvaddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876 # when sending a message , automatically create a topic that does not exist on the server, the number of queues created by default Defaulttopicqueuenums=4 # Allow Broker to automatically create topic, suggest offline on, off Autocreatetopicenable=true on line # Allow broker to automatically create subscription groups, suggest offline on, line off Autocreatesubscriptiongroup=true # Broker external Service Listener Port listenport=10911 # Delete file point in time, default 4 o'clock in the morning de letewhen=04 #文件保留时间, default 48 hours filereservedtime=120 #commitLog每个文件的大小默认1G mapedfilesizecommitlog=1073741824 # Consumequeue per file default 30W, adjust mapedfilesizeconsumequeue=300000 #destroyMapedFileIntervalForcibly = 120000 # according to business conditions redeletehangedfileinterval=120000 #检测物理文件磁盘空间 diskmaxusedspaceratio=88 #存储路径 storepathrootdir=/usr/local/rocketmq/ Store #commitLog storage path storepathcommitlog=/usr/local/rocketmq/store/commitlog #消费队列存储路径存储路径 storepathconsumequeue=/ Usr/local/rocketmq/store/consumequeue #消息索引存储路径 Storepathindex=/usr/local/rocketmq/storE/index #checkpoint file storage path storecheckpoint=/usr/local/rocketmq/store/checkpoint #abort file storage path abortfile=/usr/local/ Rocketmq/store/abort #限制的消息大小 maxmessagesize=65536 #flushCommitLogLeastPages =4 #flushConsumeQueueLeastPages = 2 #
flushcommitlogthoroughinterval=10000 #flushConsumeQueueThoroughInterval =60000 #Broker role #-async_master Asynchronous Replication MASTER #-Sync_master Synchronous Dual Write MASTER #-SLAVE brokerrole=async_master #刷盘方式 #-async_flush Asynchronous Brush disk #-Sync_flush Synchronous brush Disc Flushdisktype=asyn C_flush #checkTransactionMessageEnable =false #发消息线程池数量 #sendMessageThreadPoolNums =128 #拉消息线程池数量 # pullmessagethreadpoolnums=128

6. Modify the log configuration file

Modify the directory for the log profile, and the two machines perform the same operation:

# mkdir-p/usr/local/rocketmq/logs
# cd/usr/local/rocketmq/conf && sed-i ' s#${user.home}#/usr/local/ Rocketmq#g ' *.xml

7. Modify Startup Script Parameters

Tune the JVM, including nameserver and broker. Limited to the configuration of their own machines, the parameters of a small adjustment. However, the minimum heap of ROCKETMQ is 1g, otherwise it cannot be started. Both machines perform the same operation.
Open the Runbroker configuration file:

# vim/usr/local/rocketmq/bin/runbroker.sh

The contents of the amendment are as follows:

Java_opt= "${java_opt}-server-xms1g-xmx1g-xmn512m-
xx:permsize=128m-xx:maxpermsize=320m"

Open the Runserver configuration file:

# vim/usr/local/rocketmq/bin/runserver.sh

The contents of the amendment are as follows:

Java_opt= "${java_opt}-server-xms1g-xmx1g-xmn512m-
xx:permsize=128m-xx:maxpermsize=320m"

8. Start

To start Namerserver, restart Broker, both machines perform the same operation.
Start nameserver

# cd/usr/local/rocketmq/bin
# nohup SH mqnamesrv &

Start Brokerserver ( node 1 is a.properties, Node 2 is b.properties)

# cd/usr/local/rocketmq/bin
# nohup sh mqbroker-c/usr/local/rocketmq/conf/2m-noslave/broker-a.properties >/ Dev/null 2>&1 &
# NETSTAT-NTLP

Take a look at the following command

# JPS

You can use the following command to view the boot log:

# tail-f-N 500/usr/local/rocketmq/logs/rocketmqlogs/broker.log
# tail-f-N 500/usr/local/rocketmq/logs/ Rocketmqlogs/namesrv.log

9. Deploying The control console

To deploy Rocketmq-console.war in Tomcat, modify the Web-inf/classes/config.properties:

Start the control console and look at the homepage:

Interface is relatively concise, it is best to enter the topic interface for mqadmin operation command:

10. Data Cleansing

First stop the service:

# cd/usr/local/rocketmq/bin
# sh mqshutdown broker
# sh Mqshutdown namesrv

Then clear the store, but don't forget to re-build it:

# rm-rf/usr/local/rocketmq/store
# mkdir/usr/local/rocketmq/store
# mkdir/usr/local/rocketmq/store/ Commitlog
# mkdir/usr/local/rocketmq/store/consumequeue
# Mkdir/usr/local/rocketmq/store/index

PS:If you want to take the master-slave, repeat again the difference between master and slave in the configuration

The broker is paired with the slave by specifying the same brokername parameter, and the master Brokerid must be 0,slave Brokerid must be greater than 0. Another master can mount multiple slave, and multiple slave under the same master are differentiated by specifying different brokerid. Effect of Broker restart on clients

The broker restart may cause a failed message to be sent to this machine, and ROCKETMQ provides a graceful way to close the broker by executing the following command, which clears the broker's write permissions, and after 40s, all clients update the broker routing information. Closing the Broker at this point will not cause the message to fail because all messages are sent to the other broker.

# sh mqadmin wipewriteperm-b brokername-n namesrvaddr

The relationship between Master and slave

ROCKETMQ Open source version, master down, slave cannot switch to master, here The slave is not writable, but readable, similar to the Mysql master and Standby mode.