Bien, hablemos primero de la caja.
La «caja», en el caso de los arroyos de Kafka, es la misma «caja» que ya conoces y con la que estás familiarizado. Kafka Streams es una característica integrada en Kafka, desde las versiones recientes. No es necesario descargarla por separado. Usted obtiene todo lo que necesita con la descarga.
Acceder a la API de Streams, a través de cualquier aplicación java es tan sencillo como añadir la dependencia pertinente de cualquier manera «estándar» deseable (por ejemplo, dependencia de maven, gradle o incluso de jarra directa). En la captura de pantalla que figura a continuación se puede ver un ejemplo de dependencia de Maven:
Ahora, el hecho de que sea una biblioteca estándar de Java significa que su entorno de desarrollo, así como el objetivo de despliegue, está limitado sólo por la capacidad del objetivo de albergar una JVM. En otras palabras, eres casi ilimitado 🙂 . Windows, Mac y Linux con gusto alojarán y ejecutarán su aplicación ya sea directamente o en un contenedor, como Docker.
El cliente Streams API será alojado en su aplicación, pero es importante señalar otro aspecto del cliente – todo el cómputo se hace en proceso, dentro de su aplicación de alojamiento de clientes y no en el clúster de Kafka . Es muy importante recordar eso, así que lo repetiré de nuevo:
¿Y eso por qué? Simplemente porque tu grupo de Kafka ya está bastante ocupado :-).
Así que podrías preguntarme si hay gastos adicionales por trabajar con el cliente de Streams.
Sí, hay una sobrecarga.
Sin embargo, en muchos casos, esos gastos generales dependerán de la forma concreta en que se manipulen los datos y pueden reducirse al mínimo.
Aparte de la facilidad de desarrollo y la facilidad de despliegue, y precisamente porque todo el cómputo se realiza en las aplicaciones cliente, las aplicaciones Kafka Streams no requieren un cluster de cómputo dedicado (por ejemplo, Apache Spark). Lo único que hay que hacer es apuntar al clúster de Kafka existente y definir qué transformaciones y enriquecimientos (de datos) le gustaría hacer.
Aquí, en el siguiente diagrama, se puede ver que una aplicación cliente define un flujo de mensajes del tema «CheckoutRequest». A continuación, enriquece la solicitud con datos adicionales y la pasa a un flujo de salida, «EnrichedCheckoutRequest», para su posterior procesamiento mediante procesos que escuchan el flujo «EnrichedCheckoutRequest».
Escalable, tolerante a fallos, seguro
Un punto más a considerar cuando se considera el uso de los arroyos de Kafka, es que viene con las promesas de Kafka de escalabilidad , tolerancia a fallos y seguridad .
Como todos los datos están siendo gestionados por el clúster de Kafka en temas relevantes de Kafka, disfrutamos de la madurez de Kafka con la gestión de nuestros datos de forma segura.
Procesamiento de una sola vez
Todo esto parecía una gran razón para usar el API de Kafka Streams. Sin embargo, guardé lo mejor para el final.
Con las últimas versiones de Kafka Streams, disfrutará de un sistema semántico de procesamiento de una sola vez.
¡Eso es nada menos que una noticia de primera plana!
Con los sistemas de mensajería distribuida hay varias semánticas. Enumeraré la más común:
- Por lo menos una vez
- At-most-once
- Exactamente una vez
Lo que estoy a punto de explicar ahora, asume que todos los temas de Kafka en nuestro grupo, incluso si en estado de fallo, eventualmente estarán disponibles.
Con el procesamiento por lo menos una vez, se nos asegura que cualquier mensaje dado llegará al consumidor por lo menos una vez (como el nombre lo indica). Un mensaje que llegue a un consumidor más de una vez se deberá probablemente a que un productor vuelva a intentar crear un mensaje no reconocido, aunque también pueden ser válidas otras hipótesis.
Con el «at-most-once», básicamente estamos enviando un mensaje y podríamos (debido a un problema de cúmulos) considerar que se ha transmitido aunque no haya llegado a su destino de forma segura.
Pero sólo con una vez exacta podemos estar seguros de que un mensaje llegará y será reconocido por un consumidor una vez y sólo una vez por cada mensaje de streaming.
Y esa es una capacidad muy poderosa en un sistema de mensajería distribuida. Deja al desarrollador libre de pensar en la tarea y simplemente asumir que un mensaje transmitido por streaming llegará a un consumidor de streaming.
La semántica de procesamiento de una sola vez, tan poderosa, le da a Kafka aún más casos de uso, condiciones que antes de Kafka nos habrían obligado a «salvaguardar» nuestras entradas para evitar el procesamiento duplicado de mensajes, o un mecanismo adicional de reintento para asegurarse de que todos los mensajes han sido pasados con éxito.
Hablemos de estos casos de uso.