Le migliori pratiche per la durabilità e l'affidabilità dei messaggi in Amazon MQ for RabbitMQ

Prima di passare all'applicazione in produzione, seguite le seguenti procedure consigliate per prevenire la perdita di messaggi e l'eccessivo utilizzo delle risorse.

Fase 1: Usare 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());

Passaggio 2: configura le conferme dell'editore e la conferma di consegna al consumatore

Il processo di conferma dell'invio di un messaggio al broker è noto come conferma dell'editore. Le conferme di Publisher consentono all'applicazione di sapere quando i messaggi sono stati archiviati in modo affidabile. Le conferme di Publisher possono anche aiutare a controllare la frequenza dei messaggi archiviati nel broker. Senza le conferme dell'editore, non vi è alcuna conferma che un messaggio sia stato elaborato correttamente e il broker potrebbe eliminare i messaggi che non è in grado di elaborare.

Analogamente, quando un'applicazione client invia al broker la conferma della consegna e del consumo dei messaggi, si parla di conferma della consegna da parte del consumatore. Sia la conferma che il riconoscimento 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 il metodo. basic.consume I client AMQP 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);
         }
     });

Nota

I messaggi non riconosciuti devono essere memorizzati nella cache in memoria. È possibile limitare il numero di messaggi che un consumer pre-recupera mediante la configurazione delle impostazioni pre-fetch per un'applicazione client.

È possibile configurare in modo consumer_timeout da rilevare quando i consumatori non confermano le consegne. Se il consumatore non invia una conferma entro il valore di timeout, il canale verrà chiuso e riceverai un. PRECONDITION_FAILED Per diagnosticare l'errore, utilizza l'UpdateConfigurationAPI per aumentare il valore. consumer_timeout

Fase 3: Mantieni 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 nei mirror vengono caricati in memoria dal volume Amazon Elastic Block Store (Amazon EBS) 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 del RabbitMemUsedRabbitMqMemLimit broker con quelle del nodo 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 politiche di eliminazione automatica e TTL per ridurre in modo proattivo l'utilizzo delle risorse e per evitare NACKs che i consumatori entrino in contatto con i consumatori al minimo. La richiesta di messaggi sul broker richiede un uso intensivo della CPU, quindi un numero elevato di messaggi può influire sulle prestazioni del broker. NACKs