Introduction

In order to provide massive scalability, Amazon MQ supports a feature known as Network of Brokers. In this configuration you can connect multiple single or active/standby brokers into a network using a topology. Each active/standby broker runs in two availability zones, with messages stored in a shared durable storage. Thus, providing high availability and message durability in itself.

While there are many different topologies for connecting brokers - there are a few topology patterns described in AWS documentation. For this lab,the default 3 node mesh broker topology is deployed with active/standby broker configuration.

In the Mesh topology, Broker1 and Broker2, Broker2 and Broker3, Broker1 and Broker3 are connected with each other using OpenWire network connectors. Please follow the instructions below to understand how Broker network is configured in a Mesh topology.

Go to AWS Console, Open console for Amazon MQ, find one of the mesh brokers, the name of the broker is NoB1, NoB2 and NoB3. We are going to use these names to refer to the three brokers in the mesh going forward in this and other labs in this section.

In the broker details page, you should see “Configuration revision”, under this click on the link to open Broker Configuration.

Nob Configuration Revision

In the XML broker configuration, look for networkConnectors. In this XML item, you will see four networkConnector blocks. Two for queues and two for topics. For each queue and topic, a set of networkConnector items each for connection from the current broker and two other brokers in the mesh.

Each networkConnector establishes a connection from one broker to another in a specific direction. A networkConnector from NoB1 to NoB2, propagates messages from NoB1 to NoB2. In order for NoB2 to send messages to NoB1, either add an explicit networkConnector from NoB2 to NoB1 or mark the NoB1 to NoB2 networkConnector with duplex attribute. There are two key points here for you to remember:

In a network of brokers, messages flow between brokers on using networkConnectors only when a consumer demands them. The messages do not flow to other brokers if no consumer is available. For example, when producer sends messages to NoB1, if no consumer exists on NoB2 or NoB3, the messages remain in NoB1. However, there is a special configuration staticallyIncludedDestinations which if set with specific destinations, brokers will forward messages to those destinations even without a consumer.

The duplex attribute on networkConnector essentially establishes a two-way connection on the same port. This would be useful when network connections are traversing a firewall and is common in Hub and Spoke broker topology. In a Mesh topology, it is recommended to use explicit unidirectional networkConnector as it allows flexibility to include or exclude destinations.

Each broker can accept connections from clients. The client endpoints are named transportConnectors. In order to scale, client connections can be divided across brokers. Because these brokers are all connected using network connectors, when a producer sends messages to say NoB1, the messages can be consumed from NoB2 or from NoB3. This helps to distribute the load from clients across brokers in Mesh.