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, stellt Amazon MQ eine elastic network interface in der Virtual Private Cloud (VPC) unter Ihrem Konto bereit und benötigt daher eine Reihe von EC2 Berechtigungen. Die Netzwerkschnittstelle gestattet Ihrem Client (Erzeuger oder Verbraucher), mit dem Amazon MQ-Broker zu kommunizieren. Es wird davon ausgegangen, dass die Netzwerkschnittstelle zum Serviceumfang von Amazon MQ gehört, obwohl sie Teil Ihres Kontos istVPC.

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-Tutorial) können Sie eine einzige ActiveMQConnectionFactory-Klasse für jeden Produzenten und Konsumenten verwenden. Beispielsweise:

// 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 PooledConnectionFactory-Klasse gruppieren. Beispielsweise:

// 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 oder wenn Sie von einem lokalen Message Broker auf Amazon MQ migrieren –, verwenden Sie den Failover-Transport, um Ihren Konsumenten zu ermöglichen, eine Verbindung zu einem beliebigen dieser Endpunkte herzustellen. Beispielsweise:

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-east-2.amazonaws.com:61617)?randomize=true

Vermeiden Sie die Nachrichtenauswahl

Es ist möglich, mithilfe von JMSSelektoren Filter an Themenabonnements anzuhängen (um Nachrichten anhand ihres Inhalts an Verbraucher weiterzuleiten). Die Verwendung von JMS Selektoren füllt jedoch den Filterpuffer des Amazon MQ-Brokers und verhindert so, dass Nachrichten gefiltert werden.

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 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 in Betracht.

Wenn Sie Amazon VPC Peering verwenden, vermeiden Sie den Client IPs in Reichweite CIDR 10.0.0.0/16

Wenn Sie VPC Amazon-Peering zwischen der lokalen Infrastruktur und Ihrem Amazon MQ-Broker einrichten, dürfen Sie keine Client-Verbindungen mit IPs In-Range konfigurieren. CIDR 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:

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.

Auswählen des richtigen Broker-Instance-Typs für den besten Durchsatz

Der Nachrichtendurchsatz eines Broker-Instance-Typs hängt von dem Anwendungsfall Ihrer Anwendung und den folgenden Faktoren ab:

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 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 Broker instance types und auch Messung des Durchsatzes für Amazon MQ mithilfe des JMS Benchmarks.

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:

Auswählen des richtigen Broker-Speichertyps für den besten Durchsatz

Verwenden Sie Amazon, um die Vorteile der hohen Haltbarkeit und Replikation über mehrere Availability Zones hinweg zu nutzenEFS. Verwenden Sie Amazon, um von niedriger Latenz und hohem Durchsatz zu profitierenEBS. Weitere Informationen finden Sie unter Storage.

Korrekte Konfiguration Ihres Netzwerk von Brokern

Wenn Sie ein Netzwerk von Brokern erstellen, konfigurieren Sie es korrekt für Ihre Anwendung:

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 Quotas in Amazon MQ.

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.