이 콘텐츠는 선택한 언어로 제공되지 않습니다.

3.5. Scalability and High Performance


Overview

In a scalable messaging system, brokers can support an increasing number of concurrently connected clients. In a high-performance messaging system, brokers can process messages through the system, from producers to consumers, at a high rate. In a scalable high-performance messaging system, multiple brokers can concurrently process a large volume of messages for a large number of concurrently connected clients.
You can scale up Red Hat JBoss A-MQ to provide connectivity for thousands of concurrent client connections and many more destinations.
  • Horizontal scaling
    Create networks of brokers to vastly increase the number of brokers and potentially the number of producers and consumers.
  • Vertical scaling
    Enable individual brokers to handle more connections—for example (when possible), use embedded brokers and VM transports, transactions, nonpersistent messages with the failover transport set to cache asynchronous messages; allocate additional memory; tune the OpenWire protocol; optimize the TCP transport.
Besides the obvious components—network and system hardware, transport protocols, message compression—which you can tune to increase application performance, JBoss A-MQ provides means for avoiding bottlenecks caused by large messages and for scheduling message dispatches.

Network of brokers

As shown in Figure 3.2, “Network of Brokers Example”, the brokers in a network of brokers are connected together by network connectors, which define the broker-to-broker links that form the basis of the network. Through network connectors, a network of brokers keeps track of all active consumers, receiving notifications whenever a consumer connects to or disconnects from the network. Using the information provided through client registration, brokers can determine where and how to route messages to any consumer in a network of brokers.

Figure 3.2. Network of Brokers Example

Network of Brokers Example
The brokers use a store-and-forward delivery method to move messages between them. A broker first stores messages locally before passing them on to another broker in its network. This scheme supports the distribution of queues and topics across a network of brokers.
A network of brokers can be employed in a variety of network topologies, such as hub-and-spoke, daisy chain, or mesh.
For details, see "Using Networks of Brokers".
Note
You can incorporate multiple master/slave topologies in networks of brokers to ensure a fault tolerant messaging system.

Blob messages

Blob(binary large object) messages provide a mechanism for robust transfers of very large files, avoiding the bottlenecks often associated with them. Retrieval of a blob message is atomic. Blob messages are transferred out-of-bounds (outside the broker application) via FTP or HTTP. The blob message does not contain the file. It is only a notification that a blob is available for retrieval. The blob message contains the producer-supplied URL of the blob's location and a helper method for acquiring an InputStream to the actual data.
Though blob transfers are more robust than stream transfers, blobs rely on an external server for data storage.
For details, see ActiveMQ in Action (Snyder, Bosanac, and Davies).

Stream messages

Stream messages provide a mechanism for efficiently transferring very large files, avoiding the bottlenecks often associated with them. A stream message induces a client to function as a Java IOStream. The broker chunks OutputStream data received from the producer and dispatches each chunk as a JMS message. On the consumer, a corresponding InputStream must reassemble the data chunks.
This feature employs message groups so that messages with the same JMSXGroupID value are pinned to a single consumer. Using streams with queue destinations that connect to multiple receivers, regular or exclusive, does not affect message order. However, using streams with more than one producer could interfere with message ordering.
For details, see ActiveMQ in Action (Snyder, Bosanac, and Davies).

Scheduled message delivery

Using properties in the org.apache.activemq.ScheduledMessage interface, you can schedule when messages are dispatched to a consumer. The broker stores scheduled messages persistently, so they survive broker failure and are dispatched upon broker startup.
Four ScheduledMessage properties appended to the transport connector enable fine-grained scheduling:
  • AMQ_SCHEDULED_DELAY—Time in milliseconds to delay dispatch.
  • AMQ_SCHEDULED_PERIOD—Time in milliseconds to wait after invoking schedule to dispatch first message.
  • AMQ_SCHEDULED_REPEAT—Maximum number of times to reschedule any message for dispatch.
  • AMQ_SCHEDULED_CRON—Use the specified cron entry [string] to schedule a single-message dispatch.
For details, see ActiveMQ in Action (Snyder, Bosanac, and Davies).

Consumer clusters

JBoss A-MQ supports reliable, high-performance load balancing on queues distributed across multiple consumers. If one of the consumers fails, JBoss A-MQ redelivers any unacknowledged messages to a queue's other consumers, by default, in round-robin order. When one consumer is faster than the others, it receives more messages, and when any consumer slows down, other consumers take up the slack. This enables a queue to reliably load balance processing across multiple consumer processes.
Using queues this way in a network of brokers, you can implement a grid-style processing model, in which a cluster of worker processes, in a scalable and efficient Staged Event-Driven Architecture (SEDA) way, asynchronously process messages sent to a queue.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.