Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Prácticas recomendadas para la durabilidad y confiabilidad de los mensajes en Amazon MQ para RabbitMQ

Antes de pasar la aplicación a producción, siga las siguientes prácticas recomendadas para evitar la pérdida de mensajes y la sobreutilización de los recursos.

Paso 1: Utilice mensajes persistentes y colas duraderas

Los mensajes persistentes pueden ayudar a evitar la pérdida de datos en situaciones en las que un agente se bloquea o se reinicia. Los mensajes persistentes se escriben en el disco tan pronto como llegan. Sin embargo, a diferencia de las colas perezosas, los mensajes persistentes se almacenan tanto en la memoria caché como en el disco, a menos que el agente necesite más memoria. En los casos en que se necesita más memoria, los mensajes se eliminan de la memoria mediante el mecanismo del agente de RabbitMQ que administra el almacenamiento de mensajes en el disco, comúnmente conocido como capa de persistencia.

Para habilitar la persistencia de mensajes, puede declarar las colas como durable y establecer el modo de entrega de mensajes en persistent. En el siguiente ejemplo, se muestra el uso de la biblioteca de cliente Java de RabbitMQ para declarar una cola duradera. Al trabajar con el AMQP 0-9-1, puede marcar los mensajes como persistentes configurando el modo de entrega como “2”.

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

Una vez que haya configurado la cola como duradera, puede enviar un mensaje persistente a la cola estableciendo MessageProperties en PERSISTENT_TEXT_PLAIN, como se muestra en el siguiente ejemplo.

import com.rabbitmq.client.MessageProperties;

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

Paso 2: Configurar las confirmaciones del editor y el acuse de recibo de entrega al consumidor

Se denomina confirmación del publicador al proceso de confirmar que se ha enviado un mensaje al agente. Las confirmaciones del publicador permiten a la aplicación saber que los mensajes se han almacenado de forma fiable. También pueden ayudar a controlar el ritmo de los mensajes almacenados en el agente. Sin la confirmación del editor, no hay confirmación de que un mensaje se haya procesado correctamente y su agente puede descartar los mensajes que no pueda procesar.

Del mismo modo, cuando una aplicación cliente envía confirmación de entrega y consumo de mensajes de vuelta al agente, se conoce como acuse de recibo del consumidor. Tanto la confirmación como el acuse de recibo son esenciales para garantizar la seguridad de los datos cuando se trabaja con agentes de RabbitMQ.

El acuse de recibo de entrega del consumidor suele configurarse en la aplicación cliente. Cuando se trabaja con AMQP 0-9-1, el acuse de recibo se puede habilitar configurando el método basic.consume. Los clientes de AMQP 0-9-1 también pueden configurar las confirmaciones del publicador mediante el envío del método confirm.select.

Normalmente, el acuse de recibo de entrega se habilita en un canal. Por ejemplo, cuando se trabaja con la biblioteca de cliente Java de RabbitMQ, se puede utilizar Channel#basicAck para configurar un acuse de recibo positivo basic.ack, como se muestra en el siguiente ejemplo.

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

Puede configurar consumer_timeout para detectar cuándo los consumidores no confirman las entregas. Si el consumidor no envía un acuse de recibo dentro del tiempo de espera, el canal se cerrará y recibirá un PRECONDITION_FAILED. Para diagnosticar el error, utilice la UpdateConfigurationAPI para aumentar el consumer_timeout valor.

Paso 3: Mantenga las colas cortas

En las implementaciones de clúster, las colas con un gran número de mensajes pueden provocar una sobreutilización de recursos. Cuando un agente está sobreutilizado, el reinicio de un agente de Amazon MQ para RabbitMQ puede degradar aún más el rendimiento. Si se reinicia, los agentes sobreutilizados podrían dejar de responder en el estado REBOOT_IN_PROGRESS.

Durante los períodos de mantenimiento, Amazon MQ realiza todos los trabajos de mantenimiento de a un nodo por vez para garantizar que el agente permanezca operativo. Como resultado, es posible que las colas deban sincronizarse a medida que cada se vaya reanudando la operación de cada nodo. Durante la sincronización, los mensajes que deben replicarse en los espejos se cargan en la memoria del volumen correspondiente de Amazon Elastic Block Store (Amazon EBS) para procesarlos en lotes. El procesamiento de mensajes en lotes permite agilizar la sincronización de las colas.

Si las colas se mantienen cortas y los mensajes son pequeños, las colas se sincronizan correctamente y reanudan la operación según lo previsto. Sin embargo, si la cantidad de datos de un lote se acerca al límite de memoria del nodo, el nodo genera una alarma de memoria elevada y se pausa la sincronización de colas. Puede confirmar el uso de la memoria comparando las métricas del nodo RabbitMqMemLimit intermediario con RabbitMemUsed las del nodo intermediario. CloudWatch La sincronización no se puede completar hasta que se consuman o eliminen los mensajes, o se reduzca el número de mensajes del lote.

Si la sincronización de colas está en pausa por una implementación de clúster, recomendamos consumir o eliminar mensajes para reducir el número de mensajes en las colas. Una vez que se reduzca la profundidad de la cola y se complete su sincronización, el estado del agente cambiará a RUNNING. Para resolver una sincronización de cola en pausa, también puede aplicar una política para reducir el tamaño del lote de sincronización de colas.

También puedes definir políticas de eliminación automática y TTL para reducir de forma proactiva el uso de recursos y NACKs evitar que los consumidores lo hagan al mínimo. Poner los mensajes en cola en el bróker requiere un uso intensivo de la CPU, por lo que un número elevado de ellos puede afectar al rendimiento del bróker. NACKs