此内容没有您所选择的语言版本。
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. 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 7 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 7 Supported Configurations.
2.3. 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.4. Monitoring and management
AMQ Broker provides several tools you can use to monitor and manage your brokers.
- AMQ Management Console
- AMQ Management 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
artemisCLI, 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.
