Message Queue Server: RabbitMQ, Kafka

Message Queue Server: RabbitMQ, Kafka

1) Cuándo elegir

RabbitMQ (AMQP 0-9-1 / 1. 0, colas clásicas, Quorum Queues, Streams)

Adecuado para: RPC/comandos, flujo de trabajo, tareas cortas, enrutamiento fanout/topic, confirmaciones flexibles, administración de prioridades.
Ventajas: una rica semántica de enrutamiento (exchanges), 'basic. qos '(prefetch), per-message TTL/delay, cómodos patrones RPC (reply-to), fácil inicio.
Contras: el historial se almacena en una cola, escala horizontal por colas/chardos; alto costo de Throughput con flujos muy grandes.

Apache Kafka (registro de eventos, partidos, grupos de consumidores)

Adecuado para: hilos de eventos, auditorías, event sourcing, ETL/integraciones (Connect), RPS/MBps altos, reprocesamiento/re-procesado, procesamiento en línea (Streams/ksqlDB).
Ventajas: registro a largo plazo, escalado por lotes, repetición sostenible, compactación de llaves.
Contras: el modelo «pull + lotes» no es para el RPC menor; orden sólo dentro del partido; gestión de circuitos/compatibilidad - responsabilidad del equipo.

2) Semánticas de la entrega e invariantes

At-most-once: sin retrayas; rápido, riesgo de pérdida.
At-least-once: con retraídas; requiere la idempotencia del consumidor.
Exactly-once: alcanzable en condiciones limitadas (Kafka TX + fabricante idempotente + sink coherente; RabbitMQ - a través de la tabla dedup/llaves idempotentes).
Orden: RabbitMQ - orden en la cola (puede ser violado en retras/multi-consumers); Kafka es el orden en el partido, la clave establece el partido.

Invariantes de dominio: dinero/balances - a través de revistas/sagas y comandos idempotentes; no confíe en LWW.

3) Patrones de integración

Outbox/InBox: registro atómico del evento en la DB → publicación en cola (outbox) y consumo idempotente con la guarida de tratamientos (inbox).
DLQ (letras muertas): después de N intentos/errores - en DLQ + alerta.
Retry/Delay: RabbitMQ — TTL + dead-letter exchange; Kafka - retry-topics con backoff.
Request/Reply: RabbitMQ — `reply_to` + `correlation_id`; Kafka es raro, sólo con patrones especiales.
Indemnizaciones: sagas sobre eventos; cada operación tiene una inversa.

4) Diseño de claves y topologías

RabbitMQ

Exchanges: `direct`, `topic`, `fanout`, `headers`.
Clave de enrutamiento: define la cola (y). Para priorizar - colas individuales.
QoS: 'prefetch' (por ejemplo, 50-300) equilibra velocidad/latencia.
Quorum Queues: colas replicables en Raft; reemplazo de mirrored classic.
Streams: flujo con offsets (Kafka-similar) para high-throughput/replay.

Kafka

Topic → partitions: planifique '# partitions' por throughput objetivo y paralelismo (de nuevo es compatible aumentar más fácil que reducir).
Clave: todas las entradas de una sola clave están en un lote (garantía de orden de la clave).
Factor de replicación: 3 para temas productivos, 'min. insync. replicas = 2 '+' acks = all 'para la fiabilidad.
Retention: por tiempo/tamaño; compaction: almacena los últimos valores por clave + tombstones para eliminar.

5) Retraídas, DLQ, idempotencia

RabbitMQ

Repeticiones: per-message TTL + DLX (dead-letter exchange) con backoff (por ejemplo, 1m → 5m → 15m).
Idempotencia: 'correlation _ id '/' message-id' + tabla de mensajes procesados (TTL) o comandos deterministas.
Confirmaciones: manual 'basic. ack 'después de una transacción exitosa;' basic. nack(requeue=false)` в DLQ.

Kafka

Repeticiones: topics retry individuales; consumer commitit offset después de un side-effect exitoso.
Exactly-once processing (EOS): Producer `enable. idempotence = true ', transaccional producer/consumer,' read _ committed 'en el consumidor; sink (por ejemplo, Kafka→Kafka o Kafka→DB a través de una transacción) - sincronizar suavemente.
Dedoup: por clave/clave idempotente en el lado de la base, o a través de un topic compacto.

6) Rendimiento y tamaño

La ley de Little: 'L = λ × W'

Para los workers: el paralelismo requerido es 'N ≈ arrival_rate × avg_processing_time × stock (1. 2–1. 5)`.
Prefetch de RabbitMQ: comience con 'prefetch = 100' y mida p99/tiempo 'in-flight'.
Kafka partitions: cálculo a partir de la concurrencia de consumo deseada y el objetivo por throughput (por ejemplo, 1 lote estable 5-20 MB/s por SSD/10GbE).

7) Observabilidad y alertas

• Log/Backlog (mensajes/bytes), age de mensajes (p95/p99), error-rate de tratamientos, DLQ-rate.
• Tiempo de «publikatsiya→obrabotka» (fin a fin).
• Tarjeta de dependencia: productor → bróker → consumer.

• Conexiones, canales, mensajes sin acento, 'memory _ alarm',' disk _ free _ limit ',' queue length 'p95.
• Informes sobre Quorum (leader, Raft log, faltas de 'quorum not enough').

