Prácticas recomendadas de Amazon MQ para RabbitMQ

Utilice esta sección como referencia para encontrar rápidamente recomendaciones que le permitan maximizar el rendimiento y minimizar los costos al usar agentes de RabbitMQ en Amazon MQ.

importante

Actualmente, Amazon MQ no admite transmisiones ni utiliza el inicio de sesión estructuradoJSON, introducido en RabbitMQ 3.9.x.

importante

Amazon MQ para RabbitMQ no admite el nombre de usuario «guest» y eliminará la cuenta de invitado predeterminada cuando cree un nuevo agente. Amazon MQ también eliminará periódicamente cualquier cuenta creada por el cliente denominada «guest».

Active las actualizaciones automáticas de las versiones secundarias

Utiliza la última versión del broker, corrige errores y mejora el rendimiento. Puedes activar las actualizaciones automáticas de las versiones secundarias de Amazon MQ para gestionar las actualizaciones a la última versión del parche.

Uso de funciones obsoletas

Si utilizas la versión 3.13 para RabbitMQ en Amazon MQ, verás un banner en la interfaz de usuario de administración de RabbitMQ que dice: Deprecated features are being used.

Esto se debe a que RabbitMQ en Amazon MQ utiliza las siguientes funciones que ya no se ofrecen en RabbitMQ o que se configuran automáticamente para RabbitMQ en Amazon MQ:

• Duplicación clásica de colas

• QoS global

• Colas transitorias no exclusivas

Este es un banner informativo para la versión 3.13 que no requiere ninguna acción. Su agente de Amazon MQ seguirá utilizando estas funciones.

Elija el tipo de instancia de bróker correcto para obtener el mejor rendimiento

El rendimiento de los mensajes de un tipo de instancia de intermediario depende del caso de uso de la aplicación. Los tipos de instancias de broker más pequeñas, como, por ejemplo, solo t3.micro deberían usarse para probar el rendimiento de las aplicaciones. El uso de estas microinstancias antes de utilizar instancias más grandes en producción puede mejorar el rendimiento de las aplicaciones y ayudarle a mantener bajos los costes de desarrollo. En los tipos de instancias m5.large y superiores, puede usar implementaciones en clúster para obtener una alta disponibilidad y durabilidad de los mensajes. Los tipos de instancias de broker más grandes pueden gestionar los niveles de producción de clientes y colas, el alto rendimiento, los mensajes en memoria y los mensajes redundantes. Para obtener más información sobre cómo elegir el tipo de instancia correcto, consulta las pautas de tamaño.

Usa varios canales

Para evitar la pérdida de conexiones, usa varios canales en una sola conexión. Las aplicaciones deben evitar una relación de conexión a canal de 1:1. Recomendamos utilizar una conexión por proceso y, a continuación, un canal por hilo. Evite el uso excesivo de los canales para evitar fugas en los canales.

Habilitar colas perezosas

Si trabaja con colas muy largas que procesan grandes volúmenes de mensajes, habilitar las colas diferidas puede mejorar el rendimiento del bróker.

El comportamiento predeterminado de RabbitMQ es almacenar los mensajes en memoria caché y moverlos al disco solo cuando el agente necesita más memoria disponible. Mover los mensajes de la memoria al disco lleva tiempo y detiene el procesamiento de los mensajes. Las colas diferidas aceleran considerablemente el proceso de transferencia de memoria a disco, ya que almacenan los mensajes en el disco lo antes posible, lo que reduce el número de mensajes almacenados en caché en la memoria.

Para habilitar las colas perezosas, puede configurar los argumentos queue.declare en el momento de la instrucción o configurar una política a través de la consola de administración de RabbitMQ. En el siguiente ejemplo, se muestra la declaración de una cola perezosa mediante la biblioteca de cliente Java de RabbitMQ.

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

Todas las colas de Amazon MQ para RabbitMQ de la versión 3.12.13 y versiones posteriores se comportan como colas diferidas de forma predeterminada. Para actualizar a la versión más reciente de Amazon MQ para RabbitMQ, consulte. Actualización de una versión del motor del agente de Amazon MQ

nota

Habilitar colas perezosas puede aumentar las operaciones de E/S en el disco.

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. Cuando trabajes con el AMQP 0-9-1, puedes 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());

Mantener 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 periodos 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 réplicas se cargan en la memoria desde el volumen correspondiente de Amazon Elastic Block Store (AmazonEBS) 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 intermediario con RabbitMemUsed las del nodo RabbitMqMemLimit 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 la eliminación automática y TTL políticas para reducir de forma proactiva el uso de recursos, así como NACKs evitar que los consumidores lo hagan al mínimo. Poner los mensajes en cola en el bróker es muy CPU intensivo, por lo que un número elevado de ellos puede afectar al rendimiento del bróker. NACKs

Configurar reconocimiento y confirmación

Cuando una aplicación cliente envía confirmación de entrega y consumo de mensajes de vuelta al gente, se conoce como acuse de recibo del consumidor. Del mismo modo, el proceso de envío de confirmación a un publicador se conoce como confirmación del publicador. Publisher confirma que su aplicación sepa si los mensajes se han almacenado de forma fiable. Sin la confirmación del editor, es posible que su agente siga aceptando mensajes incluso cuando se esté quedando sin memoria o no pueda procesarlos. Tanto el acuse de recibo como la confirmación 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 el AMQP 0-9-1, la confirmación se puede activar configurando el método basic.consume o cuando se obtiene un mensaje mediante este método. basic.code AMQPLos clientes 0-9-1 también pueden configurar las confirmaciones del editor enviando el 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);
         }
     });

nota

