このコンテンツは選択した言語では利用できません。

Chapter 2. Understanding AMQ Broker

AMQ Broker enables you to loosely couple heterogeneous systems together, while providing reliability, transactions, and many other features. Before using AMQ Broker, you should understand the capabilities it offers.

2.1. Broker instances

In AMQ Broker, the installed AMQ Broker software serves as a "home" for one or more broker instances. This architecture provides several benefits, such as:

You can create as many broker instances as you require from a single AMQ Broker installation.
The AMQ Broker installation contains the necessary binaries and resources that each broker instance needs to run. These resources are then shared between the broker instances.
When upgrading to a new version of AMQ Broker, you only need to update the software once, even if you are running multiple broker instances on that host.

You can think of a broker instance as a message broker. Each broker instance has its own directory containing its unique configuration and runtime data. This runtime data consists of logs and data files, and is associated with a unique broker process on the host.

2.2. Clustering and high availability

Clustering and high availability (HA) enable you to group multiple brokers together to increase messaging throughput and reliability.

Clustering

By using clustering, you can:

Connect brokers in a variety of topologies and architectures.
A broker cluster can contain brokers on a shared host, different hosts, or both shared and different hosts.
Load balance client connections across the brokers in the cluster.
Redistribute messages across the brokers in the cluster at runtime to avoid imbalanced load scenarios.

High availability (HA)

You can minimize downtime in a broker cluster by implementing HA. With HA, the brokers in the cluster are grouped into master-slave groups: master brokers are active and serve client requests, while slave brokers back them up. If a master broker goes offline, its slave broker becomes active. Clients can then reconnect to the slave broker and resume sending and receiving messages.

AMQ Broker supports several HA policies:

Replication: The master and slave brokers synchronize their messaging data over the network. If a master broker fails, the slave broker becomes active using the synchronized data.
Shared-store: Master and slave brokers share the same location for their messaging data. If a master broker fails, the slave broker becomes active using the data in the shared location.
Live-only: If a broker is shut down, it copies its messages and transaction state to another broker in the cluster. Typically, you use this policy to scale down a broker cluster, not to handle unexpected broker failures.

2.3. Security

AMQ Broker provides a number of methods you can use to authenticate clients and control what they can access on the broker.

Guest/anonymous access control

You can configure the broker to allow anonymous access. If a user does not have login credentials, or if their credentials fail validation, the user can be granted a guess account with limited access.

Basic user and password access control

With this method, you store client user names, passwords, and security roles in properties files. A client can connect to the broker by using its user name and password. After the connection is accepted, the role assigned to the client’s user name controls the resources they can access on the broker.

For an added layer of security, you can encrypt the client’s connection to the broker by configuring server-side SSL/TLS certificates. This is also called one-way SSL/TLS.

Certificate-based access control

This method provides greater security than user and password access control by using an SSL/TLS certificate to authenticate the client. Also called two-way SSL/TLS, both the broker and the client present certificates and validate each other’s identity during the TLS handshake. Once verified, the client is assigned to a security role that defines the resources it can access on the broker.

LDAP integration

If LDAP is deployed in your environment, you can integrate AMQ Broker with it to authenticate clients and authorize what they can access.

Kerberos integration

If Kerberos is deployed in your environment, you can integrate AMQ Broker with it to authenticate clients and authorize what they can access.

Note

You can only use Kerberos to authenticate and authorize AMQP clients.

2.4. Understanding the AMQ address model

AMQ Broker provides a flexible address model that enables you to define point-to-point and publish-subscribe messaging patterns that work for any messaging protocol.

An address represents a messaging endpoint. Each address has a routing type (anycast or multicast), and a set of queues (that is, destinations). Essentially, the address model enables you to define what you want the broker to do when it receives a message with a particular address.

Point-to-point messaging

The AMQ address model supports point-to-point messaging (also called anycast) in which a producer sends a message to a single consumer. If multiple consumers are connected to the same queue, messages are distributed among each consumer equally, provided the consumers are able to handle them equally. Point-to-point messaging provides traditional queue-like behavior.

Figure 2.1. Point-to-point messaging with one queue

