本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
确保有效的 Amazon MQ 性能
以下设计模式可以提高 Amazon MQ 代理的效率和性能。
对具有慢速使用者的队列禁用并发存储和分派
默认情况下，Amazon MQ 针对具有快速使用者的队列进行优化：
-
当使用者能够跟上创建器生成的消息速率时，将其视为快速。
-
如果队列造成了未确认消息积压，并可能导致创建器吞吐量下降，则将使用者视为慢速。
要指示 Amazon MQ 针对具有慢速使用者的队列进行优化，请将 concurrentStoreAndDispatchQueues 属性设置为 false。有关示例配置，请参阅 concurrentStoreAndDispatchQueues。
选择正确的代理实例类型以实现最佳吞吐量
代理实例类型的消息吞吐量取决于应用程序的使用案例和以下因素：
-
持久模式下 ActiveMQ 的使用
-
消息大小
-
创建器和使用者的数量
-
目标的数量
了解消息大小、延迟和吞吐量之间的关系
根据您的使用案例，较大的代理实例类型不一定能提高系统吞吐量。当 ActiveMQ 将消息写入持久存储中，消息的大小决定了系统的限制因素：
-
如果您的消息大小不到 100 KB，则持久性存储延迟是限制因素。
-
如果您的消息大小超过 100 KB，则持久性存储吞吐量是限制因素。
当您在持久模式下使用 ActiveMQ 时，通常会在使用者较少或使用者较慢的情况下发生写入存储。在非持久模式下，如果代理实例的堆内存已满，则也会在使用者较慢的情况下发生写入存储。
要为您的应用程序确定最佳代理实例类型，我们建议您测试不同的代理实例类型。有关详细信息，请参阅Broker instance types以及 Measuring the Throughput for Amazon MQ using the JMS Benchmark
较大代理实例类型的使用案例
当较大代理实例类型提高吞吐量时，存在以下三个常见使用案例：
-
非持久模式 – 当您的应用程序在代理实例故障转移（例如，播报体育赛事比分时）期间对消息丢失不太敏感时，您通常可以使用 ActiveMQ 的非持久模式。在此模式下，仅在代理实例的堆内存已满时，ActiveMQ 才会将消息写入持久性存储中。使用非持久模式的系统可以从较大代理实例类型所提供的较高内存、较快 CPU 以及较快网速中受益。
-
快速使用者 – 当存在活动使用者且 concurrentStoreAndDispatchQueues 标志启用时，ActiveMQ 允许消息直接从创建器传递到使用者，而无需将消息发送到存储（即使在持久模式下也是如此）。如果您的应用程序可以快速使用消息（或者您可以将使用者设计为这么做），则应用程序能从较大代理实例类型中受益。要让您的应用程序更快地使用消息，请为应用程序实例添加使用者线程，或者纵向或横向扩展应用程序实例。
-
批处理事务 – 当您使用持久模式且在每个事务中发送多条消息时，您可以使用较大代理实例类型来实现总体更高消息吞吐量。有关更多信息，请参阅 ActiveMQ 文档中的我是否应使用事务？
。
选择正确的代理存储类型以实现最佳吞吐量
要利用跨多个可用区的高持久性和复制功能，请使用 Amazon EFS。要利用低延迟和高吞吐量，请使用 Amazon EBS。有关更多信息，请参阅Storage。
正确配置您的代理网络
当您创建代理网络时，请为您的应用程序正确配置它：
-
启用持续模式 – 因为（相对于其对等项）每个代理实例充当创建者或使用者，所以代理网络不提供消息的分布式复制。第一个充当使用者的代理接收消息并将其保留到存储中。此代理向创建者发送确认，并将消息转发给下一个代理。当第二个代理确认消息的持久性后，第一个代理将删除该消息。
如果禁用持久模式，则第一个代理会在不将消息保留到存储的情况下确认创建者。有关更多信息，请参阅 Apache ActiveMQ 文档中的复制消息存储
和持久和非持久交付有什么区别？ 。 -
请勿对代理实例禁用建议消息 – 有关更多信息，请参阅 Apache ActiveMQ 文档中的建议消息
。 -
请勿使用多播代理发现 – Amazon MQ 不支持使用多播的代理发现。有关更多信息，请参阅 Apache ActiveMQ 文档中的发现、多播和 zeroconf 的区别是什么？
。