system de mensajería distribuida, broker de message (básico antes de entender kafka, rabbitmq)

Hola, esto es codeshow.
En esta clase, aprenderemos el sistema de mensajería distribuida.
En un sistema de mensajería, un mensaje son datos que se pueden intercambiar entre dos o más relaciones.
Los datos aquí suelen ser datos binarios. Envíe y reciba datos utilizando serializadores como json o Protocol Buffers.
Con el sistema de mensajería en el medio, un lado tiene una publisher y el otro lado tiene una relación de suscriptor.
Un publisher es un cliente que produce mensajes y los envía a las colas de mensajes. El envío de un mensaje a una cola se denomina publish .
Un suscriptor es un cliente que recibe mensajes de una cola de mensajes. Obtener mensajes de la cola se llama consume .
Los mensajes son publish por publisher y los mensajes viajan a través del sistema de mensajería a los suscriptores.
Los mensajes siempre fluyen en un solo sentido: desde el publisher hasta el sistema de mensajería y los suscriptores.
Como referencia, usamos los términos producer en lugar de publisher y consumer en lugar de suscriptor.
Además, pub y sub se utilizan para acortar publisher y suscriptor.

Para entender la relación entre publisher y suscriptor, explicaré el código como ejemplo.

package main

import "time"

func main() {
    c := make(chan string)
    go pub(c)
    go sub(c)
    select {}
}

func sub(c <-chan string) {
    for {
        message := <-c
        println(message)
    }
}

func pub(c chan<- string) {
    c <- "Hello World 1"
    time.Sleep(1 * time.Second)
    c <- "Hello World 2"
    time.Sleep(1 * time.Second)
    c <- "Hello World 3"
    time.Sleep(1 * time.Second)
    c <- "Hello World 4"
    time.Sleep(24 * time.Hour)
}

En este código, se crea un canal de tipo cadena en la función principal.
La función de pub publish un carácter “Hello World”.
Y el sub emite “Hello World” cuando llega un mensaje al canal en el bucle infinito.
Dentro de la función pub, publish una cadena en el canal,
La función sub consume la cadena a través del canal.
Un módulo que consume y procesa mensajes también se denomina worker.

La relación entre el publisher, el sistema de mensajería y el suscriptor se analizó anteriormente.
En el antiguo código de lenguaje anterior, la función pub actúa como publisher y la subfunción actúa como suscriptor.
Y puede pensar en la variable c del tipo de canal de cadena entre este pub y sub como un sistema de mensajería.

Si un idioma no proporciona mensajería, como GoLanguage, el marco lo hace.
Tomando Spring Framework de Java como ejemplo, emite mensajes de tipo ApplicationEvent.
Y puede suscribirse a los mensajes publish a través de la anotación EventListener.
En este momento, Spring Framework se encarga del sistema de mensajería.
Tenga en cuenta que los mensajes y los eventos son similares.
La diferencia entre los dos es que la mensajería generalmente almacena los mensajes en un almacenamiento llamado Cola, para que los suscriptores puedan procesarlos más tarde en lugar de inmediatamente.
Los eventos se envían a los suscriptores en el momento en que ocurren y los eventos se destruyen.

Como se explicó anteriormente, la mensajería tiene un almacenamiento llamado Cola.
Por eso se llama Message Queue.

En general, los sistemas de mensajería están diseñados para la entrega y el procesamiento de mensajes en un entorno distribuido.
Entonces, ni los canales de Go language ni los EventListeners de Spring Framework son sistemas de mensajería en un contexto limitado.
Sin embargo, tanto el anterior como el siguiente siguen una arquitectura impulsada por eventos y pueden verse como sistemas de mensajería en un sentido amplio.

De ahora en adelante, veamos kafka y rabbitmq, que son los sistemas de mensajería distribuida más utilizados.

En primer lugar, kafka y rabbitmq son sistemas de mensajería que funcionan en un entorno distribuido.
También llamado broker de message .

Los sistemas de mensajería distribuida suelen proporcionar escalabilidad, alta disponibilidad y confiabilidad.

1. Para la escalabilidad, kafka y rabbitmq pueden configurar un cluster.
   Esto permite escalar horizontalmente aumentando el número de nodos.
   El rendimiento se puede aumentar a través de la escala horizontal.
