RabbitMQ 4.4: mensajes diferidos, quorum queues y qué probar

RabbitMQ 4.4.0 llegó el 20 de octubre de 2026 con varias capacidades que parecen similares hasta que se observa quién decide el retraso, cuándo se toma la decisión y qué ocurre si el consumidor reinicia. La actualización también cambia la conversación sobre topologías distribuidas: ahora puedes expresar una preferencia de colocación por zona, negociar capacidades nuevas de AMQP 1.0 y usar STOMP sin la capa interna de AMQP 0-9-1.

La primera decisión no es activar cada novedad. Es comprobar qué versión del broker, Erlang/OTP, clientes, plugins y despliegue tienes, y separar lo que existe en RabbitMQ open source de lo que pertenece a Tanzu RabbitMQ.

Qué cambia y qué edición lo incluye

La tabla de releases marca 4.4.0 como la versión de la serie 4.4 publicada el 20 de octubre, con soporte comunitario indicado hasta el 31 de julio de 2027. La fecha de soporte comercial que aparece allí es orientativa y remite al portal de Broadcom para la referencia contractual.

Capacidad	RabbitMQ open source 4.4	Tanzu RabbitMQ 4.4	Precaución
Delayed y deferred messages en quorum queues	Sí	Sí	No son scheduling general ni eliminan idempotencia.
Placement de miembros por etiqueta de zona	Sí	Sí	Reparte miembros; no determina por sí solo el líder ni garantiza disponibilidad.
Erlang/OTP 29, TLS híbrido cuando se negocia	Sí, con los requisitos de crypto y los peers	Sí	OTP 29 solo no convierte todas las conexiones en post-cuánticas.
STOMP nativo	Sí	Sí	La arquitectura cambia; no hay aquí un benchmark universal.
Sole connection AMQP 1.0	Sí, opt-in y con feature flag	Sí	Limita una identidad de conexión solicitante; no es exactly-once.
Migración automática de líderes de quorum	No	Sí	Es una extensión comercial de Tanzu.
JMS topics sobre AMQP 1.0 y noLocal	No como capacidad OSS anunciada	Sí	No atribuir la integración JMS a una instalación OSS.
Federation v2	No como extensión comercial del core	Sí	No confundirla con Federation v1.

La guía de upgrade recomienda investigar una ruta soportada, revisar las notas de la versión objetivo, cumplir la matriz de Erlang y habilitar las feature flags estables antes de un rolling upgrade. Si el cambio incluye RabbitMQ y Erlang 28 o 29, las notas de 4.4.0 piden revisar la ruta desde RabbitMQ 4.3.7 o posterior; no es una receta universal para cualquier origen, plugin o almacén de metadatos.

Tres formas de retener un mensaje

Delayed message no es delayed retry

Un delayed message lo programa el productor al publicar. La quorum queue lo almacena de inmediato y lo mantiene no disponible para consumidores hasta la fecha futura indicada. En AMQP 1.0 la anotación es x-opt-delivery-time, un timestamp Unix absoluto en milisegundos. La ruta y la confirmación ocurren al publicar; no se trata de republicar más tarde mediante un exchange adicional.

Un delayed retry lo decide el consumidor cuando asienta o devuelve el mensaje. La política de quorum queue puede usar delayed-retry-type, delayed-retry-min y delayed-retry-max para calcular un backoff. Es apropiado cuando el consumidor conoce un fallo transitorio y puede calcular el próximo intento. RabbitMQ lo incorporó a quorum queues en 4.3, así que no debe presentarse como la novedad principal de 4.4.

Variante	Quién decide	Dónde espera	Ejemplo de decisión
Delayed message	Productor	Dentro de la quorum queue, hasta una fecha	“No procesar el recordatorio antes de las 14:00”.
Delayed retry	Consumidor	Dentro de la quorum queue, con backoff	“Reintentar en 1–30 segundos tras un error transitorio”.
Deferred message	Consumidor	Dentro de la quorum queue, hasta recuperar por token	“Este evento llegó antes que otro de la misma secuencia”.

Ninguna variante convierte una cola en un reloj exacto de negocio ni confirma que la aplicación procesó el efecto. El límite de longitud de la cola, la carga y la salud del clúster siguen aplicando; confirma publicaciones y diseña consumidores idempotentes.

