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 RabbitMQ

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 RabbitMQ su Amazon MQ.

Attiva gli aggiornamenti automatici delle versioni secondarie

Utilizzando l'ultima versione del broker, correzioni di bug e sicurezza e miglioramenti delle prestazioni. Puoi attivare gli aggiornamenti automatici delle versioni secondarie per Amazon MQ per gestire gli aggiornamenti alla versione patch più recente.

Utilizzo di funzionalità obsolete

Se utilizzi la versione 3.13 per RabbitMQ su Amazon MQ, vedrai un banner nell'interfaccia utente di gestione di RabbitMQ che indica: Deprecated features are being used.

Questo perché RabbitMQ su Amazon MQ utilizza le seguenti funzionalità non più offerte su RabbitMQ o sono configurate automaticamente per RabbitMQ su Amazon MQ:

Questo è un banner informativo per la versione 3.13 che non richiede alcuna azione. Il tuo broker Amazon MQ continuerà a utilizzare queste funzionalità.

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

Il throughput dei messaggi di un tipo di istanza broker dipende dal caso d'uso dell'applicazione. I tipi di istanze broker più piccoli, come ad esempio, t3.micro devono essere utilizzati solo per testare le prestazioni delle applicazioni. L'utilizzo di queste micro istanze prima di utilizzare istanze più grandi in produzione può migliorare le prestazioni delle applicazioni e aiutare a mantenere bassi i costi di sviluppo. Per i tipi di istanze m5.large e versioni successive, puoi utilizzare le distribuzioni in cluster per un'elevata disponibilità e durabilità dei messaggi. I tipi di istanze broker più grandi possono gestire livelli di produzione di client e code, velocità effettiva elevata, messaggi in memoria e messaggi ridondanti. Per maggiori informazioni sulla scelta del tipo di istanza corretto, consulta Linee guida per il dimensionamento.

Usa più canali

Per evitare interruzioni della connessione, utilizza più canali su un'unica connessione. Le applicazioni devono evitare un rapporto tra connessione e canale di 1:1. Si consiglia di utilizzare una connessione per processo e quindi un canale per thread. Evita un uso eccessivo dei canali per evitare fughe di dati.

Abilitazione code lente

Se lavori con code molto lunghe che elaborano grandi volumi di messaggi, l'attivazione di code pigre può migliorare le prestazioni del broker.

Il comportamento predefinito di RabbitMQ è quello di memorizzare nella cache i messaggi in memoria e spostarli su disco solo quando il broker ha bisogno di più memoria disponibile. Lo spostamento dei messaggi dalla memoria al disco richiede tempo e interrompe l'elaborazione dei messaggi. Le code pigre velocizzano notevolmente il processo da memoria a disco archiviando i messaggi su disco il prima possibile, con conseguente riduzione dei messaggi memorizzati nella cache.

È possibile abilitare le code lente impostando la proprietà queue.declare al momento della dichiarazione o configurando una policy tramite la console di gestione RabbitMQ. Nell'esempio seguente viene illustrata la dichiarazione di una coda lenta utilizzando la libreria client Java RabbitMQ.

Map<String, Object> args = new HashMap<String, Object>();
args.put("x-queue-mode", "lazy");
channel.queueDeclare("myqueue", false, false, false, args);

Per impostazione predefinita, tutte le code di Amazon MQ for RabbitMQ nella versione 3.12.13 e successive si comportano come code pigre. Per eseguire l'aggiornamento alla versione più recente di Amazon MQ for RabbitMQ, consulta. Aggiornamento di una versione del motore del broker Amazon MQ

Usa messaggi persistenti e code durevoli

I messaggi persistenti possono aiutare a prevenire la perdita di dati in situazioni in cui un broker si blocca o si riavvia. I messaggi persistenti vengono scritti su disco non appena arrivano. A differenza delle code lente, tuttavia, i messaggi persistenti vengono memorizzati nella cache sia nella memoria che nel disco, a meno che alil broker non occorra ulteriore memoria. Nei casi in cui è necessaria più memoria, i messaggi vengono rimossi dalla memoria dal meccanismo del broker di RabbitMQ che gestisce la memorizzazione dei messaggi su disco, comunemente indicato come livello di persistenza.

Per abilitare la persistenza dei messaggi, è possibile dichiarare le code come durable e impostare la modalità di recapito dei messaggi su persistent. Nell'esempio seguente viene illustrata la dichiarazione di una coda duratura utilizzando la libreria client Java RabbitMQ. Quando si lavora con AMQP 0-9-1, è possibile contrassegnare i messaggi come persistenti impostando la modalità di consegna «2".

boolean durable = true;
channel.queueDeclare("my_queue", durable, false, false, null);

Una volta configurata la coda come duratura, è possibile inviare un messaggio persistente alla coda impostando MessageProperties su PERSISTENT_TEXT_PLAIN come mostrato nell'esempio seguente.

import com.rabbitmq.client.MessageProperties;

channel.basicPublish("", "my_queue",
            MessageProperties.PERSISTENT_TEXT_PLAIN,
            message.getBytes());