2. Alta disponibilidad significa que el sistema de mensajería permanece operativo incluso si algunos nodos están inactivos.
3. La confiabilidad es el comportamiento confiable de la entrega de mensajes, como no perder los mensajes publicados y no enviar mensajes duplicados a los suscriptores.

kafka y rabbitmq cumplen los criterios anteriores como sistemas de mensajería distribuida.

Y el publisher publish un mensaje a la vez, pero a través del sistema de mensajería, este mensaje se puede replicar y entregar a múltiples queue.

Por ejemplo,

kafka divide los mensajes en topic.
Y este topic se divide de nuevo en varias partition.
Y en el lado del suscriptor, varios worker pueden usar un mensaje a través de grupos de consumer .

rabbitmq consta de intercambio y queue.
Los intercambios determinan el enrutamiento a las queue a las que se entregan los mensajes.
Rabbitmq tiene 4 tipos de intercambios: directo, abanico, topic y encabezados.
No solo se pueden reenviar los mensajes a varios intercambios, sino que también se puede realizar el enrutamiento de un intercambio a otro.
En comparación con kafka, rabbitmq tiene un diseño de enrutamiento de mensajes muy flexible y conveniente.

En cambio, debido a que rabbitmq es una queue , si un consumer retira un mensaje de la queue , el mensaje se elimina de la queue.
Por otro lado, en kafka , las unidades de almacenamiento son topic y partition , no queue .
Un topic es una unidad lógica que distingue los mensajes, y una unidad que realmente se almacena es una partition.
Además, cuando un consumer consume mensajes de una partition, no elimina los mensajes como una queue.
Recuerde una offset específica y suscríbase a los datos después de la offset . Es como una matriz.

En esta diferencia, rabbitmq puede adjuntar múltiples suscriptores a una queue, pero kafka puede adjuntar solo un grupo de consumer a una partition .

La diferencia entre los dos es también la diferencia en el almacenamiento.
rabbitmq está principalmente en la memoria y kafka está en el disco.

Es por eso que usamos kafka como un almacén de datos persistente, como una base de datos.

Esta diferencia de comportamiento se refleja en el diseño del sistema de mensajería según el objetivo del sistema de mensajería.
rabbit mq está dirigido a la cola de message .
Entonces, en comparación con kafka, la cola de mensajes es muy flexible en cuanto al enrutamiento y la creación y eliminación de queue .
kafka está dirigido al procesamiento de mensajes grandes en comparación con rabbitmq.
Por lo tanto, en comparación con rabbitmq, tiene un rendimiento superior para el trabajo por lotes en masa.

Arriba, analizamos los sistemas de mensajería distribuida y analizamos brevemente rabbitmq y kafka.
Echaremos un vistazo más de cerca a kafka y rabbitmq a través del código.

Finalmente, hemos resumido 5 razones por las que usamos sistemas de mensajería.

1. Comunicación: los datos se pueden pasar entre el publisher y el suscriptor. Esto lo libera de las restricciones entre diferentes lenguajes, plataformas y heterogeneidades.
2. Asíncrona: en comparación con la comunicación sincrónica, la comunicación asincrónica puede aumentar el rendimiento en comparación con la comunicación procesal.
3. Alta disponibilidad: en un sistema de mensajería distribuida, se garantiza el funcionamiento normal incluso si algunos sistemas de mensajería no funcionan, aunque el rendimiento puede verse afectado.
4. Reintentar: incluso si el worker se cae, los mensajes permanecen en la queue, por lo que si el worker vuelve a funcionar, puede continuar después de la operación fallida anterior. Incluso si se reduce el tiempo real, la consistencia de los datos se vuelve confiable.
5. Conexión flexible: a través de llamadas indirectas a través del sistema de mensajería en lugar de llamadas directas, el publisher no necesita conocer toda la lógica comercial después de la publicación del mensaje. Es el papel del publisher sólo hasta la publicación. A continuación, el mensaje se entrega al suscriptor a través del sistema de mensajería. Ahora es el suscriptor quien se encarga de manejar el mensaje. El acoplamiento flexible logrado a través de llamadas de publisher indirectas, en lugar de directas, permite que nuestro software sea más flexible y escalable.

La configuración de notificación de suscripción y me gusta es muy útil para los creadores de contenido.

gracias