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à.
Le migliori pratiche per la configurazione del broker e la gestione delle connessioni in Amazon MQ for RabbitMQ
La configurazione del broker e la gestione delle connessioni sono il primo passo per prevenire problemi relativi alla velocità di trasmissione dei messaggi del broker, all'utilizzo delle risorse e alla capacità di gestire i carichi di lavoro di produzione. Quando crei e configuri un broker Amazon MQ for RabbitMQ, segui le seguenti best practice per selezionare i tipi di istanza appropriati, gestire le connessioni in modo efficiente e configurare la prelettura dei messaggi per massimizzare le prestazioni del broker.
Importante
Amazon MQ for RabbitMQ non supporta il nome utente «guest» ed eliminerà l'account ospite predefinito quando crei un nuovo broker. Amazon MQ eliminerà inoltre periodicamente qualsiasi account creato dal cliente chiamato «ospite».
Fase 1: utilizza le distribuzioni in cluster
Per i carichi di lavoro di produzione, consigliamo di utilizzare distribuzioni in cluster anziché broker a istanza singola per garantire un'elevata disponibilità e resilienza dei messaggi. Le implementazioni in cluster eliminano i singoli punti di errore e offrono una migliore tolleranza agli errori.
Le implementazioni dei cluster consistono in tre nodi broker RabbitMQ distribuiti su tre zone di disponibilità, che forniscono il failover automatico e garantiscono la continuità delle operazioni anche se un'intera zona di disponibilità non è disponibile. Amazon MQ replica automaticamente i messaggi su tutti i nodi per garantire la disponibilità durante i guasti o la manutenzione dei nodi.
Le implementazioni in cluster sono essenziali per gli ambienti di produzione e sono supportate dal Service Level Agreement di Amazon MQ
Per ulteriori informazioni, consulta la sezione Distribuzione di cluster in Amazon MQ for RabbitMQ.
Passaggio 2: scegli il tipo di istanza del broker corretto
La velocità effettiva dei messaggi di un tipo di istanza del broker dipende dal caso d'uso dell'applicazione. M7g.medium
deve essere utilizzato solo per testare le prestazioni dell'applicazione. L'utilizzo di questa istanza più piccola prima di utilizzare istanze più grandi in produzione può migliorare le prestazioni delle applicazioni. Sui tipi di istanze m7g.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 ulteriori informazioni sulla scelta del tipo di istanza corretto, consulta le linee guida sul dimensionamento in Amazon MQ for RabbitMQ.
Passaggio 3: utilizza le code per il quorum
Le code quorum, con distribuzione in cluster, dovrebbero essere la scelta predefinita per i tipi di coda replicati negli ambienti di produzione per i broker RabbitMQ a partire dalla versione 3.13. Le code quorum sono un tipo di coda replicato moderno che offre elevata affidabilità, velocità effettiva elevata e latenza stabile.
Le code quorum utilizzano l'algoritmo di consenso Raft per fornire una migliore tolleranza agli errori. Quando il nodo leader non è più disponibile, le code quorum eleggono automaticamente un nuovo leader a maggioranza, assicurando che la consegna dei messaggi continui con interruzioni minime. Poiché ogni nodo si trova in una zona di disponibilità diversa, il sistema di messaggistica rimane disponibile anche se un'intera zona di disponibilità diventa temporaneamente non disponibile.
Per dichiarare una coda di quorum, imposta l'intestazione x-queue-type
su quando crei le code. quorum
Per ulteriori informazioni sulle code quorum, incluse le strategie di migrazione e le best practice, consulta Quorum queues in Amazon MQ for RabbitMQ.
Passaggio 4: utilizza più canali
Per evitare interruzioni della connessione, utilizza più canali su una singola connessione. Le applicazioni devono evitare un rapporto tra connessione e canale di 1:1. Si consiglia di utilizzare una connessione per ogni processo e quindi un canale per ogni thread. Evita un uso eccessivo dei canali per evitare fughe di dati.