v2.0 es el último paquete del temario. Añade cuatro módulos - schema-registry, authorization, share-groups y capstones - además de tres escenarios de topics diskless en el módulo storage, un simulacro de DR active-active en el módulo dr y el particionado consciente del rack en el módulo producer, 24 escenarios nuevos en total. Desbloquea los niveles governance y diskless en el free play y completa el temario del Kafka Simulator con 136 de 136.

También es la versión en la que se ha reconstruido el playground que rodea esos escenarios. Desde la v1.9 ha cambiado casi todo: el lienzo tiene tres vistas, la línea de tiempo se ha convertido en algo que se puede leer, los inspectores responden preguntas en lugar de listar campos y el terminal ya no tapa el lienzo.

Qué trae la v2.0

Schema Registry (schema-registry, 3 escenarios). Subjects y versiones, qué comprueban las compatibilidades backward, forward y full, y un cambio incompatible rechazado antes de registrarse.

Autorización (authorization, 2 escenarios). Control de acceso en el camino de datos - cómo una ACL, o un role binding de RBAC, permite o deniega un produce cuando el autorizador deniega por defecto.

Ambos llegan al free play con el nuevo nivel de gobernanza: Schema Registry, controles de ACL y RBAC, y kafka-acls en el terminal, para que puedas reconstruir y romper a mano todo lo que muestran los escenarios.

Share groups (share-groups, 9 escenarios). La semántica de colas de Kafka, introducida en KIP-932:

Los share groups cambian la forma de consumir de Kafka, y verlos junto a los grupos de consumidores clásicos muestra qué es lo que cambia.

Capstones (capstones, 5 escenarios). Escenarios de extremo a extremo que combinan durabilidad, transacciones, almacenamiento, multi-DC y gobernanza, con más de una cosa ocurriendo a la vez: un pipeline de pagos exactly-once que sobrevive a la pérdida de una región, un failover regional sin pérdida de datos, una migración sin tiempo de inactividad con Cluster Linking, una columna vertebral de eventos activo/activo multi-DC, y un pipeline ajustado a la vez para throughput y latencia.

Recuperación ante desastres (dr, 1 escenario más). Un simulacro de DR active-active: se pierde la región west, su productor y su grupo de consumidores pasan a east y siguen escribiendo, y después west se reinicia y vuelven a casa. No se promueve nada, y los registros que west nunca replicó son el precio.

Productor (producer, 1 escenario más). Particionado consciente del rack, nuevo en Kafka 4.4: un productor mantiene sus registros sin clave en su propia zona de disponibilidad, hasta que esa zona pierde sus líderes. Más detalles abajo, en Apache Kafka 4.4.

Topics diskless (dirección de KIP-1150, borrador de KIP-1163/1164)

Un topic diskless guarda los datos de sus particiones en el almacenamiento de objetos en lugar de en los discos de los brokers. Un broker acumula registros de muchas particiones y los sube como un único objeto WAL; un coordinador diskless asigna los offsets al confirmar ese objeto, y el produce se confirma (ack) en ese commit. Las réplicas construyen su log releyendo el objeto desde el almacenamiento en lugar de hacer fetch al líder, y productores y consumidores usan una réplica de su propia zona de disponibilidad.

El estado actual: KIP-1150 está aceptado como dirección, mientras que KIP-1163 y KIP-1164, que definen cómo funciona, siguen en Under Discussion (KAFKA-19161 sigue la implementación). Modelamos el borrador actual y lo marcamos como “KIP draft” en todo el simulador. Los nombres y el comportamiento pueden cambiar antes de que nada de esto llegue a Kafka.

Tres escenarios (storage, 05.4.1-05.4.3):

  • Diskless: el camino de escritura - dos productores y dos particiones comparten un objeto WAL, no existe ningún offset hasta que el coordinador lo confirma, y las réplicas releen los datos desde el almacenamiento de objetos.
  • Sin replicación entre AZ - los mismos 3 registros van a un topic clásico y a uno diskless repartidos en tres AZ; la tarjeta Cross-AZ traffic termina con 7 saltos en el clásico y 0 en el diskless.
  • El precio es la latencia - el mismo produce con acks=all se confirma en 300 ms en un topic clásico y en 1300 ms en uno diskless, mientras que una ráfaga que llena el búfer se confirma en 800 ms. Los tiempos están ampliados para que cada paso sea visible.

