Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Best Practices für Amazon MQ für ActiveMQ In diesem Abschnitt finden Sie schnell Empfehlungen für die Maximierung der Leistung und die Minimierung der Durchsatzkosten bei der Arbeit mit ActiveMQ brokers auf Amazon MQ. ## Verändern oder löschen Sie auf keinen Fall die Amazon MQ Elastic Network-Schnittstelle Wenn Sie zum ersten Mal einen [Amazon MQ-Broker erstellen](getting-started-activemq.md), stellt eine [Elastic Network-Schnittstelle](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html) in der [Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Introduction.html) unter Ihrem Konto bereit. Deshalb sind verschiedene [EC2-Berechtigungen](security-api-authentication-authorization.md) dafür erforderlich. Die Netzwerkschnittstelle gestattet Ihrem Client (Erzeuger oder Verbraucher), mit dem Amazon MQ-Broker zu kommunizieren. Die Netzwerkschnittstelle wird als im *Service-Umfang* von Amazon MQ begriffen betrachtet, obwohl sie Teil der VPC Ihres Kontos ist. **Warnung** Sie dürfen diese Netzwerkschnittstelle nicht ändern oder löschen. Das Ändern oder Löschen der Netzwerkschnittstelle kann zu einem permanenten Verlust der Verbindung zwischen Ihrer VPC und Ihrem Broker führen. ![Diagramm, das Client, Elastic Network Interface und Amazon MQ Broker innerhalb einer Kunden-VPC und des Serviceumfangs zeigt.](http://docs.aws.amazon.com/de_de/amazon-mq/latest/developer-guide/images/amazon-mq-network-configuration-architecture-vpc-elastic-network-interface.png) ## Verwenden Sie immer Verbindungspools In einem Szenario mit einem einzigen Produzenten und einem einzigen Konsumenten (z. B. das [Erste Schritte: Einen ActiveMQ-Broker erstellen und eine Verbindung zu ihm herstellen](getting-started-activemq.md)-Tutorial) können Sie eine einzige [http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html](http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html)-Klasse für jeden Produzenten und Konsumenten verwenden. Beispiel: ``` // Create a connection factory. final ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(wireLevelEndpoint); // Pass the sign-in credentials. connectionFactory.setUserName(activeMqUsername); connectionFactory.setPassword(activeMqPassword); // Establish a connection for the consumer. final Connection consumerConnection = connectionFactory.createConnection(); consumerConnection.start(); ``` In realistischeren Szenarien mit mehreren Produzenten und Konsumenten hingegen kann es teuer und ineffizient sein, eine große Anzahl von Verbindungen für mehrere Produzenten zu generieren. In diesen Szenarien sollten Sie mehrere Produzentenanfragen mithilfe der [http://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html](http://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html)-Klasse gruppieren. Beispiel: **Anmerkung** Die Nachrichtenkonsumenten sollten *nie* die `PooledConnectionFactory`-Klasse verwenden. ``` // Create a connection factory. final ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(wireLevelEndpoint); // Pass the sign-in credentials. connectionFactory.setUserName(activeMqUsername); connectionFactory.setPassword(activeMqPassword); // Create a pooled connection factory. final PooledConnectionFactory pooledConnectionFactory = new PooledConnectionFactory(); pooledConnectionFactory.setConnectionFactory(connectionFactory); pooledConnectionFactory.setMaxConnections(10); // Establish a connection for the producer. final Connection producerConnection = pooledConnectionFactory.createConnection(); producerConnection.start(); ``` ## Immer Failover-Transport verwenden, um Verbindungen zu mehreren Broker-Endpunkten einzurichten Wenn Ihre Anwendung eine Verbindung zu mehreren Broker-Endpunkten einrichten muss – wenn Sie z. B. einen [aktiven/Standby-Bereitstellungsmodus verwenden](amazon-mq-broker-architecture.md#active-standby-broker-deployment) oder wenn Sie [von einem lokalen Message Broker auf Amazon MQ migrieren](https://docs.aws.amazon.com//amazon-mq/latest/migration-guide/) –, verwenden Sie den [Failover-Transport](http://activemq.apache.org/failover-transport-reference.html), um Ihren Konsumenten zu ermöglichen, eine Verbindung zu einem beliebigen dieser Endpunkte herzustellen. Beispiel: ``` failover:(ssl://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-east-2.amazonaws.com:61617,ssl://b-9876l5k4-32ji-109h-8gfe-7d65c4b132a1-2.mq.us-west-2.amazonaws.com:61617)?randomize=true ``` **Wichtig** Bei Brokern mit mehreren Verfügbarkeitszonen kann es während Wartungsfenstern und Broker-Neustarts zu Failovers kommen. Verwenden Sie den Failover-Transport, um die Verfügbarkeit Ihres Brokers sicherzustellen. ## Vermeiden Sie die Nachrichtenauswahl Sie können mit [JMS-Auswahlen](https://docs.oracle.com/cd/E19798-01/821-1841/bncer/index.html) Filter an Themenabonnements anfügen (um Nachrichten basierend auf ihrem Inhalt an Konsumenten weiterzuleiten). Doch die Verwendung von JMS-Auswahlen füllt den Filterpuffer des Amazon MQ-Brokers und verhindert somit das Filtern von Nachrichten. Im Allgemeinen sollten Sie vermeiden, dass Konsumenten Nachrichten weiterleiten können, denn für eine optimale Entkopplung von Konsumenten und Produzenten sollte sowohl der Konsument als auch der Produzent flüchtig sein. ## Virtuelle Ziele gegenüber dauerhaften Abonnements bevorzugen Ein [dauerhaftes Abonnement](http://activemq.apache.org/how-do-durable-queues-and-topics-work.html) kann sicherstellen, dass der Konsument alle Nachrichten erhält, die zu einem Thema veröffentlicht werden, z. B. nach einer Verbindungswiederherstellung. Die Verwendung von dauerhaften Abonnements schließt jedoch auch die Verwendung konkurrierender Verbrauchern aus und kann bei einem großem Umfang zu Leistungsproblemen führen. Ziehen Sie stattdessen die Verwendung von [virtuellen Zielen](http://activemq.apache.org/virtual-destinations.html) in Betracht. ## Wenn Sie Amazon VPC-Peering verwenden, vermeiden Sie Clients IPs im CIDR-Bereich `10.0.0.0/16` Wenn Sie Amazon VPC-Peering zwischen der lokalen Infrastruktur und Ihrem Amazon MQ-Broker einrichten, dürfen Sie keine Client-Verbindungen im CIDR-Bereich konfigurieren. IPs `10.0.0.0/16` ## Gleichzeitige Speicherung und Bereitstellung für Warteschlangen mit langsamen Konsumenten deaktivieren Standardmäßig optimiert Amazon MQ für Warteschlangen mit schnellen Konsumenten: + Konsumenten gelten als *schnell*, wenn sie in der Lage sind, mit der Rate der von Produzenten erstellten Nachrichten mitzuhalten. + Konsumenten gelten als *langsam*, wenn sich in der Warteschlange ein Rückstand an nicht bestätigten Nachrichten aufbaut, was möglicherweise zu einer Verringerung des Durchsatzes des Produzenten führt. Um Amazon MQ anzuweisen, für Warteschlange mit langsamen Konsumenten zu optimieren, legen Sie das Attribut `concurrentStoreAndDispatchQueues` auf `false` fest. Eine Beispielkonfiguration finden Sie unter [`concurrentStoreAndDispatchQueues`](child-element-details.md#concurrentStoreAndDispatchQueues). ## Auswählen des richtigen Broker-Instance-Typs für den besten Durchsatz Der Nachrichtendurchsatz eines [Broker-Instance-Typs](broker-instance-types.md) hängt von dem Anwendungsfall Ihrer Anwendung und den folgenden Faktoren ab: + Verwendung von ActiveMQ im persistenten Modus + Nachrichtengröße + Anzahl an Produzenten und Konsumenten + Anzahl an Zielen ### Verstehen der Beziehung zwischen Nachrichtengröße, Latenz und Durchsatz Je nach Ihrem Anwendungsfall lässt sich mit einem größeren Broker-Instance-Typ der Durchsatz möglicherweise nicht verbessern. Wenn ActiveMQ Nachrichten in einen Speicher mit hoher Beständigkeit schreibt, bestimmt die Größe Ihrer Nachrichten den begrenzenden Faktor Ihres Systems: + Wenn Ihre Nachrichten kleiner als 100 KB sind, ist die Latenz des persistenten Speichers der begrenzende Faktor. + Wenn Ihre Nachrichten größer als 100 KB sind, ist der Durchsatz des persistenten Speichers der begrenzende Faktor. Wenn Sie ActiveMQ im persistenten Modus verwenden, wird normalerweise in den Speicher geschrieben, wenn entweder weniger Konsumenten vorhanden sind oder wenn die Konsumenten langsam sind. Im nicht-persistenten Modus wird bei langsamen Konsumenten auch in den Speicher geschrieben, wenn der Heap-Speicher der Broker-Instance voll ist. Zum Bestimmen des besten Broker-Instance-Typs für Ihre Anwendung empfehlen wir, verschiedene Broker-Instance-Typen zu testen. Weitere Informationen finden Sie unter [Amazon MQ für ActiveMQ-Broker-Instance-Typen](broker-instance-types.md) sowie unter [Messen des Durchsatzes für Amazon MQ mithilfe der JMS-Benchmark](https://aws.amazon.com/blogs/compute/measuring-the-throughput-for-amazon-mq-using-the-jms-benchmark/). ### Anwendungsfälle für größere Broker-Instance-Typen Es gibt drei häufige Anwendungsfälle, wenn größere Broker-Instance-Typen den Durchsatz verbessern: + **Nicht-persistenter Modus** - Wenn Ihre Anwendung weniger empfindlich gegenüber dem Verlust von Nachrichten während eines Broker-Instance-Failovers (z. B. bei der Übertragung von Sportergebnissen) ist, können Sie oft den nicht-persistenten Modus von ActiveMQ verwenden. In diesem Modus schreibt ActiveMQ Nachrichten nur dann in einen persistenten Speicher, wenn der Heap-Speicher der Broker-Instance voll ist. Systeme, die den nicht-persistenten Modus verwenden, profitieren von der höheren Speicherkapazität, der schnelleren CPU und dem schnelleren Netzwerk, die auf größeren Broker-Instance-Typen verfügbar sind. + **Schnelle Konsumenten** - Wenn aktive Konsumenten verfügbar sind und das [`concurrentStoreAndDispatchQueues`](child-element-details.md#concurrentStoreAndDispatchQueues)-Flag aktiviert ist, erlaubt ActiveMQ den direkten Nachrichtenfluss vom Produzenten zum Konsumenten, ohne Nachrichten an den Speicher zu senden (sogar im persistenten Modus). Wenn Ihre Anwendung Nachrichten schnell abrufen kann (oder wenn Sie Ihre Konsumenten entsprechend entwerfen können), kann Ihre Anwendung von einem größeren Broker-Instance-Typ profitieren. Damit Ihre Anwendung Nachrichten schneller abrufen kann, fügen Sie zu Ihren Anwendungs-Instances Konsumenten-Threads hinzu oder skalieren Sie Ihre Anwendungs-Instances vertikal oder horizontal nach oben. + **Als Stapel verarbeitete Transaktionen** - Wenn Sie den persistenten Modus verwenden und mehrere Nachrichten pro Transaktion senden, können Sie durch Verwendung größerer Broker-Instance-Typen einen insgesamt höheren Durchsatz erzielen. Weitere Informationen finden Sie unter [Sollte ich Transaktionen verwenden?](http://activemq.apache.org/should-i-use-transactions.html) in der Apache ActiveMQ-Dokumentation. ## Auswählen des richtigen Broker-Speichertyps für den besten Durchsatz Verwenden Sie Amazon EFS, um die Vorteile der hohen Haltbarkeit und Replikation über mehrere Availability Zones hinweg zu nutzen. Verwenden Sie Amazon EBS, um die Vorteile der niedrigen Latenz und des hohen Durchsatzes zu nutzen. Weitere Informationen finden Sie unter [Amazon MQ für ActiveMQ-Speichertypen](broker-storage.md). ## Korrekte Konfiguration Ihres Netzwerk von Brokern Wenn Sie ein [Netzwerk von Brokern](network-of-brokers.md) erstellen, konfigurieren Sie es korrekt für Ihre Anwendung: + **Persistenten Modus aktivieren** - Da (im Vergleich zu seinen Mitbewerbern) jede Broker-Instance wie ein Produzent oder ein Verbraucher agiert, bieten Netzwerke von Brokern keine verteilte Replikation von Nachrichten. Der erste Broker, der als Verbraucher auftritt, erhält eine Nachricht und verbleibt im Speicher. Dieser Broker sendet eine Bestätigung an den Produzenten und leitet die Nachricht an den nächsten Broker weiter. Wenn der zweite Broker die Persistenz der Nachricht bestätigt, löscht der erste Broker die Nachricht. Wenn der persistente Modus deaktiviert ist, bestätigt der erste Broker den Produzenten, ohne die Nachricht persistent im Speicher abzulegen. Weitere Informationen finden Sie unter [Replicated Message Store](http://activemq.apache.org/replicated-message-store.html) und [What is the difference between persistent and non-persistent delivery?](http://activemq.apache.org/what-is-the-difference-between-persistent-and-non-persistent-delivery.html) in der Apache ActiveMQ-Dokumentation. + **Deaktivieren Sie Advisory Messages für Broker-Instances nicht** - Weitere Informationen finden Sie unter [Advisory Message](http://activemq.apache.org/advisory-message.html) in der Apache ActiveMQ-Dokumentation. + **Keine Multicast-Broker-Erkennung verwenden** - Amazon MQ unterstützt die Brokererkennung über Multicast nicht. Weitere Informationen finden Sie unter [What is the difference between discovery, multicast, and zeroconf?](http://activemq.apache.org/multicast-transport-reference.html) in der Apache ActiveMQ-Dokumentation. ## Vermeiden von langsamen Neustarts durch Wiederherstellung vorbereiteter XA-Transaktionen ActiveMQ unterstützt verteilte (XA-)Transaktionen. Zu wissen, wie ActiveMQ XA-Transaktionen verarbeitet, kann hilfreich sein, um langsame Wiederherstellungszeiten bei Broker-Neustarts und Failovers in Amazon MQ zu vermeiden. Nicht aufgelöste vorbereitete XA-Transaktionen werden bei jedem Neustart erneut wiedergegeben. Wenn diese weiterhin nicht aufgelöst werden, wächst ihre Anzahl mit der Zeit weiter an, was die zum Starten des Brokers benötigte Zeit erheblich erhöht. Dies wirkt sich auf die Neustart- und Failover-Zeit aus. Sie müssen diese Transaktionen mit einem `commit()` oder einem `rollback()` auflösen, damit sich die Leistung im Laufe der Zeit nicht verschlechtert. Um Ihre ungelösten vorbereiteten XA-Transaktionen zu überwachen, können Sie die `JournalFilesForFastRecovery` Metrik in Amazon CloudWatch Logs verwenden. Wenn diese Zahl ansteigt oder ständig höher als `1` ist, sollten Sie Ihre nicht aufgelösten Transaktionen mit einem Code wie in dem folgenden Beispiel wiederherstellen. Weitere Informationen finden Sie unter [Kontingente in Amazon MQ](amazon-mq-limits.md). Der folgende Beispiel-Code führt Sie durch vorbereitete XA-Transaktionen und schließt sie mit einem `rollback()` ab. ``` import org.apache.activemq.ActiveMQXAConnectionFactory; import javax.jms.XAConnection; import javax.jms.XASession; import javax.transaction.xa.XAResource; import javax.transaction.xa.Xid; public class RecoverXaTransactions { private static final ActiveMQXAConnectionFactory ACTIVE_MQ_CONNECTION_FACTORY; final static String WIRE_LEVEL_ENDPOINT = "tcp://localhost:61616";; static { final String activeMqUsername = "{{MyUsername123}}"; final String activeMqPassword = "{{MyPassword456}}"; ACTIVE_MQ_CONNECTION_FACTORY = new ActiveMQXAConnectionFactory(activeMqUsername, activeMqPassword, WIRE_LEVEL_ENDPOINT); ACTIVE_MQ_CONNECTION_FACTORY.setUserName(activeMqUsername); ACTIVE_MQ_CONNECTION_FACTORY.setPassword(activeMqPassword); } public static void main(String[] args) { try { final XAConnection connection = ACTIVE_MQ_CONNECTION_FACTORY.createXAConnection(); XASession xaSession = connection.createXASession(); XAResource xaRes = xaSession.getXAResource(); for (Xid id : xaRes.recover(XAResource.TMENDRSCAN)) { xaRes.rollback(id); } connection.close(); } catch (Exception e) { } } } ``` In einem realen Szenario können Sie Ihre vorbereiteten XA-Transaktionen mithilfe Ihres XA Transaktionsmanagers überprüfen. Anschließend können Sie entscheiden, ob die Verarbeitung der einzelnen vorbereiteten Transaktionen mit einem `rollback()` oder einem `commit()` erfolgen soll.