Kafka learning-el segundo concepto básico

1. Descripción general

Kafka fue desarrollado originalmente por Linkedin, es un suscriptor distribuido, particionado, multicopia y multicopa, basado en el sistema de registro distribuido coordinado por zookeeper (también se puede usar como un sistema MQ). Registros, servicios de mensajería, etc., Linkedin contribuyó a la Fundación Apache en 2010 y se convirtió en un proyecto de código abierto de alto nivel.

Los principales escenarios de aplicación son: sistema de recopilación de registros y sistema de mensajes.

Los principales objetivos de diseño de Kafka son los siguientes:

• La capacidad de persistencia del mensaje se proporciona con una complejidad de tiempo de O (1), y el rendimiento de acceso en tiempo constante puede garantizarse incluso para datos por encima del nivel de terabytes.
• Alto rendimiento Incluso en máquinas comerciales muy baratas, puede lograr la transmisión de mensajes de 100K por segundo en una sola máquina.
• Admite la partición de mensajes entre servidores Kafka y el consumo distribuido, al tiempo que garantiza la transmisión secuencial de mensajes dentro de cada partición.
• También es compatible con el procesamiento de datos fuera de línea y el procesamiento de datos en tiempo real.
• Escalar horizontalmente: admite la expansión horizontal en línea.

2. Ventajas de kafka

2.1 Desacoplamiento

Es extremadamente difícil predecir qué necesidades encontrará el proyecto al comienzo del proyecto. El sistema de mensajes inserta una capa de interfaz implícita basada en datos en el medio del proceso, y el proceso en ambos lados debe implementar esta interfaz. Esto le permite extender o modificar independientemente el procesamiento en ambos lados, siempre que se asegure de que cumplan con las mismas restricciones de interfaz.

2.2 Redundancia (copia)

En algunos casos, el proceso de procesamiento de datos fallará. A menos que los datos sean persistentes, causarán pérdidas. La cola de mensajes conserva los datos hasta que se hayan procesado por completo, lo que evita el riesgo de pérdida de datos. En el paradigma de "insertar-obtener-eliminar" adoptado por muchas colas de mensajes, antes de eliminar un mensaje de la cola, su sistema de procesamiento debe indicar claramente que el mensaje ha sido procesado, para garantizar que sus datos se guarden de forma segura. Hasta que termines de usarlo.

2.3 Escalabilidad

Debido a que la cola de mensajes desacopla su procesamiento, es fácil aumentar la frecuencia de procesamiento y procesamiento de mensajes, siempre que agregue procesamiento adicional. No se requieren cambios de código ni ajustes de parámetros. La expansión es tan simple como subir el botón de encendido.

2.4 Flexibilidad y capacidad de procesamiento pico

En el caso de un rápido aumento en el acceso, las aplicaciones aún deben seguir desempeñando un papel, pero este tráfico de ráfaga no es común; sin duda, es un gran desperdicio invertir recursos en modo de espera para poder manejar ese acceso máximo como estándar. El uso de colas de mensajes puede permitir que los componentes críticos resistan presiones de acceso repentinas, sin que se bloqueen por completo debido a solicitudes repentinas sobrecargadas.

2.5 Recuperación

Cuando una parte del sistema falla, no afectará a todo el sistema. La cola de mensajes reduce el acoplamiento entre procesos, por lo que incluso si un proceso que procesa mensajes cuelga, los mensajes agregados a la cola aún pueden procesarse después de que se restaura el sistema.

2.6 Garantía de pedido

En la mayoría de los escenarios de uso, el orden del procesamiento de datos es muy importante. La mayoría de las colas de mensajes se ordenan originalmente y pueden garantizar que los datos se procesarán en un orden específico. Kafka garantiza el orden de los mensajes dentro de una Partición.

2.7 Buffer

En cualquier sistema importante, habrá elementos que requieren diferentes tiempos de procesamiento. Por ejemplo, lleva menos tiempo cargar una imagen que aplicar un filtro. La puesta en cola de mensajes utiliza una capa de búfer para ayudar a que la ejecución más eficiente del procesamiento de cola de escritura de tareas sea lo más rápida posible. Este búfer ayuda a controlar y optimizar la velocidad del flujo de datos a través del sistema.

2.8 Comunicación asincrónica