You can also use point-to-point messaging with multiple queues for a single address. In this case, messages sent to the address are distributed evenly across all associated queues. If more than one consumer connects to the same queue, AMQ distributes messages between them.

Figure 2.2. Point-to-point messaging with two queues

Publish-subscribe messaging

The AMQ address model also supports publish-subscribe messaging (also called multicast) in which a producer sends a message to every consumer subscribed to the address. Publish-subscribe messaging provides topic-like behavior.

Figure 2.3. Publish-subscribe

Publish-subscribe messaging also supports durable and non-durable subscription queues.

Combining point-to-point and publish-subscribe messaging

AMQ Broker also supports both point-to-point and publish-subscribe semantics for the same address. This configuration is not common, but it does provide the greater flexibility required for advanced messaging patterns.

Figure 2.4. Point-to-point and publish-subscribe

2.5. Message persistence

AMQ Broker persists message data to ensure that messages are never lost, even if the broker fails or shuts down unexpectedly. AMQ Broker provides two options for message persistence: journal-based persistence and database persistence.

Journal-based persistence

The default method, this option writes message data to message journal files stored on the file system. Initially, each of these journal files is created automatically with a fixed size and filled with empty data. As clients perform various broker operations, records are appended to the journal. When one of the journal files is full, the broker moves to the next journal file.

Journal-based persistence supports transactional operations, including both local and XA transactions.

Journal-based persistence requires an IO interface to the file system. AMQ Broker supports the following:

Linux Asynchronous IO (AIO)

AIO typically provides the best performance, but it requires the following:

Linux Kernel version 2.6 or later
Supported file system
To see the currently supported file systems, see Red Hat AMQ Supported Configurations.

Java NIO

Java NIO provides good performance, and it can run on any platform with a Java 6 or later runtime.

Database persistence

This option stores message and bindings data in a database by using Java Database Connectivity (JDBC). This option is a good choice if you already have a reliable and high performing database platform in your environment, or if using a database is mandated by company policy.

The broker JDBC persistence store uses a standard JDBC driver to create a JDBC connection that stores message and bindings data in database tables. The data in the database tables is encoded using the same encoding as journal-based persistence. This means that messages stored in the database are not human-readable if accessed directly using SQL.

To use database persistence, you must use a supported database platform. To see the currently supported database platforms, see Red Hat AMQ Supported Configurations.

2.6. Resource consumption

AMQ Broker provides a number of options to limit memory and resource consumption on the broker.

Resource limits

You can set connection and queue limits for each user. This prevents users from consuming too many of the broker’s resources and causing degraded performance for other users.

Message paging

Message paging enables AMQ Broker to support large queues containing millions of messages while also running with a limited amount of memory. When the broker receives a surge of messages that exceeds its memory capacity, it begins paging messages to disk. This paging process is transparent; the broker pages messages into and out of memory as needed.

Message paging is address-based. When the size of all messages in memory for an address exceeds the maximum size, each additional message for the address will be paged to the address’s page file.

Large messages

With AMQ Broker, you can send and receive huge messages, even when running with limited memory resources. To avoid the overhead of storing large messages in memory, you can configure AMQ Broker to store these large messages in the file system or in a database table.

2.7. Monitoring and management

AMQ Broker provides several tools you can use to monitor and manage your brokers.

AMQ Console

AMQ Console is a web interface accessible through a web browser. You can use to monitor network health, view broker topology, and create and delete broker resources.

CLI

AMQ Broker provides the artemis CLI, which you can use to administer your brokers. Using the CLI, you can create, start, and stop broker instances. The CLI also provides several commands for managing the message journal.

Management API

AMQ Broker provides an extensive management API. You can use it to modify a broker’s configuration, create new resources, inspect these resources, and interact with them. Clients can also use the management API to manage the broker and subscribe to management notifications.

AMQ Broker provides the following methods for using the management API:

Java Management Extensions (JMX) - JMX is a standard technology for managing Java applications. The broker’s management operations are exposed through AMQ MBeans interfaces.
JMS API - Management operations are sent using standard JMS messages to a special management JMS queue.

Logs

Each broker instance logs error messages, warnings, and other broker-related information and activities. You can configure the logging levels, the location of the log files, and log format. You can then use the resulting log files to monitor the broker and diagnose error conditions.