En el free play: un preset Diskless 3 AZ, un interruptor diskless por topic y deslizadores para los tiempos de diskless. El lienzo gana un carril de almacenamiento de objetos con su propio eje temporal, bandejas WAL bajo cada broker y una insignia del coordinador, y el panel de métricas una tarjeta Cross-AZ traffic. En el terminal, kafka-topics --create --config diskless.enable=true crea un topic diskless y kafka-diskless-metadata (también una herramienta en borrador, que aún no está en Apache Kafka) muestra los offsets por partición y lista los objetos WAL del almacenamiento.

El compromiso, en resumen: menos tráfico de replicación entre AZ y produces más lentos - el borrador apunta a una latencia de produce de unos 500 ms en P50 y de 1-2 s en P99. Kafka clásico ya puede leer de un follower de la misma AZ (KIP-392), así que lo que aporta diskless es que no hay replicación entre brokers y que un produce no tiene que llegar al líder.

Apache Kafka 4.4

El modelo sigue ahora Apache Kafka 4.4, publicado esta semana. Comparamos 4.3.0 con 4.4.0 y no encontramos ningún valor por defecto, salida de la CLI ni mensaje de error en los que se apoye el simulador que haya cambiado, así que todo en los escenarios se comporta como antes.

La v2.0 modela una novedad de 4.4: el particionado consciente del rack en el productor (KIP-1123). Con partitioner.rack.aware=true y un client.rack, el particionador por defecto envía los registros sin clave a particiones cuyo líder está en la zona de disponibilidad del productor, y a cualquier partición cuando esa zona no tiene líder, de modo que el tráfico de producción no sale de la zona. El nuevo escenario Particionado consciente del rack muestra los dos casos. En el free play, el inspector del productor tiene el interruptor, y los productores con los que arranca un sandbox pueden elegir su client.rack. Sin client.rack, el productor rechaza el ajuste, como en Kafka.

Las colas de mensajes fallidos (dead-letter queues) de los share groups (KIP-1191), otra novedad de 4.4, aún no están modeladas.

Un playground reconstruido

Tres formas de ver un clúster

El lienzo tiene ahora tres vistas, que se cambian desde su barra de herramientas:

  • Brokers es la imagen de siempre: productores a la izquierda, el clúster en el centro, grupos de consumidores y share groups a la derecha.
  • Lanes dibuja una fila por partición sobre un eje de offsets compartido: las réplicas una debajo de otra, el líder primero, y el high watermark como una sola línea que las atraviesa todas. Un follower rezagado tiene un log visiblemente más corto, el log de un broker detenido se queda quieto, y cada consumidor aparece en su posición de lectura con su offset confirmado y su lag. De un vistazo ves dónde está cada uno en el log.
  • Matrix es para clústeres demasiado grandes para dibujarlos: una tabla con los topics en filas y los brokers en columnas, y cuatro lentes - Failures, Balance, Lag y Traffic - que la colorean y la ordenan poniendo primero lo peor. Al pasar el ratón por un broker se ve qué perdería el clúster, topic por topic, antes de detenerlo. Un clúster grande de free play se abre directamente en Matrix.

El lienzo muestra lo que ha cambiado

Los cambios de estado se reproducen ahora sobre el elemento que ha cambiado en lugar de con un pulso genérico: los marcadores del high watermark se deslizan hasta su nuevo offset, la corona del líder pasa del líder antiguo al nuevo, y la etiqueta ISR de un follower toma el color del cambio. Un registro producido aterriza en su propia celda del log, un lienzo con mucha actividad dibuja los registros como estelas cortas, y un broker detenido se queda en el lienzo, atenuado, para que veas lo que había ahí. En los lienzos multirregión, el enlace de mirror muestra su RPO, cada franja de DC indica lo que costaría perderla, una partición de red muestra qué lado sigue sirviendo, la franja de KRaft cuenta su mayoría y el carril de un share group muestra el temporizador de bloqueo y el recuento de entregas de cada registro.

Una línea de tiempo que se puede leer