Muchas veces, los usuarios no quieren y necesitan procesar mensajes de inmediato. La cola de mensajes proporciona un mecanismo de procesamiento asincrónico que permite a los usuarios poner un mensaje en la cola, pero no lo procesa de inmediato. Ponga tantos mensajes como desee en la cola y luego procéselos cuando sea necesario.

3. Comparación de la cola de mensajes de uso común

3.1 RabbitMQ

RabbitMQ es una cola de mensajes de código abierto escrita en Erlang. Admite muchos protocolos: AMQP, XMPP, SMTP, STOMP. Debido a esto, es muy pesado y más adecuado para el desarrollo a nivel empresarial. Al mismo tiempo, se implementa el marco Broker, lo que significa que los mensajes se ponen en cola en la cola central antes de enviarse al cliente. Tiene buen soporte para enrutamiento, equilibrio de carga o persistencia de datos.

3.2 Redis

Redis es una base de datos NoSQL basada en pares clave-valor, y el desarrollo y el mantenimiento son muy activos. Aunque es un sistema de almacenamiento de base de datos de valor clave, en sí mismo admite funciones MQ, por lo que puede usarse como un servicio de cola ligero. Para las operaciones en cola y en cola de RabbitMQ y Redis, cada una se ejecuta 1 millón de veces, y el tiempo de ejecución se registra cada 100,000 veces. Los datos de prueba se dividen en cuatro tamaños de datos diferentes: 128 Bytes, 512 Bytes, 1K y 10K. Los experimentos muestran que al ingresar al equipo, el rendimiento de Redis es más alto que RabbitMQ cuando los datos son relativamente pequeños, y si el tamaño de los datos supera los 10K, Redis es insoportablemente lento; al abandonar el equipo, Redis muestra un rendimiento muy bueno independientemente del tamaño de los datos , Y el rendimiento decadente de RabbitMQ es mucho más bajo que Redis.

3.3 ZeroMQ

ZeroMQ es conocido como el sistema de colas de mensajes más rápido, especialmente para escenarios de demanda de alto rendimiento. ZeroMQ puede implementar colas avanzadas / complejas en las que RabbitMQ no es bueno, pero los desarrolladores necesitan combinar múltiples marcos técnicos ellos mismos. La complejidad técnica es un desafío para el éxito de esta aplicación MQ. ZeroMQ tiene un modo único de no middleware, no necesita instalar y ejecutar un servidor de mensajes o middleware, porque su aplicación desempeñará este rol de servidor. Solo necesita citar la biblioteca ZeroMQ, que se puede instalar usando NuGet, y luego puede enviar mensajes entre aplicaciones con gusto. Sin embargo, ZeroMQ solo proporciona colas no persistentes, lo que significa que si se cae, los datos se perderán. Entre ellos, las versiones Storm de Twitter anteriores a 0.9.0 usan ZeroMQ como transmisión de flujo de datos de forma predeterminada (Storm admite ZeroMQ y Netty como módulos de transmisión de la versión 0.9).

3.4 ActiveMQ

ActiveMQ es un subproyecto bajo Apache. Al igual que ZeroMQ, puede implementar colas con agentes y tecnologías punto a punto. Al mismo tiempo, similar a RabbitMQ, puede implementar de manera eficiente escenarios de aplicaciones avanzadas con una pequeña cantidad de código.

3.5 Kafka/Jafka

Kafka es un subproyecto de Apache. Es un sistema de colas de mensajes de publicación / suscripción distribuido en varios idiomas de alto rendimiento. Jafka se incuba en Kafka, que es una versión mejorada de Kafka. Tiene las siguientes características: persistencia rápida, persistencia de mensajes bajo O (1) sobrecarga; alto rendimiento, que puede alcanzar una tasa de rendimiento de 10W / s en un servidor común; sistema completamente distribuido, Broker , Productor y Consumidor admiten automáticamente el equilibrio distribuido y de carga automáticamente; admiten la carga paralela de datos Hadoop. Para los datos de registro y los sistemas de análisis fuera de línea como Hadoop, pero requieren limitaciones de procesamiento en tiempo real, esta es una solución factible . Kafka unifica el procesamiento de mensajes en línea y fuera de línea a través del mecanismo de carga paralela de Hadoop. En comparación con ActiveMQ, Apache Kafka es un sistema de mensajería muy liviano y, además de su muy buen rendimiento, también es un sistema distribuido que funciona bien.