• Under-replicated partitions, ISR shrink/expand, controller changes.
• Producer errors (timeouts, `request latency`), consumer lag per group/partition.
• Broker I/O, page cache hit, GC, ZooKeeper/KRaft health.

8) Seguridad y multi-tenencia

Encriptación TLS in-transit, autenticación (SASL/PLAIN/SCRAM/OAuth, mTLS).
Autorización: vhost/permissions (RabbitMQ), ACL en topics/group (Kafka).
Cuotas: para conexiones, canales, tamaño de cola/topic, velocidad de publicación/lectura.
Aislamiento por miércoles (dev/stage/prod) y por namespace/vhost.

9) Operación y afinación

RabbitMQ

Extienda los exchanges/queues por nodos (capaceta CPU/IO).
Lazy queues (mensajes de disco) para búferes grandes; evite las colas «calientes» sin charding.
Quorum Queues para HA; planifique el tamaño del registro Raft y el disco.
Las políticas TTL/length-limit, priority de la cola sólo en caso de necesidad real (caro).

bash rabbitmqctl set_policy DLX "^task\." \
'{"dead-letter-exchange":"dlx","message-ttl":60000,"max-length":100000}' --apply-to queues

Kafka

SSD/NVMe, redes rápidas; Sintonización OS (swappiness bajo, límites de archivo).
`acks=all`, `linger. ms '(bateo),' compresión. type = zstd '/lz4 para ancho de banda.
Parámetros del consumidor: 'max. poll. interval. ms`, `max. poll. records`, `fetch. min. bytes`.
Retention y Compaction: balance de almacenamiento/replay.

java props. put("acks","all");
props. put("enable. idempotence", "true");
props. put("max. in. flight. requests. per. connection","1");
props. put("retries","10");

10) Integración y ecosistema

Kafka Connect (Sinks/Sources), Registro de Schema (Avro/JSON/Protobuf) y compatibilidad ('BACKWARD/FORWARD/FULL').
Kafka Streams/ksqlDB: operaciones stateful, ventanas, agregados.
RabbitMQ Shovel/Federation: migración entre clústeres/centros.
Operadores de K8s: Strimzi (Kafka), RabbitMQ Cluster Operator; GitOps-manifiestos.

11) Lista de verificación de implementación (0-45 días)

0-10 días

Definir uso-caso's: comandos/tasky (RabbitMQ), eventos/auditoría (Kafka).
Seleccione las claves ('routing key '/' partition key'), especifique SLO «publikatsiya→obrabotka».
Políticas básicas de seguridad (TLS, ACL), cuotas, DLQ/TTL.

11-25 días

Implementar outbox/inbox, idempotencia y dedoup.
Configurar retraídas con backoff (Rabbit: TTL + DLX; Kafka: retry topics).
Dashboards: lag, age, DLQ-rate, end-to-end latency; alertas.

26-45 días

Ajuste de ancho de banda: prefetch/acks (Rabbit); partitions/acks/batch (Kafka).
Procedimientos de DR (duplicación/replicación), pruebas de fallo de nodo.
Documentar los contratos de eventos (esquemas) y la política de compatibilidad.

12) Anti-patrones

Una herramienta «universal» para todas las tareas.
Ausencia de DLQ/TTL: envenenadores eternos (mensajes de poison).
Ilimitado 'prefetch' → ayuno de los consumidores, crecimiento p99.
Kafka sin claves → pérdida de orden/lotes calientes por defecto.
«Exactly-once» sin necesidad/disciplina real es una falsa sensación de seguridad.
Secretos/lógicos en el código, sin TLS/ACL.
Código duro de esquemas/versiones de mensajes sin Registro y migraciones.

13) Métricas de madurez

Lag/age SLO se ejecuta ≥ el 99% del tiempo; DLQ-rate bajo control.
La idempotencia cubre el 100% de las vías críticas; outbox/inbox implementado.
Retention/compaction está documentado, el replay no rompe a los consumidores.
Las alertas en ISR/URP (Kafka) y Raft/Disk Limits (Rabbit) están configuradas.
Los contratos de eventos se versionan (Registro de Schema), la compatibilidad se prueba en CI.
Días de juego regulares: error de nodo/corredor/AZ, verificación de recuperación.

14) Ejemplos de confecciones (resumen)

python channel. basic_qos(prefetch_count=200)
for msg in consume("tasks"):
try:
handle(msg)
channel. basic_ack(msg. delivery_tag)
except Transient:
channel. basic_nack(msg. delivery_tag, request = False) # will go to DLQ

java props. put("enable. auto. commit","false");
props. put("isolation. level","read_committed"); // при EOS
//...
poll -> process(idempotent) -> commitSync()

15) Conclusión

RabbitMQ y Kafka resuelven diferentes clases de tareas: comandos/tasky y enrutamiento rico contra el registro de eventos a largo plazo y streaming escalable. Éxito - en semánticas de entrega correctas, disciplina de idempotencia, clave pensada, retraídas/DLQ, observabilidad y seguridad estricta. Construye prácticas de ingeniería alrededor de las colas - outbox/inbox, esquemas y políticas GitOps - y tu integración será predecible, escalable y sostenible.