¿Cuál es la diferencia entre Kafka y Redis?
Redis es un almacén de datos clave-valor en memoria, mientras que Apache Kafka es un motor de procesamiento de flujos. Sin embargo, puede comparar las dos tecnologías porque puede usar ambas para crear un sistema de mensajería de publicación-suscripción (pub/sub). En la arquitectura de la nube moderna, las aplicaciones se desacoplan en bloques pequeños e independientes llamados servicios. La mensajería de publicación y suscripción brinda notificaciones de eventos instantánea para dichos sistemas distribuidos. Kafka admite un sistema basado en la extracción en el que los editores y los suscriptores comparten una cola de mensajes común de la que los suscriptores extraen los mensajes que necesitan. Redis admite un sistema basado en notificaciones push en el que el editor distribuye los mensajes a todos los suscriptores cuando se produce un evento.
Cómo funcionan: Kafka en comparación con Redis pub/sub
Apache Kafka es una plataforma de transmisión de eventos que permite que varias aplicaciones transmitan datos de forma independiente unas de otras. Estas aplicaciones, denominadas productores y consumidores, publican y suscriben información desde y hacia ciertas particiones de datos denominadas temas.
Mientras tanto, Redis está diseñada como una base de datos en memoria que admite la transferencia de datos de baja latencia entre aplicaciones. Almacena todos los mensajes en la RAM en lugar de en un disco duro para reducir el tiempo de lectura y escritura de los datos. Al igual que Kafka, varios consumidores pueden suscribirse a una transmisión de Redis para recuperar mensajes.
Aunque puede usar ambos para enviar mensajes de pub/sub, Kafka y Redis funcionan de manera diferente.
Flujo de trabajo Kafka
Apache Kafka conecta a productores y consumidores a través de clústeres de computación. Cada clúster consta de varios corredores de Kafka que residen en servidores diferentes.
Kafka crea temas y particiones para estos fines:
- Temas para agrupar datos similares que pertenecen a un tema de interés, como el correo electrónico, el pago, los usuarios y la compra
- Particiones en diferentes agentes para la replicación de datos y la tolerancia a errores
Los productores publican mensajes para el agente. Cuando el agente recibe un mensaje, clasifica los datos en un tema y los almacena en una partición. Los consumidores se conectan al tema relevante y extraen datos de su partición.
Flujo de trabajo de Redis
Redis se ejecuta con una arquitectura cliente-servidor como un sistema de base de datos NoSQL. Los productores y los consumidores están débilmente acoplados y no tienen que conocerse cuando envían mensajes.
Redis usa claves y nodos primario-secundarios para los siguientes fines:
- Teclas para agrupar mensajes similares. Por ejemplo, “correo electrónico” es una clave que apunta al almacén de datos que contiene solo mensajes de correo electrónico.
- Nodos primario-secundario para la replicación de mensajes.
Cuando un productor envía un mensaje a un nodo específico, Redis envía el mensaje a todos los suscriptores conectados comprobando la clave del mensaje. El consumidor siempre debe iniciar y mantener una conexión activa con el servidor de Redis para recibir mensajes. Esto se conoce como semántica de entrega conectada.
Manejo de mensajes: Kafka en comparación con Redis pub/sub
Apache Kafka proporciona sistemas de mensajería distribuidos altamente escalables a los desarrolladores. Mientras tanto, Redis ofrece estructuras de datos enriquecidas que permiten a una aplicación enviar datos rápidamente a varios nodos. Ambos sistemas tienen varias diferencias en sus mecanismos de cola de mensajes.
Tamaño del mensaje
Kafka y Redis funcionan mejor cuando envían paquetes de datos de tamaño pequeño entre consumidores y suscriptores.
Redis, en particular, no está diseñado para administrar datos de gran tamaño sin comprometer el rendimiento. Tampoco puede almacenar grandes cantidades de datos, ya que la RAM tiene una capacidad menor que el almacenamiento en disco.
Mientras tanto, Kafka puede admitir mensajes razonablemente grandes a pesar de no estar diseñado específicamente para hacerlo. Kafka puede administrar mensajes de hasta 1 GB si comprime el mensaje y lo configura para un almacenamiento por niveles. En lugar de almacenar todos los mensajes en el almacenamiento local, utiliza el almacenamiento remoto para almacenar los archivos de registro completos.
Entrega de mensajes
Los consumidores de Kafka extraen los datos de la cola de mensajes. Cada consumidor de Kafka lleva un registro del mensaje que ha leído con un offset, que se actualiza para recuperar el mensaje siguiente. Los consumidores pueden detectar y rastrear los mensajes duplicados.
Por otro lado, Redis envía automáticamente el mensaje a los suscriptores conectados. Los suscriptores de Redis esperan pasivamente los mensajes entrantes que reciban desde el servidor. Como se trata de una configuración de entrega de una vez como máximo, los suscriptores de Redis no pueden detectar mensajes duplicados.
Retención de mensajes
Kafka retiene los mensajes después de que los consumidores los leen. Por lo tanto, si una aplicación cliente pierde los datos recuperados, puede volver a solicitar esos datos de la partición a la que se suscribe. Cuando establecen la política de retención de mensajes, los usuarios pueden determinar durante cuánto tiempo Kafka retendrá los datos.
Por el contrario, Redis no almacena los mensajes después de entregarlos. Si no hay suscriptores conectados a la transmisión, Redis descarta los mensajes. Los mensajes descartados no se pueden recuperar, aunque el suscriptor se conecte a Redis más adelante.
Administración de errores
Tanto Kafka como Redis permiten que las aplicaciones mitiguen la entrega de mensajes poco fiable, pero lo hacen de manera diferente.
La administración de errores en Redis se centra en la interacción entre la aplicación cliente y los servicios de Redis. Con Redis, los desarrolladores pueden abordar circunstancias como el tiempo de espera de los clientes, el búfer de memoria excedido y los límites máximos de los clientes. Debido a su arquitectura de base de datos de pares clave-valor, Redis no puede proporcionar una administración sólida de los errores de mensajes como lo hace Kafka.
Los desarrolladores de Kafka pueden almacenar eventos erróneos en una cola de mensajes fallidos, volver a intentarlo o redirigirlos para permitir una entrega coherente de los mensajes a las aplicaciones cliente. Los desarrolladores también pueden usar la API de Kafka Connect para reiniciar automáticamente las tareas del conector en caso de ciertos errores.
Obtenga más información sobre las colas de mensajes fallidos »
Diferencias de rendimiento: Kafka en comparación con Redis pub/sub
En general, Apache Kafka supera a Redis en la mensajería pub/sub porque Kafka se diseñó específicamente para la secuencia de datos. Redis tiene varios casos de uso diferentes en los que no se puede usar Kafka.
Paralelismo
El paralelismo es la capacidad de varios consumidores de recibir el mismo mensaje simultáneamente.
Redis no admite el paralelismo.
Por otro lado, Kafka permite que el mismo mensaje se distribuya a varios consumidores al mismo tiempo. Por lo general, los consumidores de los grupos de consumidores de Kafka se turnan para recuperar los mensajes nuevos de una partición. Si solo hay un consumidor en varios grupos de consumidores, recupera todos los mensajes. Si se aprovechan esta configuración y la replicación de particiones, se puede asignar un consumidor a cada grupo de consumidores en cada réplica de partición. Esto permite a todos los consumidores recuperar una secuencia similar de mensajes.
Rendimiento
El rendimiento mide la cantidad de mensajes que cada sistema puede procesar por segundo.
En general, Kafka tiene un rendimiento superior al pub/sub de Redis. Kafka gestiona volúmenes de datos mucho mayores porque no tiene que esperar a que cada suscriptor reciba el mensaje antes de pasar a otro. En su lugar, almacena los mensajes actuales en una memoria caché y almacenamiento, lo que optimiza la velocidad de lectura.
Sin embargo, el rendimiento de Kafka puede disminuir si los consumidores no recuperan el mensaje lo suficientemente rápido, ya que los mensajes no leídos de la memoria caché acaban por eliminarse. En este caso, los consumidores deben leer desde el disco, lo que es más lento.
Mientras tanto, Redis debe esperar la confirmación de cada consumidor, lo que reduce significativamente su rendimiento con más nodos conectados. Una solución alternativa es enviar varias solicitudes con un proceso llamado canalización, pero esto reduce la latencia de los mensajes.
Latencia
Tanto Kafka como Redis son adecuados para el procesamiento de datos de baja latencia. Redis ofrece un tiempo de mensajería más bajo, que varía en milisegundos, mientras que Kafka tiene un promedio de decenas de milisegundos.
Si se tiene en cuenta que Redis lee y escribe datos principalmente en la RAM, naturalmente supera a Kafka en velocidad. Sin embargo, es posible que Redis no mantenga operaciones de datos de latencia ultrabaja cuando administra mensajes más grandes. Mientras tanto, Kafka necesita más tiempo para replicar particiones en diferentes unidades físicas para la persistencia de los datos, lo que aumenta la sobrecarga del tiempo de entrega de los mensajes.
Es posible optimizar la latencia para Redis y Kafka, pero se debe hacer con cuidado. Por ejemplo, se pueden comprimir los mensajes de Kafka para reducir la latencia, pero los productores y los consumidores necesitan más tiempo para descomprimirlos.
La latencia en Redis puede deberse a varios factores, como el entorno operativo, las operaciones de red, la lentitud de los comandos o la bifurcación. Para reducir los retrasos en la bifurcación, Redis recomienda ejecutar el sistema de entrega pub/sub en instancias EC2 modernas basadas en una máquina virtual de hardware (HVM).
Tolerancia a errores
Kafka escribe todos los datos en el disco de almacenamiento de un agente líder y los replica en diferentes servidores. Cuando un servidor falla, varios suscriptores recuperan los datos de las particiones de respaldo.
A diferencia de Kafka, Redis no hace copias de seguridad de los datos de forma predeterminada y los usuarios deben habilitar la característica manualmente. Redis usa el almacén de datos en memoria, que pierde todos los datos cuando se apaga. Para evitarlo, los desarrolladores activan la persistencia de Redis Database (RDB) para capturar periódicamente instantáneas de los datos de la RAM y almacenarlos en el disco.
Cuándo utilizarlos: Kafka en comparación con Redis pub/sub
Apache Kafka es la mejor opción para crear aplicaciones que transmitan grandes conjuntos de datos y requieran una alta capacidad de recuperación. Inicialmente se desarrolló como una única canalización de datos distribuidos capaz de gestionar billones de mensajes que pasan por allí. Kafka replica las particiones en diferentes servidores para evitar la pérdida de datos cuando se produce un error en un nodo. Las organizaciones utilizan Kafka para permitir la comunicación en tiempo real entre aplicaciones, dispositivos móviles de Internet de las cosas (IoT) y microservicios. También es la mejor opción para la agregación de registros, el procesamiento de transmisiones y otras tareas de integración de datos basadas en la nube.
Mientras tanto, Redis proporciona una distribución de eventos de latencia ultrabaja para aplicaciones que requieren una transferencia de datos instantánea pero que toleran pequeñas pérdidas de datos. Redis se usa comúnmente como caché de sesión para almacenar datos a los que se accede con frecuencia o enviar mensajes urgentes. También es adecuado para almacenar datos de juegos, comercio electrónico o redes sociales para permitir una experiencia de usuario más fluida.
Resumen de las diferencias: Kafka en comparación con Redis pub/sub
| Apache Kafka |
Redis |
|
| Tamaño del mensaje |
Admite mensajes de hasta 1 GB con compresión y almacenamiento por niveles. |
Admite mensajes de tamaño más pequeño. |
| Entrega de mensajes |
Los suscriptores extraen los mensajes de la cola. |
El servidor Redis envía mensajes a los suscriptores conectados. |
| Retención de mensajes |
Retiene los mensajes después de recuperarlos. |
No retiene los mensajes. |
| Administración de errores |
Gestiona de manera sólida los errores a nivel de mensajería. Cola de mensajes fallidos, reintentos de eventos y redireccionamiento. |
Se deben gestionar las excepciones de Redis a nivel de aplicación con tiempos de espera, límites de clientes y capacidad del búfer de memoria. |
| Paralelismo |
Kafka admite el paralelismo. Varios consumidores pueden recuperar el mismo mensaje al mismo tiempo. |
No admite el paralelismo. |
| Desempeño |
Tiene un rendimiento más alto debido a la lectura o escritura asincrónica. |
Presenta un menor rendimiento debido a que el servidor Redis debe esperar una respuesta antes de enviar un mensaje a otro suscriptor. |
| Latencia |
Baja latencia Un poco más lento que Redis debido a la replicación de datos predeterminada. |
Presenta una latencia ultrabaja cuando distribuye mensajes de menor tamaño. |
| Tolerancia a errores |
Hace copias de seguridad automáticas de las particiones para diferentes agentes. |
No hace copias de seguridad de forma predeterminada. Los usuarios pueden habilitar la persistencia de Redis manualmente. Riesgo de pérdida de datos pequeños. |
¿Cómo puede AWS Support cumplir los requisitos de Kafka y Redis?
Amazon Web Services (AWS) proporciona una infraestructura escalable y administrada para satisfacer sus necesidades de mensajería de publicación y suscripción (pub/sub).
Utilice Amazon Managed Streaming para Apache Kafka (Amazon MSK) para incorporar y procesar fácilmente grandes volúmenes de datos en tiempo real. Puede crear un bus de datos de acceso privado para proporcionar nodos de streaming de alta disponibilidad a escala. Además, se puede conectar sin problemas con otros servicios de AWS, como AWS IoT Core, Amazon Virtual Private Cloud (Amazon VPC) y Amazon Managed Service para Apache Flink.
Utilice Amazon MemoryDB para disponer de almacenamiento en memoria de alta disponibilidad para las cargas de trabajo de Redis. Puede ejecutar fuentes de datos de streaming de alta concurrencia para incorporar la actividad de los usuarios. Además, puede admitir millones de solicitudes diarias de aplicaciones multimedia y de entretenimiento.
En lugar de Redis o Kafka, también puede utilizar Amazon Simple Notification Service (Amazon SNS) para crear un sistema de mensajería pub/sub. Puede enviar mensajes desde las aplicaciones directamente a clientes u otras aplicaciones de forma escalable y rentable. Amazon SNS ofrece varias características, como las siguientes:
- Mensajería de varios a varios de alto rendimiento basada en push entre sistemas distribuidos, microservicios y aplicaciones sin servidor basadas en eventos
- Cifrado de mensajes y privacidad del tráfico
- Distribución ramificada de las capacidades en todas las categorías de AWS Esto incluye análisis, computación, contenedores, bases de datos, Internet de las cosas (IoT), machine learning (ML), seguridad y almacenamiento.
Para comenzar a utilizar pub/sub, Redis y Kafka en AWS, cree una cuenta hoy mismo.
