← volver

¿qué es apache kafka?

kafkaevent-drivenmensajería

introducción

apache kafka es una plataforma distribuida para manejar eventos en tiempo real: permite enviar, almacenar y consumir flujos de datos de forma fiable y escalable.

a diferencia de una cola “simple”, kafka persiste los eventos en un commit logparticionado y replicado. eso habilita alto rendimiento, reprocesamiento y tolerancia a fallos.

idea clave: kafka no es una base de datos relacional ni una cola básica; es un commit log distribuido que guarda eventos por topics y particiones, con réplicas para disponibilidad.
diagrama — distintos casos de uso de apache kafka.

demo: flujo producer → tópico → consumer

presiona enviar evento en “usuario” y observa cómo se agrega al final del tópico; inicia consumir en “kafka consumer”.

usuario

interactúa → producer

tópico de kafka — partición #0
primer offset: 0último offset: 0siguiente: 1
offset 0
evento #1
cada clic agrega un evento al final del log.
kafka consumer

lee en streaming

offset leído: —
interacción — envío y consumo con offsets crecientes.
diagrama — un mismo topic puede alimentar múltiples consumer groups con asignaciones distintas. Flujo de arriba diagramado.

conceptos

  • topic: categoría donde se publican eventos.
  • partición: división del topic para paralelismo y throughput.
  • réplica: copia de una partición (líder + seguidores) para tolerancia a fallos.
  • broker: servidor kafka que almacena y entrega particiones.
  • producer: servicio que envía eventos al topic.
  • consumer: servicio que lee eventos, usualmente en grupos.

particiones y réplicas

cada partición tiene un líder que acepta escrituras y una o más réplicas seguidoras. si el líder falla, una réplica elegible asume el liderazgo.

Un tópico con 3 particiones y 3 réplicas distribuidas en 3 brokers
diagrama — distribución de líderes y réplicas de un tópico en múltiples brokers.

grupos de consumidores

los consumidores se organizan en grupos. dentro de un grupo, cada partición es leída por un único miembro (balanceo automático). varios grupos pueden leer el mismo topic de forma independiente.

Particiones de un topic asignadas a distintos consumer groups
diagrama — un mismo topic puede alimentar múltiples consumer groups con asignaciones distintas.

demo avanzada: particiones, key hashing y consumer group

envía eventos con o sin key (la key dirige la partición). cambia los miembros para provocar rebalance. observa el lag y los offsets comprometidos por partición.

topic con 3 particiones • consumer group
miembros: 2lag total: 6
producer
consumer group
partición #0
owner: M1last: 1committed: -1lag: 2
offset 0
evento #1
key: k0-0
offset 1
evento #2
key: k0-1
partición #1
owner: M1last: 1committed: -1lag: 2
offset 0
evento #1
key: k1-0
offset 1
evento #2
key: k1-1
partición #2
owner: M2last: 1committed: -1lag: 2
offset 0
evento #1
key: k2-0
offset 1
evento #2
key: k2-1
M1
particiones: 1
M2
particiones: 2
interacción — cada partición tiene un único owner en el group; lag = last − committed.

replicación entre brokers (y regiones)

la alta disponibilidad se logra replicando particiones en brokers distintos; en algunos despliegues, incluso en zonas/regiones diferentes para DR.

diagrama — una partición con líder y réplicas ubicadas en diferentes regiones.

resumen visual

Particiones ≡ escalabilidad; Brokers ≡ disponibilidad
lámina — regla mental: particiones → escalabilidad; brokers → disponibilidad/DR.

¿por qué usar kafka?

  • alto throughput y latencia baja para eventos en tiempo real.
  • persistencia y reprocesamiento: relees histórico cuando quieras.
  • tolerancia a fallos con réplicas y liderazgo.
  • escalado horizontal por particiones y por consumidores en grupo.
  • ecosistema completo: connect, streams, ksql, esquema/serde, etc.