iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Kafka garantiza el orden dentro de cada partición, no entre todas las particiones de un topic. Para que los eventos de una misma entidad, como un cliente, una cuenta o un vehículo, queden en una secuencia ordenada, la aplicación debe enviarlos con una clave que los haga caer en la misma partición. La moneda puede servir como clave en un caso concreto, pero no es una regla de Kafka ni una recomendación general.
Qué orden garantiza Kafka exactamente
Un topic se divide en particiones. Cada partición es un log ordenado en el que cada registro recibe un offset. Según la documentación de conceptos de Apache Kafka, “any consumer of a given topic-partition will always read that partition’s events in exactly the same order as they were written”. Esa es la garantía: el orden relativo de los registros de una partición se mantiene para cualquier consumidor que la lea.
Lo que Kafka no ofrece es un orden total entre particiones del mismo topic. Si dos eventos relacionados caen en particiones distintas, un consumidor puede recibirlos en cualquier orden relativo. Kafka no puede reconstruir un orden global que la aplicación repartió entre particiones, porque no conoce la relación de negocio entre esos eventos.
La garantía también tiene un alcance temporal y de origen. Kafka ordena lo que se escribió en la partición; no garantiza el orden en que ocurrieron los hechos en el mundo real ni el orden entre productores independientes que escriben en la misma partición sin coordinarse.
#1 Best Overall
Cómo la clave decide la partición
La asignación de un mensaje a una partición la controla el cliente productor, no el broker. Según el protocolo oficial, el broker no impone qué mensaje debe ir a qué partición. Una estrategia habitual toma la clave del mensaje, aplica una función hash y escoge la partición a partir del resultado. Mientras la clave y el número de particiones no cambien, todos los registros con la misma clave van a la misma partición.
Esto tiene dos consecuencias prácticas:
- Los eventos sin clave no tienen orden de entidad. Si el productor no envía clave, los registros se reparten sin que la aplicación pueda asociarlos a una secuencia concreta.
- Cambiar el número de particiones cambia el destino de las claves. Con asignación por hash, al añadir particiones una misma clave puede empezar a escribir en otra partición. Los eventos anteriores permanecen donde estaban, así que la secuencia de esa entidad queda partida en el punto del cambio. Conviene fijar el número de particiones antes de producir datos que dependan del orden.
Por qué “la clave es la moneda” necesita matiz
La moneda puede ser una clave válida si la divisa es la entidad cuyo orden importa. Por ejemplo, si una tesorería necesita revisar en orden todas las operaciones de una misma divisa, usar la divisa como clave hace que esas operaciones compartan partición. Pero la documentación de Kafka describe el mecanismo general de claves y no prescribe la moneda ni ningún otro campo concreto.
El riesgo de la moneda es de distribución, no de corrección. Una clave de baja cardinalidad, como un conjunto pequeño de divisas, tiende a concentrar el tráfico en pocas particiones. Esta es una inferencia práctica del particionamiento por hash, no una medición publicada: si una divisa domina el volumen, la partición que la recibe puede convertirse en cuello de botella mientras el resto del topic está casi vacío.
Si el orden que importa es el de cada cuenta, cliente o vehículo, la clave debe ser ese identificador. Si el orden que importa es el de una divisa dentro de un proceso de conciliación, la moneda es razonable. En ambos casos la pregunta es la misma: qué entidad necesita una secuencia completa.
Rank #3
Tres formas de diseñar el orden
| Estrategia | Qué queda ordenado | Paralelismo | Cuándo encaja |
|---|---|---|---|
| Topic con una sola partición | Todo el topic, en un único log | Un solo consumidor del grupo lee la partición a la vez, por lo que la concurrencia queda limitada | Flujos de bajo volumen donde el orden global de todo el topic es más importante que el rendimiento |
| Clave por entidad (cliente, cuenta, vehículo) | Los eventos de cada entidad dentro de su partición | Varias particiones; el trabajo se reparte entre entidades, y el orden se mantiene solo dentro de cada una | Casos en los que cada entidad tiene su propia secuencia y no existe orden entre entidades distintas |
| Clave por moneda | Las operaciones de cada divisa dentro de su partición | Depende de cuántos valores de divisa aparezcan y de su peso en el volumen; la concentración no está medida en la documentación consultada | Procesos donde la divisa es la unidad de conciliación o de cálculo |
La documentación consultada no aporta cifras comparativas de throughput ni de latencia para estas opciones, así que cualquier número de rendimiento debe medirse con la carga y la configuración propias del sistema.
Orden no equivale a exactamente una vez
Un flujo puede conservar el orden dentro de una partición y, aun así, procesar un evento dos veces o perderlo. Son garantías distintas, y cada una depende de configuración en distintas partes del sistema.
Guardar el offset: antes o después
El consumidor decide cuándo registra su offset. Si lo guarda antes de procesar el registro, un fallo durante el procesamiento puede dejar ese evento sin procesar. Si lo guarda después, un fallo entre el procesamiento y el registro del offset puede provocar que el evento se reprocese. Cada orden de operaciones tiene un riesgo distinto, y el diseño debe elegir cuál es aceptable para el negocio.
Free tools Windows power users keep installed
One-click scans. No signup required.
Idempotencia del productor
La documentación de KafkaProducer indica que la idempotencia del productor se limita a los mensajes enviados dentro de una sesión del productor. Reduce duplicados provocados por reintentos dentro de ese alcance. No crea un orden entre particiones ni cubre fallos fuera de la sesión.
Transacciones
Las transacciones requieren configuración explícita, incluido transactional.id. Según la guía de configuración de la versión consultada, ese identificador permite semánticas que atraviesan sesiones del productor. La misma guía recomienda, para producción, un clúster de al menos tres brokers para usar transacciones. Esta recomendación depende de la versión de la documentación y conviene verificarla en la versión que se despliega.
Según el documento de diseño de Apache Kafka 4.1, “the transactional producer and the consumer using read-committed isolation level can be used generally to provide exactly-once delivery when reading, processing and writing data on Kafka topics”. La misma sección añade: “Exactly-once delivery for other destination systems generally requires cooperation with such systems”. Dentro de Kafka a Kafka, las transacciones permiten producir resultados y actualizar offsets como una unidad atómica. Hacia bases de datos u otros sistemas externos, la garantía depende de que el destino coopere, por ejemplo mediante escrituras idempotentes o claves únicas.
Callbacks del productor
La API de KafkaProducer garantiza que los callbacks de registros enviados a la misma partición se ejecuten en orden. Esa garantía se aplica a los callbacks del cliente bajo las condiciones descritas por la API. No debe leerse como un orden total de callbacks entre particiones distintas.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchErrores frecuentes al elegir la clave
- Usar una clave que no representa la entidad. Si la clave es un campo técnico, como un ID de lote, los eventos de un mismo cliente pueden repartirse en varias particiones.
- Usar una clave de baja cardinalidad sin medir el reparto. Un campo con pocos valores puede dejar particiones vacías y otras saturadas.
- Esperar orden entre productores que escriben sin coordinación. Kafka ordena lo que llega a la partición, no la intención de cada productor.
- Cambiar el número de particiones en un topic con historia que depende del orden. La clave que antes iba a una partición puede empezar a ir a otra.
- Confundir orden con entrega exactamente una vez. Revisar el momento de guardar offsets y la idempotencia del destino antes de dar la garantía por cerrada.
Cómo decidir la clave
- Identifica la entidad cuya secuencia debe mantenerse completa; esa es la clave candidata.
- Confirma que todos los productores envían la misma clave para esa entidad, con el mismo formato.
- Estima cuántos valores distintos tendrá la clave y cuánto volumen concentra cada uno.
- Define cuántas particiones necesitas antes de producir datos que dependan del orden.
- Decide qué pasa con los duplicados y los fallos en el consumidor y en el destino final.
Si el orden debe ser global para todo el topic, la única opción que lo garantiza es una partición, con el coste de paralelismo que eso implica. En la mayoría de los casos en los que se necesita orden, la clave por entidad ofrece el equilibrio más útil entre secuencia y rendimiento.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