Mantenere le code brevi

Nelle implementazioni cluster, le code con un numero elevato di messaggi possono causare un eccessivo utilizzo delle risorse. Quando un broker viene utilizzato in modo eccessivo, il riavvio di un broker Amazon MQ per RabbitMQ può causare un ulteriore peggioramento delle prestazioni. In caso di riavvio, i broker sovrasfruttati potrebbero non rispondere nello stato REBOOT_IN_PROGRESS.

Durante le finestre di manutenzione, Amazon MQ esegue tutti i lavori di manutenzione su un nodo alla volta per garantire che il broker rimanga operativo. Di conseguenza, potrebbe essere necessario sincronizzare le code quando ogni nodo riprende l'operazione. Durante la sincronizzazione, i messaggi che devono essere replicati sui mirror vengono caricati in memoria dal volume Amazon Elastic Block Store (AmazonEBS) corrispondente per essere elaborati in batch. L'elaborazione dei messaggi in batch consente alle code di sincronizzarsi più velocemente.

Se le code vengono mantenute brevi e i messaggi sono piccoli, le code si sincronizzano correttamente e riprendono l'operazione come previsto. Tuttavia, se la quantità di dati in un batch si avvicina al limite di memoria del nodo, il nodo genera un allarme di memoria elevata, sospendendo la sincronizzazione della coda. Puoi confermare l'utilizzo della memoria confrontando le metriche del nodo RabbitMemUsed e del RabbitMqMemLimit broker in. CloudWatch La sincronizzazione non può essere completata finché i messaggi non vengono consumati o eliminati o il numero di messaggi nel batch non viene ridotto.

Se la sincronizzazione della coda è sospesa per una distribuzione del cluster, si consiglia di utilizzare o eliminare i messaggi per ridurre il numero di messaggi nelle code. Una volta ridotta la profondità della coda e completata la sincronizzazione della coda, lo stato del broker diventerà RUNNING. Per risolvere una sincronizzazione della coda sospesa, è anche possibile applicare un criterio per ridurre la dimensione di batch di sincronizzazione della coda.

Puoi anche definire l'eliminazione automatica e TTL le politiche per ridurre in modo proattivo l'utilizzo delle risorse, oltre a tenere lontane le informazioni NACKs dai consumatori al minimo. La richiesta di messaggi sul broker è CPU impegnativa, quindi un numero elevato di messaggi può influire sulle prestazioni del NACKs broker.

Configurare il riconoscimento e la conferma

L'invio di una conferma di recapito e consumo di messaggi alil broker da parte di un'applicazione client è noto come conferma del consumatore. Allo stesso modo, il processo di invio di conferma a un editore è noto come conferma del mittente. Publisher conferma che consente all'applicazione di sapere quando i messaggi sono stati archiviati in modo affidabile. Senza la conferma dell'editore, il broker potrebbe continuare ad accettare messaggi anche quando la memoria sta per esaurirsi o non è in grado di elaborarli. Sia il riconoscimento che la conferma sono essenziali per garantire la sicurezza dei dati quando si lavora con i broker RabbitMQ.

La conferma di consegna dei consumatori è in genere configurata nell'applicazione client. Quando si lavora con AMQP 0-9-1, la conferma può essere abilitata configurando basic.consume o quando un messaggio viene recuperato utilizzando il metodo. basic.code AMQPI client 0-9-1 possono anche configurare le conferme dell'editore inviando il metodo. confirm.select

In genere, la conferma di consegna è abilitata in un canale. Ad esempio, quando si lavora con la libreria client Java RabbitMQ, è possibile utilizzare Channel#basicAck per impostare una semplice conferma basic.ackpositiva come mostrato nell'esempio seguente.

// this example assumes an existing channel instance

boolean autoAck = false;
channel.basicConsume(queueName, autoAck, "a-consumer-tag",
     new DefaultConsumer(channel) {
         @Override
         public void handleDelivery(String consumerTag,
                                    Envelope envelope,
                                    AMQP.BasicProperties properties,
                                    byte[] body)
             throws IOException
         {
             long deliveryTag = envelope.getDeliveryTag();
             // positively acknowledge a single delivery, the message will
             // be discarded
             channel.basicAck(deliveryTag, false);
         }
     });

Configurazione del pre-fetching

È possibile utilizzare il valore di pre-fetching di RabbitMQ per ottimizzare il modo in cui i consumatori consumano i messaggi. RabbitMQ implementa il meccanismo di pre-fetch del canale fornito da AMQP 0-9-1 applicando il conteggio di pre-fetch ai consumatori anziché ai canali. Il valore di pre-fetching viene utilizzato per specificare quanti messaggi vengono inviati al consumatore in un dato momento. Per impostazione predefinita, RabbitMQ imposta una dimensione del buffer illimitata per le applicazioni client.

