RabbitMQ 4

AMQP 1.0 como protocolo principal: para obtener más información, consulte Protocolos.

Palas locales: las palas ahora admiten un nuevo protocolo denominado «local», además de los protocolos AMQP 0-9-1 y AMQP 1.0. Las palas locales se basan internamente en el AMQP 1.0, pero en lugar de utilizar conexiones TCP independientes, utilizan conexiones internas entre los nodos del clúster e internas para publicar y consumir mensajes. APIs Esto solo se puede usar para consumir y publicar dentro del mismo clúster y puede ofrecer un mayor rendimiento y utilizar menos recursos que el AMQP 0-9-1 y el AMQP 1.0.

Las colas de quórum respaldan las prioridades de los mensajes: las prioridades de los mensajes de las colas de quórum están siempre activas y no requieren una política para funcionar. Tan pronto como una cola de quórum reciba un mensaje con una prioridad establecida, se habilitará la priorización. Las colas de quórum internamente solo admiten dos prioridades: alta y normal. Los mensajes sin un conjunto de prioridades se asignarán a la normalidad, al igual que las prioridades 0 a 4. Los mensajes con una prioridad superior a 4 se asignarán a alta. Los mensajes de alta prioridad se preferirán a los mensajes de prioridad normal en una proporción de 2:1, es decir, por cada 2 mensajes de alta prioridad, la cola entregará 1 mensaje de prioridad normal (si está disponible). Por lo tanto, las colas de quórum implementan un tipo de procesamiento prioritario no estricto y de «reparto equitativo». Esto garantiza que siempre se avance en los mensajes prioritarios normales, pero se prefieren los más prioritarios en una proporción de 2:1.

Khepri: Khepri se utiliza como almacén de metadatos predeterminado para los corredores de RabbitMQ 4

TLS mutuo (mTLS): Amazon MQ admite el TLS mutuo (mTLS) para los corredores de RabbitMQ, lo que permite a los clientes autenticarse mediante certificados. Para obtener más información, consulte Configuración de mTLS.

Complemento de autenticación con certificado SSL: el complemento de autenticación SSL utiliza certificados de cliente de las conexiones mTLS para autenticar a los usuarios, lo que permite la autenticación mediante certificados de cliente X.509 en lugar de credenciales de nombre de usuario y contraseña. Para obtener más información, consulte Autenticación con certificados SSL.

Complemento de autenticación HTTP: el complemento backend de autenticación HTTP permite delegar la autenticación y la autorización a un servicio HTTP externo. Para obtener más información, consulta Autenticación y autorización HTTP.

Duplicación de las colas clásicas: las colas clásicas siguen siendo compatibles sin cambios importantes en las bibliotecas y aplicaciones de los clientes, pero ahora son del tipo de cola no replicada. Los clientes podrán conectarse a cualquier nodo para publicar y consumir contenido de cualquier cola clásica no replicada. Se recomiendan las colas de quórum para garantizar la replicación y la seguridad de los datos.

Eliminación de la QoS global: se recomienda a los clientes configurar la QoS por consumidor (no global) en lugar de la QoS global, en la que se utiliza una única captura previa compartida para todo el canal.

Support para colas transitorias y no exclusivas: las colas transitorias son colas cuya vida útil está vinculada al tiempo de actividad del nodo en el que se declaran. En un broker de instancia única, se eliminan cuando se reinicia el nodo. En una implementación de clúster, se eliminan cuando se reinicia el nodo en el que están alojados. Recomendamos utilizar el TTL de cola para eliminar automáticamente las colas inactivas y no utilizadas tras un tiempo de inactividad. Las colas exclusivas siguen siendo compatibles y se eliminan una vez que se han eliminado todas las conexiones a la cola.

Tipo de cola predeterminado: el tipo de cola predeterminado en un bróker de RabbitMQ 4 es quórum. Si no se especifica ningún argumento de tipo de cola durante la creación de la cola, se creará una cola de quórum.

El límite de reenvío predeterminado en las colas de quórum está establecido en 20: los mensajes que se reenvíen 20 veces o más se incluirán en letra muerta o se eliminarán (se eliminarán). Si lo habitual en una cola es que haya 20 entregas por mensaje, es necesario configurar un objetivo fijo o un límite superior para dichas colas a fin de evitar la pérdida de datos. La forma recomendada de hacerlo es mediante una política.

amqplib: Las versiones amqplib del cliente Node JS anteriores a la 0.10.7 o cualquier biblioteca cliente de AMQP que utilice frame_max < 8192 no podrán conectarse a RabbitMQ

Límites de recursos predeterminados: Amazon MQ para RabbitMQ ha introducido límites de uso de recursos predeterminados para las conexiones, los canales, los consumidores por canal, las colas, los vhosts, las palas, los intercambios y el tamaño máximo de los mensajes. Sirven como barreras para proteger la disponibilidad de los corredores y se pueden personalizar mediante configuraciones que se adapten a sus requisitos específicos.

Intercambios aleatorios locales: Amazon MQ no admite los intercambios aleatorios locales, ya que los nodos de Amazon MQ están detrás de un balanceador de carga de red.

Interceptor de mensajes: los interceptores de mensajes RabbitMQ no son compatibles con Amazon MQ.

Métricas por cola: Amazon MQ no venderá las métricas de colas de RabbitMQ para los corredores de RabbitMQ 4 a través de ellas. AWS CloudWatch Amazon MQ seguirá proporcionando métricas a nivel de corredor. AWS CloudWatch Puede consultar las métricas de colas mediante la API de administración de RabbitMQ. Recomendamos consultar las métricas de colas específicas con una frecuencia de un minuto o más.