Log vs cola
El extracto de marzo
3 de abril. El equipo de Reporting descubre un error: durante todo marzo ha agrupado mal los movimientos en el extracto. El código ya está corregido, pero hay que rehacer el extracto del mes entero. «Solo tenemos que volver a leer los movimientos de marzo», dice alguien. «¿Y dónde están?».
Reportingver en el mapa se entera de los movimientos escuchando MovimientoRegistrado, que publica Cuentasver en el mapa. Los procesó en su día, uno a uno, a través del broker. La pregunta es si el broker los sigue teniendo.
Hasta ahora el broker ha sido una caja genérica que «guarda el mensaje hasta que cada consumidor lo procesa». Lo que pasa después de procesarlo lo dejamos para este episodio, y la respuesta depende de qué tipo de broker sea. Hay dos grandes familias: las colas y los logs.
Los mismos movimientos, dos brokers
Cuentas publica movimientos (m1, m2…) y Reporting los anota en el extracto. A la izquierda, un broker con una cola por suscriptor; a la derecha, un log, con la posición de cada consumidor debajo. Registra movimientos, pide a Reporting que reprocese el mes, añade un consumidor nuevo y, al final, haz que Reporting se caiga en mal momento.
Qué ha pasado
Dos formas de guardar un mensaje
Una cola es una lista de tareas pendientes. Cuando Reporting confirma que ha procesado un mensaje (el ack), el broker lo borra: ya no queda nada por hacer con él. Si hay dos suscriptores, cada uno tiene su propia cola, con su propia copia de cada mensaje.
Un log es un registro que solo crece. Los mensajes se añaden al final y nunca se borran por haberlos leído. Cada consumidor lleva la cuenta de por dónde va (su posición u offset), y confirmar es solo avanzar esa posición. Lo que decide cuándo se borra un mensaje no es quién lo ha leído, sino una política de retención: siete días, un año o para siempre.
Con un día normal no notas la diferencia.probar en el laboratorio Reporting recibe lo mismo en los dos. Solo cambia lo que queda en el broker después: la cola, vacía; el log, entero.
Volver a leer
Esa diferencia es la que salva o hunde el extracto de marzo.probar en el laboratorio Con log, Reporting vacía su extracto, pone su posición a cero y vuelve a leer el mes. Nadie más se entera: ni Cuentas, ni los demás consumidores, que siguen por donde iban.
Con cola no hay nada que releer. Cada mensaje se borró cuando Reporting lo confirmó en marzo. Las opciones son pedir a Cuentas que vuelva a publicar los movimientos (y entonces los recibirán también todos los demás suscriptores, que no los esperaban) o montar un camino aparte, una exportación o una consulta directa, solo para esto. En los dos casos, un fallo de Reporting acaba siendo trabajo para Cuentas.
Llegar tarde a la fiesta
Pasa lo mismo con un consumidor nuevo.probar en el laboratorio Antifraudever en el mapa quiere aprender patrones de los movimientos del mes. En el log, empieza en la posición 0 y lee todo el historial que haya retenido. En la cola, su cola se crea en el momento en que se suscribe: solo recibe lo que llegue a partir de entonces.
En el episodio 1 decíamos que con eventos «añadir un consumidor es suscribirse». Con log, además, el consumidor nuevo puede ponerse al día solo.
Un log no es la fuente de verdad del banco. Los movimientos de Ana viven en el libro de Cuentas, que es su base de datos. El log tiene una copia de los eventos durante el tiempo que diga su retención. Se puede configurar para guardar años, pero entonces es un almacén más que hay que tratar como tal (copias de seguridad, datos personales, borrados).
Lo que la cola hace mejor
Si el log gana en todo lo anterior, ¿para qué quieres una cola? Porque piensa en mensajes sueltos, no en un historial, y eso tiene ventajas:
- Repartir trabajo es trivial. Pon tres instancias de Notificaciones leyendo de la misma cola y el broker reparte los mensajes entre ellas. En un log, el reparto va por particiones: si el log tiene una sola, solo una instancia puede leer a la vez. Las particiones son el tema del episodio 6.
- Cada mensaje va a su aire. Si un mensaje falla, la cola lo reintenta o lo aparta a una cola de mensajes muertos (dead letter queue) y sigue con los demás. En un log, la posición avanza en orden: un mensaje que falla siempre bloquea a los que vienen detrás hasta que decides qué hacer con él.
- Enrutado, prioridades, retrasos. Muchas colas permiten mandar cada mensaje a un sitio según su contenido, darle prioridad o programarlo para más tarde.
Por eso la cola es la herramienta natural para tareas: mandar un SMS, generar un PDF, reintentar un envío. Y el log, para hechos que varios consumidores leen a su ritmo y que alguien puede querer releer.
¿Una vez, al menos una vez o como mucho una vez?
Queda una pregunta que no depende de cola o log: ¿cuándo confirma el consumidor? Marca «Reporting se cae a mitad» y prueba las dos opciones.
- Confirmar después de procesar.probar en el laboratorio Si Reporting se cae entre anotar y confirmar, el broker no sabe que lo anotó y se lo vuelve a dar: línea repetida. Nunca se pierde nada, pero algo se puede repetir. Es la garantía al menos una vez.
- Confirmar antes de procesar.probar en el laboratorio Si Reporting se cae entre confirmar y anotar, el broker ya lo da por entregado: movimiento perdido. Nunca se repite, pero se puede perder. Es como mucho una vez.
¿Y exactamente una vez? Entre el broker y un efecto externo (una línea en otra base de datos, un SMS), no existe como garantía del transporte. Lo que sí se puede conseguir es el efecto de exactamente una vez: al menos una vez más un consumidor idempotente que ignora lo que ya ha visto. Es lo que hicimos en el episodio 4.
Criterio
-
¿Alguien puede necesitar releer mensajes pasados, o llegar tarde y ponerse al día?Reporting rehaciendo marzo; Antifraude aprendiendo del mes.log
-
¿Varios consumidores independientes leen el mismo flujo de hechos, cada uno a su ritmo?
MovimientoRegistradopara Reporting, Antifraude y lo que venga.log -
¿Son tareas que hay que repartir entre trabajadores y hacer una vez cada una?Enviar un SMS, generar un extracto en PDF.cola
- Cualquiera sirve. Usa el que ya tengas en marcha: operar dos brokers cuesta más que la diferencia.
| Cola | Log | |
|---|---|---|
| Al confirmar | El mensaje se borra | El consumidor avanza su posición |
| Releer el pasado | No | Sí, lo que cubra la retención |
| Consumidor nuevo | Empieza vacío | Puede empezar desde el principio |
| Repartir entre instancias | Natural, mensaje a mensaje | Por particiones |
| Un mensaje que falla | Se reintenta o se aparta; los demás siguen | Bloquea su partición hasta que decidas |
| Bueno para | Tareas | Hechos |
Y confirma siempre después de procesar, con consumidores idempotentes. Perder un movimiento del extracto es peor que ver uno repetido, y el repetido se puede evitar.
En el mundo real
Logs: Apache Kafka es el más conocido; Amazon Kinesis, Azure Event Hubs y Redpanda funcionan igual. En Kafka, la retención por defecto es de siete días, y existe la compactación, que conserva solo el último mensaje de cada clave (útil para «el último estado de cada cuenta»). Los consumidores guardan su posición en el propio Kafka, por grupo de consumidores.
Colas: RabbitMQ, Amazon SQS, Azure Service Bus o ActiveMQ. SQS borra el mensaje cuando el consumidor lo elimina explícitamente y guarda los no leídos hasta 14 días; si un mensaje falla demasiadas veces, lo manda a una cola de mensajes muertos.
La frontera se difumina. RabbitMQ tiene streams, que son logs. Apache Pulsar ofrece las dos semánticas sobre el mismo almacenamiento. Google Cloud Pub/Sub funciona como una cola, pero se puede configurar para conservar los mensajes confirmados y «rebobinar» a una fecha. Lo que importa no es el producto, sino saber qué semántica estás usando.
Siguiente episodio
Un log con una sola partición lo lee una sola instancia de cada consumidor. Para escalar, se parte en varias… y los movimientos de la cuenta de Ana pueden acabar repartidos entre particiones que se leen a distinta velocidad. Además, el extracto de marzo tenía otra trampa: a mitad de mes, Cuentas cambió el formato de MovimientoRegistrado.