Ci sono una varietà di fattori da considerare quando si imposta un conteggio pre-fetching per i consumatori RabbitMQ. Innanzitutto, l'ambiente e la configurazione dei consumatori. Poiché i consumatori devono conservare tutti i messaggi in memoria durante l'elaborazione, un valore di pre-fetching elevato può influire negativamente sulle prestazioni dei consumatori e, in alcuni casi, far causare potenzialmente a un consumatore un crash generale. Allo stesso modo, il broker RabbitMQ stesso mantiene tutti i messaggi che invia memorizzati nella cache fino a quando non riceve il riconoscimento del consumatore. Un valore di pre-fetching elevato può causare l'esaurimento della memoria del server RabbitMQ rapidamente se il riconoscimento automatico non è configurato per i consumatori e se i consumatori impiegano un tempo relativamente lungo per elaborare i messaggi.

Tenendo presente le considerazioni di cui sopra, si consiglia di impostare sempre un valore di pre-fetching per evitare situazioni in cui un broker RabbitMQ o i suoi consumatori esauriscano la memoria a causa di un numero elevato di messaggi non elaborati o non riconosciuti. Se è necessario ottimizzare i broker per elaborare grandi volumi di messaggi, è possibile testare i broker e i consumatori utilizzando una serie di conteggi pre-fetching per determinare il valore in cui il sovraccarico di rete diventa in gran parte insignificante rispetto al tempo impiegato da un consumatore per elaborare i messaggi.

L'esempio seguente dimostra l'impostazione di un valore pre-fetching di 10 per un singolo consumatore che utilizza la libreria client Java RabbitMQ.

ConnectionFactory factory = new ConnectionFactory();

Connection connection = factory.newConnection();
Channel channel = connection.createChannel();

channel.basicQos(10, false);

QueueingConsumer consumer = new QueueingConsumer(channel);
channel.basicConsume("my_queue", false, consumer);

Configurazione di Celery

Python Celery invia molti messaggi non necessari che possono rendere più difficile trovare ed elaborare le informazioni utili. Per ridurre il rumore e semplificare l'elaborazione, inserire il seguente comando:

celery -A app_name worker --without-heartbeat --without-gossip --without-mingle

Ripristino automatico da guasti di rete

Si consiglia di abilitare sempre il ripristino automatico della rete per evitare tempi di inattività significativi nei casi in cui le connessioni client ai nodi RabbitMQ non avessero esito positivo. La libreria client Java RabbitMQ supporta il ripristino automatico della rete per impostazione predefinita, a partire dalla versione 4.0.0.

Il ripristino automatico della connessione viene attivato se viene generata un'eccezione non gestita nel ciclo I/O della connessione, se viene rilevato un timeout dell'operazione di lettura socket o se il server salta un heartbeat.

Nei casi in cui la connessione iniziale tra un client e un nodo RabbitMQ non riesce, il ripristino automatico non verrà attivato. Si consiglia di scrivere il codice dell'applicazione per tenere conto degli errori di connessione iniziali riprovando la connessione. Nell'esempio seguente viene illustrato il tentativo di tentativi di errori iniziali di rete utilizzando la libreria client Java RabbitMQ.

ConnectionFactory factory = new ConnectionFactory();
// enable automatic recovery if using RabbitMQ Java client library prior to version 4.0.0.
factory.setAutomaticRecoveryEnabled(true);
// configure various connection settings

try {
  Connection conn = factory.newConnection();
} catch (java.net.ConnectException e) {
  Thread.sleep(5000);
  // apply retry logic
}

Abilitazione di Classic Queue v2 per il broker RabbitMQ

Ti consigliamo di abilitare Classic Queue v2 (CQv2) sulle versioni 3.10 e 3.11 del motore di brokeraggio per miglioramenti delle prestazioni, tra cui:

Tutte le code di Amazon MQ for RabbitMQ su 3.12.13 e versioni successive vengono utilizzate per impostazione predefinita. CQv2 Per eseguire l'aggiornamento alla versione più recente di Amazon MQ for RabbitMQ, consulta. Aggiornamento di una versione del motore del broker Amazon MQ

Migrazione da a CQv1 CQv2

Per utilizzarloCQv2, devi prima abilitare il flag della classic_mirrored_queue_version funzionalità. Per ulteriori informazioni sui flag di funzionalità, consulta Come abilitare i flag di funzionalità.

Per migrare da CQv1 aCQv2, è necessario creare un nuovo criterio di coda o modificare un criterio di coda esistente con la definizione della chiave di politica impostata queue-version su. 2 Per ulteriori informazioni sull'applicazione dei criteri, vedere. Applicazione delle politiche ad Amazon MQ for RabbitMQ Per ulteriori informazioni sull'abilitazione CQv2 con una politica di coda, consulta Classic Queues nella documentazione di RabbitMQ.

Consigliamo di seguire le nostre altre best practice in materia di prestazioni prima di iniziare la migrazione.

Se si utilizza una politica di coda, l'eliminazione della politica di coda comporterà il downgrade delle code a. CQv2 CQv1 Non è consigliabile eseguire il downgrade delle CQv2 code a CQv1 perché RabbitMQ convertirà la rappresentazione su disco della coda. Questa operazione può richiedere molto tempo e memoria per le code a elevata profondità.