Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Best practice di Amazon MQ per ActiveMQ

Usa questa sezione per individuare rapidamente le raccomandazioni per massimizzare le prestazioni e ridurre al minimo i costi della velocità effettiva; quando lavori con i broker ActiveMQ su Amazon MQ.

Non modificare né eliminare mai l'interfaccia di rete elastica Amazon MQ

Quando crei per la prima volta un broker Amazon MQ, Amazon MQ fornisce un'interfaccia di rete elastica nel Virtual Private Cloud (VPC) del tuo account e, pertanto, richiede una serie di EC2autorizzazioni. L'interfaccia di rete consente al client (produttore o consumatore) di comunicare con il broker Amazon MQ. L'interfaccia di rete è considerata rientrante nell'ambito del servizio di Amazon MQ, nonostante faccia parte del tuo accountVPC.

Usa sempre il pooling delle connessioni

In uno scenario con un singolo produttore e un singolo consumatore (ad esempio il tutorial Guida introduttiva: creazione e connessione a un broker ActiveMQ), puoi utilizzare una singola classe ActiveMQConnectionFactory per ogni produttore e consumatore. Per esempio:

// 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();

Tuttavia, in scenari più realistici con più produttori e consumatori, creare un numero elevato di connessioni per più produttori può essere costoso e inefficiente. In questi scenari, è consigliabile raggruppare più richieste del produttore utilizzando la classe PooledConnectionFactory. Per esempio:

// 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();

Usa sempre Failover Transport per la connessione a più endpoint del broker

Se è necessario che l'applicazione si connetta a più endpoint del broker, ad esempio quando si utilizza una modalità di implementazione attiva/standby o quando si esegue una migrazione da un broker di messaggistica on-premise ad Amazon MQ, usare il Trasporto del failover per consentire ai consumatori di connettersi in modo casuale a uno dei due. Per esempio:

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

Evita l'uso di selettori di messaggi

È possibile utilizzare i JMSselettori per applicare filtri agli abbonamenti agli argomenti (per indirizzare i messaggi ai consumatori in base al loro contenuto). Tuttavia, l'uso dei JMS selettori riempie il buffer di filtro del broker Amazon MQ, impedendogli di filtrare i messaggi.

In generale, non consentire ai consumatori di instradare i messaggi perché, per il disaccoppiamento ottimale di consumatori e produttori, questi devono essere entrambi temporanei.

Preferisci destinazioni virtuali ad abbonamenti durevoli

Un abbonamento durevole garantisce che il consumatore riceva tutti i messaggi pubblicati in un argomento, ad esempio, dopo il ripristino di una connessione persa. Tuttavia, l'uso di abbonamenti durevoli preclude anche l'uso di consumatori concorrenti e può causare problemi di prestazioni su scala. Valuta se utilizzare invece destinazioni virtuali.

Se utilizzi Amazon VPC peering, evita il client IPs nell'intervallo CIDR 10.0.0.0/16

Se stai configurando Amazon VPC peering tra l'infrastruttura locale e il tuo broker Amazon MQ, non devi configurare connessioni client entro un intervallo. IPs CIDR 10.0.0.0/16

Disabilita archiviazione e invio simultaneo per code con consumatori lenti

Per impostazione predefinita, Amazon MQ è ottimizzato per code con consumatori veloci:

Per richiedere ad Amazon MQ di ottimizzare le code con consumatori lenti, impostare l'attributo concurrentStoreAndDispatchQueues su false. Per un esempio di configurazione, consulta concurrentStoreAndDispatchQueues.

Scegli il tipo di istanza broker corretta per il miglior throughput

Il throughput dei messaggi di un tipo di istanza broker dipende dal caso d'uso dell'applicazione e dai seguenti fattori:

Comprensione della relazione tra dimensione dei messaggi, latenza e velocità effettiva

A seconda del caso d'uso, un tipo di istanza broker più grande potrebbe non necessariamente migliorare il throughput del sistema. Quando ActiveMQ scrive messaggi in uno storage durevole, le dimensioni dei messaggi determinano il fattore di limitazione del sistema:

Quando utilizzi ActiveMQ in modalità persistente, la scrittura nello storage avviene normalmente quando ci sono pochi consumatori o quando i consumatori sono lenti. In modalità non persistente, la scrittura nello storage avviene anche con consumatori lenti se la memoria heap dell'istanza broker è piena.

Per determinare il miglior tipo di istanza broker per l'applicazione, ti consigliamo di testare tipi di istanza broker diversi. Per ulteriori informazioni, consulta Broker instance types e anche Misurazione del throughput per Amazon MQ utilizzando il JMS benchmark.

Casi d'uso per tipi di istanza del broker più grandi

Vi sono tre casi d'uso comune quando tipi di istanza broker più grandi migliorano il throughput:

Scegli il tipo di archiviazione del broker corretto per il miglior throughput

Per sfruttare l'elevata durabilità e la replica su più zone di disponibilità, usa AmazonEFS. Per sfruttare la bassa latenza e l'elevato throughput, usa Amazon. EBS Per ulteriori informazioni, consulta Storage.

Configura la rete di broker nel modo corretto

Quando crei una rete di broker, configurala correttamente per l'applicazione:

Evita riavvi lenti ripristinando transazioni XA preparate

ActiveMQ supporta transazioni distribuite (XA). Sapere in che modo ActiveMQ elabora le transazioni XA può evitare lenti tempi di ripristino per riavvii broker e failover del broker in Amazon MQ

Transazioni XA preparate non risolte vengono riprodotte a ogni riavvio. Se queste rimangono non risolte, il loro numero crescerà nel tempo, aumentando in modo significativo il tempo necessario per avviare il broker. Questo influisce sul tempo di riavvio e di failover. Occorre risolvere queste transazioni con un commit() o un rollback() per evitare il degrado delle prestazioni nel tempo.

Per monitorare le transazioni XA preparate non risolte, puoi utilizzare la JournalFilesForFastRecovery metrica in Amazon Logs. CloudWatch Se questo numero aumenta o è costantemente maggiore di 1, è opportuno recuperare le transazioni non risolte con un codice simile a quello dell'esempio seguente. Per ulteriori informazioni, consulta Quotas in Amazon MQ.

Il codice di esempio seguente descrive in dettaglio le transazioni XA preparate e le chiude con un rollback().

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 uno scenario reale, puoi controllare le transizioni XA preparate rispetto al sistema di gestione delle transazioni XA. Puoi quindi decidere se gestire ogni transazione preparata con un rollback() o un commit().