JMS Learning (vi) high-availability implementation of-ACTIVEMQ

One, ACTIVEMQ high availability architecture

ACTIVEMQ's high availability architecture is based on the Master/slave model. ACTIVEMQ provides a total of four configuration scenarios to configure Ha, where shared nothing master/slave is no longer used after version 5.8, and zookeeper-based replicated is introduced in the ActiveMQ5.9 version LevelDB Store ha scenario.

Second, the configuration explanation of Master/slave architecture

①shared Nothing Master/slave The most important features of this architecture are:

1) both Master and slave each store persistent messages separately, and they do not share data.

2) When master receives a persistent message, it needs to Sync (sync) to slave before sending an ACK acknowledgement to producer.

3) Only Master is responsible for client requests, Slave does not receive client requests. The slave is connected to master and is responsible for backing up messages.

4) master fails, Slave has two ways of handling:? to become master; Close (stop service)---depending on the configuration.

5) The "Split Brain" phenomenon may occur between Master and slave. For example: The master itself is normal, but the network between master and slave fails, and the network failure causes slave to think that master is down because it will become master (depending on the configuration: Shutdownonmasterfailure). At this point, there will be two master for the client.

6) Slave can only synchronize messages after it is connected to master. Before slave connects to master producer messages sent to master will not be synchronized to slave, which can be configured through the configuration (waitforslave) parameter, only if Slave is also started. Master starts initializing Transportconnector Accept client request (Producer request)

7) If either Master or slave one of them goes down, messages that are not synchronized between them cannot be synchronized automatically, then only the unsynchronized messages can be recovered manually. This means: "ACTIVEMQ does not provide any effective means to allow master and slave to automatically synchronize data during a failover."

8) for non-persisted messages, it is not synchronized to slave. Therefore, master down, non-persistent messages are lost.

②shared Database Master/slave

This is a very common kind of architecture. "Shared storage" means that the data between master and slave is shared.

So how to avoid conflict? By competing for an exclusive lock on a database table, only Master has a lock, and the unlocked automatically becomes slave.

ActiveMQ Message Broker uses a relational database, it grabs an exclusive lock on a table ensuring this no other ActiveMQ Broker can access the database at the same time

For shared storage, only persistent messages are shared. For non-persisted messages, they are saved in memory. You can force all messages to persist through the configuration (Forcepersistencymodebrokerplugin Persistenceflag) property.

When Master is down, slave can automatically take over the service as master. Because the data is shared, there is no need for data replication and synchronization between master and slave. Slave a competition lock to determine who is master.

③shared File System Master/slave

This way and shared database storage principle is basically the same, (file system also has a file lock), it is not described in detail.

④ the nearest replicated LevelDB Store

1) Use Zookeeper to elect master in this way. To conduct an election, a majority "participant" is required. Because there are multiple brokers in the replicated LevelDB store, one is elected as master from multiple brokers and the others become slave. Only master receives the client connection, slave is responsible for connecting to master, and Receive（synchronous mode, asynchronous mode) data on Master.

The elected master broker node starts and accepts client connections. The other nodes go to slave mode and connect the master and synchronize their persistent state/w it.

The above also shows that each broker stores data separately . Because Master wants to copy the new data to the slave. From this point of view: "Share Storage" is a bit inappropriate to call this way.

2) Another application of quorum mechanism

Assuming that there are 3 brokers, the election requires at least two broker consent (most) to elect master. In addition, you can return an ACK to producer only when the new message is copied to most brokers. Other minority brokers can replicate new messages asynchronously in the background.

All messaging operations which require a sync to disk would wait for the update to being replicated to a quorum of the nodes B Efore completing. So if you configure the store with replicas= "3" then the quorum size is (3/2+1) =2. The master would store the update locally and wait for 1 other slave to store the update before reporting success.

For example: A total of 3 broker, a master, two slave. When the new message arrives at Master, Master needs to synchronize the message to one of the slave before sending an ack to producer to confirm that the message was sent successfully.

The other slave, you can copy the new message asynchronously in the background. In addition, it can tolerate a slave outage. (Can tolerate no more than the majority of broker outages)

This design requirement can guarantee the reliability of the message in the cluster, and only if the (REPLICAS/2 + 1) node is physically faulted, there is a risk of losing the message. In addition, it also improves responsiveness because it does not need to synchronize messages to all slave, but only to the majority of the broker.

3) What is the standard to judge who is master and who is slave? "The election will be based on the size of the message log, the weight, the larger the version stamp (data is up-to-date), the higher the weight of the broker takes precedence to master, and the other broker as slave and follow master." 】

Third, references

Quorum mechanism of Distributed system theory

Https://activemq.apache.org/artemis/docs/1.0.0/ha.html

Replicated LevelDB Store HA official documentation

Activemq and HA Architecture (master/slave)

JMS Learning (vi) high-availability implementation of-ACTIVEMQ