Deferred message: reordenar sin esconder un incidente

Un deferred message sirve cuando el evento llegó antes de la condición que lo habilita. El consumidor lo asienta con el resultado AMQP modified y un x-opt-deferral-token estable, de hasta 256 bytes. También puede incluir un x-opt-delivery-time como deadline: si nadie lo recupera antes, vuelve a estar disponible para todos los consumidores.

Más tarde, un consumidor solicita los mensajes mediante rabbitmq:deferral-tokens. Los mensajes con el mismo token se entregan del más antiguo al más nuevo y se colocan por delante del backlog disponible. El token identifica el evento dentro de este mecanismo; no es una clave universal de idempotencia ni un almacén de workflow.

Si la base de datos o el servicio del que depende el consumidor está caído y no existe una condición razonable para recuperar el mensaje, diferirlo no resuelve la incidencia. Pausar el consumidor puede ser más honesto que acumular mensajes con deadlines que nadie puede cumplir. El artículo oficial también distingue este caso del retry: la decisión debe corresponder al tipo de fallo y a una condición observable de recuperación.

Placement por zona: distribuir no es elegir líder

RabbitMQ 4.4 puede repartir miembros de una quorum queue entre valores de una etiqueta de nodo. En cada nodo se define, por ejemplo:

node_tags.az = az1

Y se selecciona esa clave para la colocación:

quorum_queue.member_placement_tag = az

También puede configurarse mediante la política member-placement-tag o el argumento x-member-placement-tag. La precedencia documentada es operator policy, user policy, argumento de declaración y, por último, configuración del nodo. La política prevalece sobre una user policy.

La colocación ocurre al declarar la cola y busca repartir miembros entre valores disponibles. No significa que el nodo al que está conectado el cliente sea miembro, no reubica automáticamente todos los miembros existentes y no escoge el líder por sí sola. queue-leader-locator continúa controlando qué miembro es líder. rabbitmq-queues quorum_status muestra la distribución y añade la columna de zona cuando el placement está activo.

El comando rabbitmq-queues rebalance quorum reequilibra líderes; no cambia los nodos que forman cada quorum. Para hablar de alta disponibilidad necesitas además comprobar el número de miembros, las zonas realmente disponibles, el tamaño del quorum, las alarmas y el comportamiento ante la pérdida de una zona. Una etiqueta bien escrita no sustituye esa prueba.

Erlang/OTP 29 y TLS híbrido

RabbitMQ 4.4.0 soporta Erlang/OTP 29. La combinación puede preferir el grupo TLS 1.3 híbrido x25519mlkem768 cuando se negocia con un cliente compatible, y OTP 29 puede preferir firmas ML-DSA cuando existe un certificado compatible. Para esos algoritmos post-cuánticos, la aplicación Erlang crypto debe estar enlazada con OpenSSL 3.5 o posterior.

Eso no convierte a OpenSSL 3.5 en requisito de todo TLS ni a OTP 29 en una promesa de cifrado post-cuántico. Hay que comprobar la versión efectiva de crypto, OpenSSL, el certificado y el cliente que participa en la conexión. Si el peer no ofrece la capacidad, la conexión negociará otra opción compatible. La prueba correcta registra el grupo negociado y el entorno; no infiere el resultado desde la versión del servidor.

La matriz de RabbitMQ indica que Erlang 29 está soportado desde 4.4.0 y que Erlang 26 ya está fuera de soporte. Todos los nodos de un clúster deben usar una combinación compatible y coherente antes de un upgrade.

STOMP nativo y AMQP 1.0

En 4.4, STOMP deja de apoyarse en el cliente interno AMQP 0-9-1: sus conexiones interactúan directamente con exchanges y queues. El anuncio describe menos procesos Erlang y menos memoria por conexión, pero no ofrece un porcentaje aplicable a cualquier carga. La configuración stomp.max_connections permite limitar conexiones; mide el uso real de tu servicio antes de cambiar el límite.

