1. Introducción a Apache Kafka y Shoputopia
Hola a todos. Hoy quería hablarles sobre Apache Kafka, un proyecto increíble que se ha convertido en el estándar predeterminado para la transmisión de datos. Permítanme darles un ejemplo de cómo Apache Kafka puede marcar una diferencia significativa en un proyecto. Imaginen construir un producto de comercio electrónico basado en la película Zootopia, llamado Shoputopia. A medida que el proyecto crece, es importante evitar poner todo en un solo monolito. En su lugar, debemos considerar dividir el monolito en microservicios independientes para garantizar escalabilidad y mantenibilidad.
Hola a todos. Mi nombre es Elena. Trabajo en Ivan donde apoyamos y contribuimos mucho a proyectos de código abierto. Hoy quería hablarles sobre uno de esos proyectos increíbles que ya existe desde hace más de una década y se ha convertido en el estándar predeterminado para la transmisión de datos.
Este es, obviamente, Apache Kafka. Pero antes de dar una definición de Apache Kafka, quería darles un ejemplo de un proyecto donde Apache Kafka marca una diferencia significativa tanto para los usuarios del sistema como para los desarrolladores. Y mi ingeniosa idea de proyecto se basa en una película de animación que quizás hayan visto, Zootopia. Si no la han visto, no se preocupen. Sin embargo, si la han visto, reconocerán algunos de nuestros personajes porque hoy, ustedes y yo, vamos a construir el primer producto de comercio electrónico de Zootopia y lo llamaremos Shoputopia. Y al igual que en cualquier proyecto de comercio electrónico, queremos tener un inventario de productos. Vamos a vender una interfaz de usuario simple para empezar donde nuestros queridos clientes podrán buscar productos, seleccionar lo que necesitan, hacer un pedido y esperar la entrega.
Y al principio, tal vez durante la etapa de MVP, es posible que se sientan tentados a poner todo en un solo monolito donde su frontend y su backend estarán uno al lado del otro. También tendrán alguna fuente de datos allí, y no hay nada de malo en los monolitos en sí. Sin embargo, una vez que tengan más clientes y su tienda se vuelva más popular y comiencen a agregar más y más módulos a este monolito, muy pronto el flujo de arquitectura y el flujo de información del sistema corren el riesgo de convertirse en un desastre. Un desastre que es difícil de mantener y difícil de expandir. Y suponiendo que nuestro equipo de desarrollo está creciendo, ninguna persona individual podrá mantenerse al día con el flujo de información del sistema. Y es posible que hayan estado en esa situación en la que se unen a un proyecto y les presentan la arquitectura, y piensan, ¡Dios mío, cómo navego esto? ¿Con quién debo hablar para entender todo este sistema? En este punto, tendremos que tener una conversación difícil sobre cómo podemos dividir nuestro monolito en un conjunto de microservicios independientes con interfaces de comunicación claras.
2. Importancia de los datos en tiempo real y Apache Kafka
Nuestra arquitectura debe depender de eventos en tiempo real para recomendaciones significativas. También queremos tener acceso fácil a datos en tiempo real sin complicar nuestras vidas. Ahí es donde entra Apache Kafka, desenredando flujos de datos y simplificando el manejo de datos en tiempo real.
Lo que es aún más crucial, nuestra arquitectura debe estar lo más cerca posible de la comunicación en tiempo real para poder depender de eventos en tiempo real, de modo que nuestros usuarios no tengan que esperar hasta mañana para obtener recomendaciones significativas basadas en sus compras realizadas hoy o ayer. También es importante tener soporte para monitoreo en tiempo real, procesamiento e informes que vienen como un paquete de funcionalidad.
Además, como ingenieros, queremos trabajar con datos en tiempo real de manera sencilla, sin complicar demasiado nuestra vida. Y esto es mucho pedir, sin embargo, es por eso que tenemos Apache Kafka, que es excelente para desenredar flujos de datos y simplificar
3. Introducción a Apache Kafka
Apache Kafka es una plataforma de transmisión de eventos que es distribuida, escalable, de alto rendimiento, baja latencia y tiene un ecosistema y una comunidad increíbles. Puede manejar el transporte de mensajes a través de múltiples sistemas, incluyendo microservicios, dispositivos IoT y más. Apache Kafka trabaja con entidades descritas por eventos que ocurren continuamente, lo que permite un flujo de eventos y la capacidad de abordar los datos desde diferentes ángulos. Juega un papel clave en la arquitectura orientada a eventos, coordinando el movimiento de datos y utilizando un modelo de empuje-tirón para manejar los mensajes entrantes.
la forma en que manejamos los datos en tiempo real. Así que con esto, quería pasar a una definición de Apache Kafka, y sé que las definiciones son realmente aburridas, sin embargo, quería que estuviéramos en la misma línea para que podamos entendernos. Entonces, Apache Kafka es una plataforma de transmisión de eventos que es distribuida, escalable, de alto rendimiento, baja latencia y tiene un ecosistema y una comunidad increíbles. O simplemente dicho, es una plataforma para manejar el transporte de mensajes a través de sus múltiples sistemas. Pueden ser microservicios, dispositivos
IoT, puede ser una tetera en tu cocina enviando información sobre el agua a tu teléfono móvil, cualquier cosa. La plataforma Apache Kafka es distribuida, lo que significa que se basa en múltiples servidores con datos que se replican en múltiples ubicaciones, asegurándose de que si alguno de esos servidores falla, estaremos bien. Nuestros usuarios aún pueden utilizar el sistema. También es escalable, por lo que puedes tener tantos servidores como necesites y pueden manejar billones de mensajes al día, lo que resulta en petabytes de datos almacenados persistentemente en los discos. Y también lo increíble de Apache Kafka es su comunidad y también un amplio ecosistema, incluyendo bibliotecas, verás
JavaScript más adelante en acción, y también los conectores para que no tengas que reinventar la rueda. Ya existen desde hace décadas, por lo que hay muchos conectores que ya están construidos, lo que facilita la conexión de Apache Kafka con tus sistemas también.
Para entender cómo funciona Apache Kafka y, lo que es más importante, cómo podemos trabajar de manera efectiva con Apache Kafka, necesitamos hablar sobre la forma en que Kafka piensa en los datos. Y el enfoque que Kafka adopta es simple, pero también bastante inteligente. En lugar de trabajar con datos en términos de objetos estáticos o hechos finales, un conjunto final de datos que se almacena en una tabla, en una base de datos, Apache Kafka trabaja con entidades descritas por eventos que ocurren continuamente.
En nuestro ejemplo, para nuestra tienda en línea, tenemos algunos productos que estamos vendiendo. Y la información sobre los productos y sus estados se puede almacenar en una tabla, en una base de datos. Y esto nos brinda información valiosa, algunos resultados finales comprimidos. Sin embargo, si después de almacenar los datos surgen más preguntas, no sé, las tendencias de búsqueda, los momentos pico para algunos productos, no puedes detectar realmente esa información a partir de los datos que almacenaste a menos que lo hayas planeado de antemano. Por lo tanto, podemos ver los datos en la tabla como una instantánea comprimida y una vista unidimensional o un solo punto en una línea de tiempo infinita de los datos.
¿Qué tal si en lugar de eso podemos ver estos datos como un flujo de eventos? Por ejemplo, un cliente ordenó una corbata. Otro cliente buscó una dona. Luego enviamos la corbata al primer cliente y el segundo decidió comprar la dona. Y así sucesivamente, tenemos más eventos que llegan al sistema. Entonces, en lugar de ver el punto de datos único, vemos todo el ciclo de vida de la compra del producto. Además, podemos reemplazar esos eventos. No podemos cambiar realmente los eventos pasados, ya sucedieron, pero podemos ir y reemplazarlos una y otra vez, y abordar los datos desde diferentes ángulos y responder todas las preguntas que podamos tener en nuestra mente incluso más adelante. Y esto se llama una arquitectura orientada a eventos, y estoy bastante seguro de que muchos de ustedes están familiarizados con eso. Pero veamos cómo Apache Kafka interactúa con la arquitectura orientada a eventos. Entonces, aquí en el centro puse el clúster, y a la izquierda y a la derecha veremos las aplicaciones que interactúan con el clúster. Apache Kafka coordina el movimiento de datos y se encarga de los mensajes entrantes. Utiliza un modelo de empuje-tirón para trabajar con los datos, lo que significa que por un lado tenemos algunas estructuras que crearán y enviarán los datos al clúster.
4. Producers, Consumers, and Topics
Los productores y consumidores son los componentes clave en Apache Kafka. Los productores son las aplicaciones que los ingenieros escriben y controlan para enviar datos, mientras que los consumidores extraen y leen los datos. Pueden estar escritos en diferentes lenguajes y plataformas, lo que permite un sistema desacoplado. En el clúster, los eventos de diversas fuentes se organizan en temas, que se pueden ver como tablas en una base de datos. Los mensajes dentro de un tema están ordenados y tienen números de desplazamiento. A diferencia de los sistemas de cola tradicionales, los mensajes consumidos en Apache Kafka no se eliminan ni destruyen, lo que permite que múltiples aplicaciones lean los datos repetidamente. Los datos también son inmutables, lo que garantiza la integridad de los datos pasados.
Y esas son las aplicaciones que nosotros, los ingenieros, escribimos y controlamos, y se llaman productores. Por otro lado, tenemos otras estructuras que empujarán los data, extraerán los data, leerán los data y harán lo que necesiten hacer con los data. Se llaman consumidores. Y puedes tener tantos productores y consumidores como necesites. Además, esos consumidores leerán los data del clúster en paralelo. Es un sistema distribuido. Y lo increíble es que aquí en esta imagen, los productores y consumidores pueden estar escritos en diferentes lenguajes. Quiero decir, no todos son fanáticos de Javascript. Así que en realidad puedes mezclar diferentes aplicaciones en diferentes lenguajes y plataformas. Y así es como Apache Kafka ayuda a desacoplar el sistema. Además, cuando envías data con tus productores y algo sucede con tus productores, los consumidores no dependen directamente de los productores. No hay sincronización que se espere. No fui yo. ¿Me escuchas? Sí. Adelante. Y sí. Puedes pausar técnicamente los productores, puedes, por ejemplo, si tus consumidores se caen, está bien, el consumidor se reiniciará y comenzará desde el punto donde se quedó. Porque almacenamos los data persistentemente en los discos, podemos hacer ese tipo de interacciones sin comunicación directa entre productores y consumidores. Ahora que sabemos un poco sobre los productores, consumidores, veamos qué sucede dentro del clúster. Veamos la estructura de los data que tenemos allí. Entonces, un conjunto de eventos que proviene de uno de algunos tipos de fuentes se llama tema. Un tema es en realidad un término abstracto que veremos más adelante, pero digamos que es cómo hablamos de las cosas, no exactamente cómo se almacenan en el disco. Y puedes ver un tema como una tabla en una base de datos, por lo que puedes tener múltiples temas diferentes dentro de tu sistema. Y los mensajes en el tema están ordenados. Esto es en realidad un poco más complejo, lo veremos más adelante, pero todos tienen su número de desplazamiento. Puedes ver un tema como una cola, pero aquí hay un giro. En Apache Kafka, a diferencia de muchos otros sistemas de cola, los mensajes consumidos no se eliminan de la cola ni se destruyen. Puedes leer los data una y otra vez con múltiples aplicaciones diferentes o la misma aplicación si necesitas procesar estos data una vez más. Además, los data son inmutables.
5. Demo de Productores y Consumidores en Apache Kafka
Quería mostrar una demostración rápida usando Apache Kafka. Demostraré productores y consumidores y proporcionaré más experimentos en el repositorio. Podemos crear un productor que se comunique de forma segura con el clúster de Kafka utilizando SSL. Una vez que el productor esté listo, podemos generar y enviar datos al clúster. Para verificar los datos, podemos crear un consumidor utilizando Node-RD Kafka y comenzar a leer los datos.
Entonces, lo que sea que llegue allí, realmente no puedes cambiar el pasado
data. Y es bastante obvio si alguien compró una dona. Realmente no puedes ir al pasado y cambiar ese hecho, a menos que, por supuesto, seas Michael J. Fox y tengas un DeLorean, pero de lo contrario, si no te gusta la dona, tendrás que tirarla. Genial. Con esto, quería mostrar una demostración rápida. De hecho, preparé un repositorio de GitHub donde puedes verificar más cosas más tarde. Mostraré productores y consumidores, pero hay más experimentos en el repositorio que puedes reproducir. Necesitarás un clúster de Apache Kafka. Apache Kafka es un proyecto de código abierto. Puedes configurar el servidor localmente en tu máquina o utilizando
Docker o utilizando una de las versiones administradas disponibles para Apache Kafka. Como trabajo en Ivan, debo mencionar que tenemos Ivan para Apache Kafka, que en realidad puedes probar con una prueba gratuita de Ivan. Creemos un productor. Un productor puede ser como una
lambda función o algo más. Por eso necesita saber dónde se encuentra el clúster. Además, cómo comunicarse con ese clúster de manera segura para que nadie pueda interceptar qué tipo de información estamos intercambiando. Y por eso estamos usando SSL. De hecho, hay diferentes formas de autenticación. Creo que la más común es usar TLS o SSL. Una vez que creamos el productor, podemos iniciarlo y una vez que esté en marcha, hay diferentes eventos a los que puedes suscribirte. El más útil probablemente sea cuando está listo. Es como una vez que el productor está listo, podemos generar
data y comenzar a enviarlo al clúster. Especificamos el nombre del tema, los propios
data, algunos parámetros adicionales que son menos importantes, y también intento hacer que sea un flujo continuo de eventos, así que espero que los dioses de
JavaScript no se ofendan de que esté usando el bucle while true aquí. Y si te preguntas qué tengo en los
data, son solo datos generados para los clientes. Y también en el repositorio encontrarás muchos tipos diferentes de scripts que puedes ejecutar. Entonces, si ejecuto
npm run produce y puedes clonar el repositorio y verlo, comenzamos a enviar los
data. Para verificar que los
data lleguen al clúster, podemos crear el consumidor que es algo similar. Aquí, por cierto, estoy usando Node-RD Kafka, que es un envoltorio alrededor de la biblioteca libRD Kafka. Esa es mi biblioteca favorita de
JavaScript para eso. Y sí, aquí simplemente hacemos de la misma manera. Nosotros
6. Brokers, Partitions, Replication, and Conclusion
Agreguemos un par de conceptos más a la historia: brokers y particiones. Cada partición tiene su propia enumeración para el registro, lo que dificulta el mantenimiento del orden. Las claves se pueden utilizar para garantizar el orden de los mensajes. La replicación es otro concepto importante, con cada broker que contiene réplicas. Siéntete libre de probar Ivan para Apache Kafka con nuestra prueba gratuita.
conectarse al flujo y comenzar a leer los
data. Así que esto es bastante sencillo para la configuración mínima, técnicamente eso es lo que necesitas, no mucho más. Pero agreguemos un par de conceptos más a la historia. Brokers y particiones. Ya mencioné que los clústeres de Kafka consisten en múltiples servidores. Entonces, esos servidores en el mundo de Kafka, los llamamos brokers. Cuando almacenamos los
data en los múltiples servidores, es como un sistema distribuido, por lo que necesitamos dividir nuestro tema en fragmentos. Y lo que haremos, lo dividiremos y llamaremos a esos fragmentos particiones. Y aquí está la parte complicada, como la enumeración que se muestra en la diapositiva se ve muy bien, pero en realidad es una mentira. Porque todas las particiones son entidades independientes. Técnicamente, no puedes tener estos números de desplazamiento en todo el recorrido. Entonces, cada una de las particiones tendrá su propia enumeración para el registro. Y esto dificulta cuando almacenas los
data en diferentes servidores y luego los lees. ¿Cómo mantienes el orden de los registros y te aseguras de que el orden en el que llegaron sea el mismo en el que se van? Para esto, estamos usando claves. Y, por ejemplo, podemos usar un ID de cliente como clave y esto garantiza que podamos garantizar el orden de los mensajes. También mencionar otro concepto importante, la replicación. Sistemas distribuidos. Cada uno de los brokers contendrá no solo los
data de la partición, sino también algunas réplicas. Este es un factor de replicación de dos. Normalmente, en realidad, preferimos tres para que también puedas ocuparte de las ventanas de mantenimiento. Pero en general, sí, tienes
data replicados. Creo que ya se me está acabando el tiempo. Aquí está el enlace, nuevamente, al repositorio. Hay más ejemplos allí con los que puedes jugar con claves y simplemente clonarlo y funcionará. Y también puedes contactarme más tarde si quieres, si tienes alguna pregunta. Y siéntete libre de probar Ivan para Apache Kafka. Tenemos una prueba gratuita para Ivan para Apache Kafka y no necesitas proporcionar los detalles de una tarjeta de crédito ni nada más. Con esto, muchas gracias por escucharme.
7. Introducción a Kafka y GDPR
He oído hablar de Kafka antes, pero eso realmente reforzó muchos de los conceptos. Nuestra primera pregunta tiene que ver con GDPR. ¿Puedes explicar cómo funciona la retención de datos con GDPR? Técnicamente, puedes mantener los datos en Apache Kafka todo el tiempo que necesites, pero es más común consumir y almacenar los datos en otros almacenes de datos. GDPR no tiene mucho impacto aquí, ya que puedes establecer un TTL para eliminar los datos más tarde o comprimirlos por la clave.
En primer lugar, excelente charla. Me encantaron las
animations. Había oído hablar de Kafka antes, pero eso realmente reforzó muchos de los conceptos. Así que sí, eso fue increíble.
Nuestra primera pregunta tiene que ver con GDPR. Entonces hablaste sobre cómo los data son inmutables o cómo los data permanecen durante mucho tiempo. Entonces, ¿cuál es la situación con respecto a la retención de data y GDPR? Hablando técnicamente, y esto probablemente no sea un gran secreto, puedes mantener los data en Apache Kafka todo el tiempo que necesites. Sin embargo, normalmente no los mantendrías allí por mucho tiempo, porque también es probable que consumas los data y los almacenes en otros almacenes de data, como, no sé, lagos de data, si tienes muchos data. Por eso, con GDPR, no hay mucho impacto. También puedes establecer un TTL, por lo que puedes eliminar los data más tarde. También puedes comprimir los data, si lo haces por la clave, puedes mantener solo el elemento
8. Event Removal in Kafka Queue
Los eventos en la cola de Kafka se almacenan de forma persistente y se pueden eliminar según el tiempo, el tamaño o la compresión por clave. La opción predeterminada es almacenar los datos durante un período especificado, como dos semanas. Alternativamente, se puede establecer el tamaño máximo del tema y, cuando se excede, se eliminan los mensajes más antiguos. Otra opción es comprimir los datos por una clave específica, como el ID del cliente, lo que resulta en la eliminación de mensajes más antiguos. Sin embargo, no es posible indicar selectivamente qué eventos eliminar.
con la clave más reciente. Así que sí. Increíble. La siguiente pregunta es, ¿cómo y cuándo se eliminan los eventos en la cola de Kafka, ya que no se eliminan después de ser consumidos? No sé si tenías un ejemplo de eso. ¿Podrías repetirlo? ¿Cómo se eliminan los eventos? ¿Cómo salen de la cola? Se almacenan de forma persistente. Se eliminan cuando llega el momento, por ejemplo, quiero que los
data se almacenen durante dos semanas. En realidad, hay un valor predeterminado allí. O puedes decir que quieres mantener el tamaño máximo del tema y, una vez que se incrementa el tamaño, se comienzan a eliminar los mensajes más antiguos. O quiero comprimir por la clave, por ejemplo, ID del cliente, entonces se eliminan los mensajes más antiguos. Realmente no puedes ir e indicar
9. Consumer Offset and Data Schema in Kafka
Para los consumidores individuales, el desplazamiento realiza un seguimiento de los datos consumidos. Kafka permite almacenar cualquier tipo de datos, pero se recomienda restringirlo. Diferentes formas de restringir los datos incluyen el uso de versiones y evitar formatos de texto o JSON.
cuál eliminar. Eso sería ineficiente. De acuerdo. Supongo que para un consumidor individual, ¿cómo hacen un seguimiento de lo que ya han consumido? Sí. El desplazamiento, que probablemente fue un escenario más complejo, el desplazamiento, así que lo tenemos por partición, y los consumidores saben cómo trabajar con múltiples particiones. Entonces mantendrán qué datos se consumieron. Y por ejemplo, si los consumidores se detienen, se apagan y luego necesitan reiniciarse. Entonces recuerdan los últimos elementos consumidos. De acuerdo. Sí, así es como funciona. ¡Genial! Y hay una pregunta sobre el esquema. Entonces los
data que estás almacenando en los eventos, ¿Kafka requiere, o puedes restringir de alguna manera los
data que almacenas en un esquema, o es de forma libre? En realidad, a Kafka no le importa qué
data almacenes, quiero decir, no deberías almacenar tus películas en streaming, pero cuando se trata de objetos
data normales, puedes almacenar lo que quieras. Estaba usando JSON solo por el amor que le tengo a JSON. Pero en realidad puedes y debes restringir. Y hay diferentes formas de hacerlo, porque técnicamente el esquema evoluciona, así que quieres tener versiones en eso, por lo que realmente no deberías intentar usar formatos de texto o incluso
10. RD Kafka Library and TypeScript Support
La biblioteca RD Kafka es una opción poderosa para JavaScript con una amplia gama de funciones y alto rendimiento. Aunque puede que no sea la más fácil de usar, ofrece un buen soporte de TypeScript y te permite asegurar la conformidad de los eventos con propiedades específicas.
json. Sí, de acuerdo. Esta pregunta es, ¿qué tiene de mejor la biblioteca RD Kafka? Supongo, ¿hay otras? Hay tres o incluso más. Depende de tu caso de uso. Esta es probablemente la decisión más importante que tendrás que tomar si la usas para
JavaScript. Me gusta esta biblioteca porque envuelve la biblioteca completa de Java, por lo que técnicamente admite la mayor cantidad de funciones, y también es la más eficiente, al menos según mi conocimiento. Sin embargo, puede que no sea la más fácil de usar, para ser honesto. Y supongo que el soporte de
TypeScript varía entre ellas, pero la que mostraste, ¿tiene buen soporte de
TypeScript? ¿Se puede pasar un tipo para asegurarse de que los eventos cumplan con esas propiedades? Noté algunas cosas que no me gustaron mucho. Pensé, no, no lo admite, pero está bien. Diría que es mejor que nada.
11. Alternativas a Kafka y Consistencia
Cuando se consideran alternativas a Kafka, depende de tus necesidades de almacenamiento de datos y confiabilidad. Si no necesitas almacenamiento de datos o no te importa perder datos, un sistema de encolado puede ser suficiente. Redis y RabbitMQ se comparan a menudo con Kafka, pero la diferencia clave radica en las capacidades de replicación y almacenamiento persistente de Kafka. Los productores y consumidores en Kafka son entidades separadas, lo que garantiza la consistencia al permitir que los datos se envíen rápidamente y se almacenen. La velocidad y eficiencia del procesamiento de datos puede variar entre los productores y consumidores, pero existen técnicas para optimizar el rendimiento. En comparación, RabbitMQ requiere un desarrollo adicional para garantizar conexiones estables y retención de datos.
¡Genial! Alguien está preguntando, ¿hay alguna alternativa a Kafka o algo que usarías o recomendarías además de Kafka? Creo que depende, porque puedes usar, si realmente no necesitas almacenar los data o no te importa perder data, entonces puedes usar algún sistema de encolado simple porque Kafka es, quiero decir, Kafka es increíble. Creo que puede hacer muchas cosas diferentes, pero también conlleva la responsabilidad de mantener el clúster y cuidar de eso. Si realmente no necesitas todas esas réplicas y un sistema distribuido, simplemente puedes elegir una cola. De acuerdo. Y esto nos lleva a una pregunta similar. ¿Cómo es diferente de algo como Redis? Porque sé que con Redis puedes hacer un sistema de encolado o de mensajería. Creo que con Redis es completamente diferente. Hay RabbitMQ. Ahí es donde generalmente se compara. Redis es una tienda de datos y Kafka es una solución de transmisión. Pero también se pregunta a menudo, ¿cómo es diferente de RabbitMQ, por ejemplo? Y la diferencia radica en la replicación de data, en el almacenamiento persistente de data. Por lo tanto, si realmente no tienes que mantener los data por ti mismo, Kafka lo hace, y también tus productores y consumidores pueden dejar de funcionar aleatoriamente porque está en vivo cuando tus servidores se desconectan y en realidad, es un escenario completamente normal para Apache Kafka. Entonces esa es la mayor diferencia porque admite todo el ecosistema de asegurarse de que no pierdas data en absoluto.
Y eso nos lleva a la siguiente pregunta, que es, ¿cómo garantizas la consistencia entre los productores y consumidores? Bueno, entre los productores y consumidores, son entidades separadas. Los separamos realmente no tienes ese problema. Estoy pensando ahora mismo, realmente no tienes ese problema. Estás en un lado, envías los data. Entonces tu productor solo es responsable de enviar los data rápidamente. Y luego los data se almacenan en el medio, los tienes ahí. Y luego los consumidores, realmente no saben nada acerca de los productores. Realmente no necesitan saber. En realidad, conocen este tipo de tema y luego leen los data uno por uno. Pero tal vez la consistencia es el problema, porque lleva tiempo, ¿verdad? Y a veces algunos de tus consumidores pueden ser lentos. Entonces tal vez la diferencia es cuánto tiempo tardan tus consumidores en procesar los data que fueron producidos por los productores. Quiero decir, probablemente eso también sea muy complejo, pero es como cuánto tiempo lleva, qué tan eficiente es el sistema. Así que puedes medir eso. Y hay diferentes trucos para hacerlo más rápido. De acuerdo. Y una última pregunta para ti, ¿cómo funcionan las colas de mensajes confiables en RabbitMQ, o sea, puedes hacer colas de mensajes confiables en RabbitMQ, ¿eso es diferente de Kafka? Es bastante diferente. Para ser honesto, puede que no profundice tanto en detalle con RabbitMQ, pero con RabbitMQ, tendrás que construir mucho encima para asegurarte de tener una conexión estable entre... Por si algo falla, que no pierdas data. En cambio, creo que Kafka está construido de... Esa es la parte principal, este data replicado y no perderlo. De acuerdo, genial. ¿Podemos aplaudir una vez más a Elena? Muchas gracias, Elena. Gracias. Muchas gracias.