4. Arquitectura y terminología.

4.1 Arquitectura de Kafka

Como se muestra en la figura anterior, un clúster típico de Kafka contiene varios Productores (que pueden ser Vista de página generada por el front-end web, o registros del servidor, CPU del sistema, Memoria, etc.) y varios Corredores (Kafka admite la expansión horizontal, generalmente cuanto mayor es el número de corredores, Cuanto mayor sea la tasa de rendimiento del clúster), varios grupos de consumidores y un clúster Zookeeper. Kafka gestiona la configuración del clúster a través de Zookeeper, elige al líder y reequilibra cuando cambia el grupo de consumidores. El productor usa el modo push para publicar mensajes a los corredores, y el consumidor usa el modo pull para suscribirse y consumir mensajes de los corredores.

4.2 Explicación de términos

• Corredor

El clúster de Kafka contiene uno o más servidores, y los nodos del servidor se denominan intermediarios.

El corredor almacena datos de temas. Si un tema tiene N particiones y el clúster tiene N intermediarios, entonces cada intermediario almacena una partición del tema.

Si un tema tiene N particiones y el clúster tiene intermediarios (N + M), entonces hay N intermediarios que almacenan una partición del tema, y ​​los intermediarios M restantes no almacenan datos de partición del tema.

Si un tema tiene N particiones y el número de intermediarios en el clúster es menor que N, entonces un intermediario almacena una o más particiones del tema. En el entorno de producción real, intente evitar esta situación, que puede conducir fácilmente a datos de clúster Kafka desequilibrados.

• Tema

Cada mensaje publicado en el clúster Kafka tiene una categoría, que se llama Tema. (Físicamente, los mensajes de diferentes temas se almacenan por separado. Aunque lógicamente, los mensajes de un tema se almacenan en uno o más intermediarios, pero los usuarios solo necesitan especificar el tema del mensaje para producir o consumir datos sin tener que preocuparse de dónde se almacenan los datos)

• Dividir

Los datos en el tema se dividen en una o más particiones. Cada tema tiene al menos una partición. Los datos en cada partición se almacenan utilizando archivos de múltiples segmentos. Los datos en la partición se ordenan, y los datos entre diferentes particiones pierden el orden de los datos. Si un tema tiene múltiples particiones, no se puede garantizar el orden de los datos cuando se consumen datos. En el escenario donde el orden de consumo de mensajes debe garantizarse estrictamente, el número de particiones debe establecerse en 1.

• Réplica

1. Cuando el factor de replicación de un tema es N y N es mayor que 1, cada partición tendrá N réplicas (réplica). La réplica de Kafka contiene líder y seguidor.
2. El número de réplicas es menor o igual que el número de intermediario, es decir, para cada partición, habrá como máximo una réplica en cada intermediario, por lo que puede usar la identificación del intermediario para especificar la réplica de la partición.
3. La réplica de todas las particiones se distribuirá uniformemente a todos los intermediarios de forma predeterminada.

• Productor

El productor es el editor de los datos, y este rol publica el mensaje sobre el tema de Kafka. Después de que el intermediario recibe el mensaje enviado por el productor, el intermediario agrega el mensaje al archivo de segmento utilizado actualmente para adjuntar datos. El mensaje enviado por el productor se almacena en una partición, y el productor también puede especificar la partición para el almacenamiento de datos.

• Consumidor

Los consumidores pueden leer datos del corredor. Los consumidores pueden consumir datos de múltiples temas.

• Grupo de consumidores

Cada consumidor pertenece a un grupo de consumidores específico (puede especificar el nombre del grupo para cada consumidor o el grupo predeterminado si no especifica el nombre del grupo).

• Líder

Cada partición tiene múltiples copias, una y solo una de las cuales es el líder, que actualmente es la partición responsable de leer y escribir datos.

• Seguidor

El seguidor sigue al líder, todas las solicitudes de escritura se enrutan a través del líder, los datos se transmitirán a todos los seguidores, el seguidor y el líder mantienen la sincronización de datos. Si el líder falla, se elige un nuevo líder del seguidor. Cuando el seguidor y el líder cuelgan, se atascan o se sincronizan demasiado lentamente, el líder eliminará este seguidor de la lista "Réplicas en sincronización" (ISR) y volverá a crear un seguidor.