¿Cuál es la diferencia entre Kafka y Redis OSS?
Redis OSS 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 OSS admite un sistema basado en notificaciones push en el que el publicador distribuye los mensajes a todos los suscriptores cuando se produce un evento.
Cómo funcionan: Kafka en comparación con Pub/sub de Redis OSS
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 OSS 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 OSS para recuperar mensajes.
Aunque puede usar ambos para enviar mensajes de pub/sub, Kafka y Redis OSS 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 OSS
Redis OSS 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 OSS 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 OSS 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 OSS para recibir mensajes. Esto se conoce como semántica de entrega conectada.
Manejo de mensajes: Kafka en comparación con Pub/sub de Redis OSS
Apache Kafka proporciona sistemas de mensajería distribuidos altamente escalables a los desarrolladores. Mientras tanto, Redis OSS 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 OSS funcionan mejor cuando envían paquetes de datos de tamaño pequeño entre consumidores y suscriptores.
Redis OSS, 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 OSS envía automáticamente el mensaje a los suscriptores conectados. Los suscriptores de Redis OSS 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 OSS 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 OSS no almacena los mensajes después de entregarlos. Si no hay suscriptores conectados a la transmisión, Redis OSS descarta los mensajes. Los mensajes descartados no se pueden recuperar, aunque el suscriptor se conecte a Redis OSS más adelante.
Administración de errores
Tanto Kafka como Redis OSS permiten que las aplicaciones mitiguen la entrega de mensajes poco fiable, pero lo hacen de manera diferente.
La administración de errores en Redis OSS se centra en la interacción entre la aplicación cliente y los servicios de Redis OSS. Con Redis OSS, 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 OSS 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 Pub/sub de Redis OSS
En general, Apache Kafka supera a Redis OSS en la mensajería pub/sub porque Kafka se diseñó específicamente para la secuencia de datos. Redis OSS 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 OSS 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 OSS. 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 OSS 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 OSS son adecuados para el procesamiento de datos de baja latencia. Redis OSS 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 OSS lee y escribe datos principalmente en la RAM, naturalmente supera a Kafka en velocidad. Sin embargo, es posible que Redis OSS 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 OSS 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 OSS 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 OSS recomienda ejecutar el sistema de entrega pub/sub en instancias de 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 OSS no hace copias de seguridad de los datos de forma predeterminada y los usuarios deben habilitar la característica manualmente. Redis OSS 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 OSS 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 Pub/sub de Redis OSS
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 OSS 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 OSS 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 OSS |
|
| 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 OSS 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 OSS 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 OSS debe esperar una respuesta antes de enviar un mensaje a otro suscriptor. |
| Latencia |
Baja latencia Un poco más lento que Redis OSS 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 OSS manualmente. Riesgo de pérdida de datos pequeños. |
¿Cómo puede AWS Support cumplir los requisitos de Kafka y Redis OSS?
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. También puede conectarse 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 ofrecer almacenamiento en memoria de alta disponibilidad para las cargas de trabajo de Redis OSS. 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 OSS 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 OSS y Kafka en AWS, cree una cuenta hoy mismo.