Los mensajes sin confirmar se deben almacenar en la memoria caché. Para limitar el número de mensajes que un consumidor captura previamente, puede establecer el parámetro Pre-fetch (Captura previa) para una aplicación cliente.

Configurar la captura previa

Puede utilizar el valor de captura previa de RabbitMQ para optimizar la forma en que los consumidores consumen los mensajes. RabbitMQ implementa el mecanismo de búsqueda previa de canales proporcionado por AMQP 0-9-1 al aplicar el recuento previo a los consumidores y no a los canales. El valor de captura previa se utiliza para especificar cuántos mensajes se envían al consumidor en un momento dado. De forma predeterminada, RabbitMQ establece un tamaño de búfer ilimitado para las aplicaciones cliente.

Hay varios factores a tener en cuenta al establecer un recuento de captura previa para los consumidores de RabbitMQ. Primero, considere el entorno y la configuración de los consumidores. Debido a que los consumidores necesitan mantener todos los mensajes en la memoria mientras se procesan, un alto valor de captura previa puede tener un impacto negativo en el rendimiento de los consumidores y, en algunos casos, puede provocar el bloqueo de todos los consumidores juntos. Del mismo modo, el propio agente de RabbitMQ guarda todos los mensajes que envía en la memoria caché hasta que recibe el acuse de recibo del consumidor. Un alto valor de captura previa puede hacer que el servidor de RabbitMQ se quede sin memoria rápidamente si el reconocimiento automático no está configurado para los consumidores y si los consumidores tardan un tiempo relativamente largo en procesar mensajes.

Teniendo en cuenta las consideraciones anteriores, recomendamos establecer siempre un valor de captura previa para evitar situaciones en las que un agente de RabbitMQ o sus consumidores se queden sin memoria debido a un gran número de mensajes sin procesar o sin reconocer. Si necesita optimizar sus agentes para que procesen grandes volúmenes de mensajes, puede probarlos junto con los consumidores utilizando un intervalo de recuentos de captura previa para determinar el valor en el que la sobrecarga de red se vuelve en gran medida insignificante en comparación con el tiempo que tarda un consumidor en procesar mensajes.

nota

• Si las aplicaciones cliente se han configurado para confirmar automáticamente la entrega de mensajes a los consumidores, no servirá de nada establecer un valor de captura previa.

• Todos los mensajes que capturados previamente se eliminan de la cola.

En el siguiente ejemplo, se muestra cómo establecer un valor de captura previa de 10 para un solo consumidor utilizando la biblioteca de clientes Java de 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);

nota

En la biblioteca de clientes Java de RabbitMQ, el valor predeterminado para el indicador global se establece en false, por lo que el ejemplo anterior se puede escribir simplemente como channel.basicQos(10).

Configuración de Celery

Python Celery envía muchos mensajes innecesarios que pueden dificultar la búsqueda y el procesamiento de la información útil. Para reducir el ruido y facilitar el procesamiento, ingrese el siguiente comando:

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

Recuperación automática de fallas de red

Se recomienda habilitar siempre la recuperación automática de red para evitar un tiempo de inactividad significativo en caso de falla de las conexiones del cliente con los nodos de RabbitMQ. La biblioteca de cliente Java de RabbitMQ admite la recuperación automática de red de forma predeterminada, a partir de la versión 4.0.0.

La recuperación automática de la conexión se activa si se produce una excepción no controlada en el bucle de E/S de la conexión, si se detecta un tiempo de espera de la operación de lectura de socket o si el servidor pierde un latido.

En caso de falla en la conexión inicial entre un cliente y un nodo de RabbitMQ, no se activará la recuperación automática. Recomendamos escribir el código de la aplicación para tener en cuenta los errores de conexión iniciales al volver a intentar la conexión. En el siguiente ejemplo, se muestran fallas al reintentar iniciar la red mediante la biblioteca de cliente Java de 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
}

nota

Si una aplicación cierra una conexión con el método Connection.Close, la recuperación automática de red no se activará ni se disparará.

Active Classic Queue v2 para su agente de RabbitMQ

Recomendamos activar Classic Queue v2 (CQv2) en las versiones 3.10 y 3.11 de Broker Engine para mejorar el rendimiento, entre las que se incluyen:

• Disminuya el uso de memoria

• Mejorar la entrega a los consumidores

• Aumentar el rendimiento de las cargas de trabajo para que los consumidores estén a la altura de los productores

Todas las colas de Amazon MQ para RabbitMQ del 3.12.13 y versiones posteriores se utilizan de forma predeterminada. CQv2 Para actualizar a la versión más reciente de Amazon MQ para RabbitMQ, consulte. Actualización de una versión del motor del agente de Amazon MQ

Migración de a CQv1 CQv2

Para usarloCQv2, primero debe habilitar el indicador de classic_mirrored_queue_version función. Para obtener más información sobre los indicadores de características, consulte Cómo habilitar los indicadores de características.

Para migrar de CQv1 aCQv2, debe crear una nueva política de colas o editar una política de colas existente con la definición clave de la queue-version política establecida en. 2 Para obtener más información sobre la aplicación de políticas, consulte. Aplicación de políticas a Amazon MQ para RabbitMQ Para obtener más información sobre cómo habilitar CQv2 una política de colas, consulte Colas clásicas en la documentación de RabbitMQ.

Recomendamos seguir nuestras otras prácticas recomendadas de rendimiento antes de iniciar la migración.

Si utilizas una política de colas, si eliminas la política de colas, las colas volverán a ser. CQv2 CQv1 No recomendamos bajar las CQv2 colas a otra, CQv1 ya que RabbitMQ convertirá la representación en disco de la cola. Esto puede consumir mucha memoria y llevar mucho tiempo si las colas son muy profundas.