RabbitMQ 4.2

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

Palas locales: las palas ahora admiten un nuevo protocolo llamado «local», además de AMQP 0-9-1 y AMQP 1.0. Las palas locales se basan internamente en AMQP 1.0, pero en lugar de utilizar conexiones TCP independientes, utilizan conexiones dentro del clúster entre los nodos del clúster y las API internas para publicar y consumir mensajes. Solo se pueden usar para consumir y publicar en el mismo clúster y, al mismo tiempo, ofrecen un mayor rendimiento y utilizan menos recursos que los AMQP 0-9-1 y AMQP 1.0.

Las colas de quórum admiten las prioridades de los mensajes: las prioridades de los mensajes de la cola de quórum siempre están activas y no requieren una política. Cuando una cola de quórum recibe un mensaje con una prioridad establecida, habilita la priorización. Las colas de quórum solo admiten dos niveles de prioridad internos: alto y normal.

RabbitMQasigna los mensajes sin prioridad y los mensajes con prioridades de 0 a 4 a normales. Los mensajes con una prioridad superior a 4 se asignan a alta. High-priority los mensajes se prefieren a los mensajes de prioridad normal en una proporción de 2:1. Por cada 2 mensajes de alta prioridad, la cola entrega 1 mensaje de prioridad normal, si hay alguno disponible. Como resultado, las colas de quórum implementan un modelo de procesamiento de prioridades equitativo y no estricto que garantiza el progreso de los mensajes de prioridad normal.

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

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

Complemento de autenticación mediante certificados SSL: el complemento de autenticación SSL utiliza certificados de cliente de conexiones mTLS para autenticar a los usuarios, lo que permite la autenticación mediante certificados de X.509 cliente 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 de 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.

Compatibilidad con JMS: el bróker ahora admite cargas de trabajo de JMS con el complemento de intercambio de temas de JMS activado, lo que permite que las aplicaciones de JMS se conecten mediante el cliente de JMS. RabbitMQ

Tamaño de almacenamiento configurable: los brokers RabbitMQ 4.x implementados en el modo CLUSTER_MULTI_AZ admiten tamaños de almacenamiento de EBS configurables. Para obtener más información, consulte los tipos de instancia mq.m7g. Tipos de instancias para la implementación de clústeres m7g

Duplicación de las colas clásicas: las colas clásicas siguen siendo compatibles sin ningún cambio importante para las bibliotecas y aplicaciones cliente, pero ahora son de un tipo de cola que no se replica. Los clientes podrán conectarse a cualquier nodo para publicar y consumir desde cualquier cola clásica no replicada. Se recomiendan las colas de quórum para la replicación y la seguridad de los datos.

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

Compatibilidad con colas transitorias y no exclusivas: las colas transitorias son colas cuya duración depende del tiempo de actividad del nodo en el que se declaran. En un bróker 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. Se recomienda 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 vuelvan a entregar 20 veces o más se convertirán en letra muerta o se eliminarán (eliminarán). Si lo habitual es que una cola entregue 20 mensajes por mensaje, debe configurarse un objetivo de texto sin texto 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 de 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 for 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 agentes y se pueden personalizar mediante configuraciones que se ajusten a sus requisitos específicos.