La sole connection de AMQP 1.0 es otra capacidad distinta. El cliente debe solicitar sole-connection-for-container; solo entonces RabbitMQ aplica la unicidad para ese container-id dentro de un virtual host. Con refuse-connection, la segunda conexión se rechaza; con close-existing, se cierra la anterior y entra la nueva. La sustitución solo se permite con el mismo usuario autenticado. Las conexiones que no solicitan la capability no se comprueban.

La feature flag estable rabbitmq_4.4.0 debe estar habilitada en todo el clúster. Inspecciónala antes de la prueba y, tras completar el upgrade y según la política del clúster, habilítala solo si corresponde:

rabbitmqctl list_feature_flags
rabbitmqctl enable_feature_flag rabbitmq_4.4.0

El primer comando debe mostrar rabbitmq_4.4.0 como enabled en el clúster. El segundo no es un paso para improvisar durante una prueba ni se debe ejecutar antes de que todos los nodos soporten la flag; las feature flags no se deshabilitan después.

Para consultar el estado del almacén de enforcement y sus métricas Raft usa rabbitmqctl sole_connection_status; no es un inventario de identidades o leases individuales:

rabbitmqctl sole_connection_status

Si queda un lease huérfano después de confirmar que la conexión ya no existe, la limpieza administrativa excepcional se expresa así:

rabbitmqctl sole_connection_force_delete --vhost <vhost> <container-id>

sole_connection_force_delete no forma parte del flujo normal de conflicto: no reemplaza refuse-connection o close-existing, y tampoco crea una garantía de exactly-once. Antes de usarlo hay que verificar la identidad y el virtual host, porque elimina el registro administrativo que impide otra conexión. La extensión protege la propiedad de una identidad de conexión, no el procesamiento de un mensaje. RabbitMQ no implementa exactly-once delivery, transacciones AMQP 1.0 ni reanudación de entregas como garantía general. Sigue siendo necesario usar confirmaciones, idempotencia y locks de negocio cuando el efecto lo requiera.

Checklist de staging

Antes de activar estas capacidades en producción, prepara una prueba que pueda repetirse y deja claro qué observaste:

1. Inventaría la versión del broker, Erlang/OTP, feature flags, clientes, protocolos, plugins, tipo de cola y despliegue por zonas. Revisa la ruta de rolling upgrade y el rollback antes de detener el primer nodo.
2. Publica un mensaje en una quorum queue con x-opt-delivery-time. Comprueba confirmación, contador de cola y disponibilidad posterior; no conviertas una medición local en una promesa de puntualidad.
3. Separa un escenario de delayed retry con la política delayed-retry-* de otro deferred con token, deadline y recuperación. Reinicia un nodo de prueba y verifica qué estado observa el consumidor.
4. Etiqueta nodos de laboratorio, declara una cola de tres miembros y consulta rabbitmq-queues quorum_status. Comprueba la distribución real y simula una pérdida controlada de zona sin asumir que cualquier número de nodos conserva el quorum.
5. Para TLS, registra RabbitMQ, OTP, la aplicación crypto, OpenSSL, certificado, cliente y grupo negociado. Si no tienes un peer compatible, documenta esa limitación en lugar de afirmar que probaste PQ.
6. Mide STOMP, conexiones AMQP 1.0, memoria, procesos, latencia y alarmas con la carga propia. Abre dos conexiones con el mismo container-id en un vhost de prueba para comprobar el conflicto de sole connection.
7. Conserva el artefacto y configuración anteriores como rollback, pero no atribuyas a OSS una función que solo está disponible en Tanzu.

La pieza anterior sobre RabbitMQ 4.3.6 y su actualización sirve como contexto de compatibilidad y rolling upgrade. Para contrastar la coordinación durable con la idempotencia de efectos externos, consulta Durable Task en .NET; no es documentación RabbitMQ ni un sustituto de sus garantías. La guía Diseñar una API REST sin sorpresas aporta contexto sobre contratos y errores de integración, no sobre la implementación del broker.

Fuentes primarias

• RabbitMQ 4.4 Highlights
• RabbitMQ Release Information
• RabbitMQ Server 4.4.0 release notes
• Erlang Version Requirements
• Upgrading RabbitMQ
• Quorum Queues
• AMQP 1.0
• TLS Support
• Feature Flags
• Monitoring