En el escritorio, el dock inferior es ahora un rail de una sola línea: los fotogramas se colocan en su tiempo real de simulación, de modo que una ráfaga se lee como un grupo y un tramo tranquilo como un hueco, y se recorre arrastrando sobre él. Abre sus event lanes y todos los eventos de la ejecución se reparten en carriles de produce, replicación, brokers y consumo, con los fallos en rojo y el evento principal de cada fotograma marcado.

Inspectores que responden preguntas

El panel derecho parte ahora de las preguntas que te haces. Una partición se lee como una regla de sus offsets, un broker como lo que pierdes cuando se detiene, un topic como un carril por partición, un productor como su camino de envío y un grupo de consumidores como carriles o como una cuadrícula de particiones. Why lista qué se ha roto y por qué, Metrics se agrupa por rol, y algunos inspectores muestran lo que va a pasar a continuación, no solo el estado actual. Las vistas multirregión ganan una tarjeta de DR que muestra el log de cada región y la cola sin replicar como RPO.

El lienzo le hace sitio al terminal

El terminal CLI de Kafka sigue acoplado bajo el lienzo, pero ahora el lienzo le hace sitio en lugar de quedar tapado por él - así que kafka-server-stop y la caída de broker-1 aparecen en pantalla a la vez, y el terminal tiene todo el ancho del lienzo para lo que escribes y lo que imprimen las herramientas. En una pantalla ancha, dock side en su barra de título lo pasa a una columna junto al lienzo. La salida conserva sus columnas y el menú de hosts es una tabla ssh con todos los brokers y controladores. Los archivos de configuración de los brokers coinciden con Kafka 4.4, y kafka-reassign-partitions --generate, junto con drenar un broker antes de retirarlo, funcionan como en un clúster real.

Primeros pasos, sin tour

El tour modal de 13 pasos ha desaparecido. En su lugar hay una tarjeta Getting started en una esquina del lienzo: los mismos temas como una lista de comprobación que recorres en el orden que quieras, cada uno con un “Show me”. La ayuda es ahora una referencia en la que consultar cosas, un escenario guionizado se puede bifurcar en un sandbox con Undo, los escenarios sugieren sus propios movimientos de “Try it yourself” y qué hacer después, y un enlace compartido reproduce ahora cómo se llegó al estado que muestra.

Un aspecto nuevo y un repaso de accesibilidad

Todo el sitio, playground incluido, tiene un aspecto nuevo inspirado en la grajilla de nuestro nombre: tinta oscura, un brillo azul y gris, con todos los pares de colores de texto en WCAG AA. Con él llegaron enlaces para saltar al contenido y regiones con nombre, un rail de escenarios con una sola parada de tabulación, contraste AA para las regiones inactivas, respuesta visual al pulsar y áreas táctiles más grandes, y un movimiento que respeta prefers-reduced-motion conservando los fundidos y eliminando los desplazamientos. El diseño para móvil tuvo su propio repaso, hasta un test que comprueba que todas las etiquetas siguen cabiendo.

Fuera del playground

El playground en sí no es indexable, así que los buscadores nunca vieron el texto de sus escenarios. Ahora cada escenario tiene su propia página en /kafka-simulator/scenarios/: su introducción y su conclusión, cada paso con un enlace “Open at this step”, un fotograma real del lienzo que puedes recorrer paso a paso y las configuraciones de Kafka que toca. Con la v2.0 son 136 páginas.

Junto a ellas están las páginas de resolución de problemas para errores y síntomas de Kafka: qué significa el problema, las causas probables, las soluciones y lo que no hay que hacer, y si el cliente lo reintenta. Cada una está enlazada a los escenarios en los que ocurre, abiertos justo en ese momento. La página de autorización se suma a ellas con esta versión. El changelog se lee ahora como notas de versión sobre una línea de tiempo.

Una cosa más

Hemos escondido algo en esta versión. Encontrarlo te lo dejamos a ti.

El final de la hoja de ruta

v2.0 completa lo que empezó con la v1.0: once paquetes quincenales, 136 escenarios, desde la anatomía de un único broker hasta las colas y los capstones de plataforma completa. Todo se ejecuta en el navegador, de forma determinista, con la semántica de Apache Kafka 4.4, sin backend y sin telemetría sobre tus escenarios.

El temario está completo, pero el simulador es un sandbox, no un curso que se termina. Abre el simulador, construye algo y rómpelo.