system de messagerie distribué, broker de message (de base avant de comprendre kafka, rabbitmq)

Bonjour, c’est un codeshow.
Dans ce cours, nous apprendrons le système de messagerie distribué.
Dans un système de messagerie, un message est constitué de données pouvant être échangées entre deux ou plusieurs relations.
Les données ici sont généralement des données binaires. Envoyez et recevez des données à l’aide de sérialiseurs tels que json ou Protocol Buffers.
Avec le système de messagerie au milieu, un côté a une publisher et l’autre côté a une relation d’abonné.
Un publisher est un client qui produit des messages et les soumet à des files d’attente de messages. L’envoi d’un message à une file d’attente est appelé publish .
Un abonné est un client qui reçoit des messages d’une file d’attente de messages. Obtenir des messages de la file d’attente s’appelle consume .
Les messages sont publish par les publisher et les messages transitent par le système de messagerie jusqu’aux abonnés.
Les messages circulent toujours dans un sens : de publisher au système de messagerie et aux abonnés.
Pour référence, nous utilisons les termes producer au lieu d’ publisher et consumer au lieu d’abonné.
De plus, pub et sub sont utilisés en raccourcissant publisher et abonné.

Pour comprendre la relation entre publisher et l’abonné, je vais expliquer le code à titre d’exemple.

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)
}

Dans ce code, un canal de type chaîne est créé dans la fonction main.
La fonction pub publish un caractère “Hello World”.
Et le sous affiche “Hello World” lorsqu’un message arrive dans le canal dans la boucle infinie for.
Dans la fonction pub, nous publish une chaîne sur le canal,
La sous-fonction consume la chaîne via le canal.
Un module qui consume et traite les messages est également appelé un worker.

La relation entre publisher, le système de messagerie et l’abonné a été abordée précédemment.
Dans l’ancien code de langue ci-dessus, la fonction pub agit en publisher et la fonction sub agit en tant qu’abonné.
Et vous pouvez considérer la variable c de type chaîne de chaîne entre ce pub et ce sous comme un système de messagerie.

Si un langage ne fournit pas de messagerie, comme GoLanguage, le framework le fait.
En prenant le Spring Framework de Java comme exemple, il émet des messages de type ApplicationEvent.
Et vous pouvez vous abonner aux messages publish via l’annotation EventListener.
À l’heure actuelle, le système de messagerie est pris en charge par le framework Spring.
Notez que les messages et les événements sont similaires.
La différence entre les deux est que la messagerie stocke généralement les messages dans un stockage appelé file d’attente, afin que les abonnés puissent les traiter plus tard plutôt qu’immédiatement.
Les événements sont envoyés aux abonnés dès qu’ils se produisent et les événements sont détruits.

Comme expliqué ci-dessus, la messagerie dispose d’un stockage appelé File d’attente.
C’est pourquoi il s’appelle Message Queue.

En général, les systèmes de messagerie sont conçus pour la livraison et le traitement des messages dans un environnement distribué.
Ainsi, ni les canaux du langage Go ni les EventListeners de Spring Framework ne sont des systèmes de messagerie dans un contexte limité.
Cependant, les éléments précédents et suivants suivent une architecture événementielle et peuvent être considérés comme des systèmes de messagerie au sens large.

A partir de maintenant, intéressons-nous à kafka et rabbitmq, qui sont les systèmes de messagerie distribués les plus utilisés.

Premièrement, kafka et rabbitmq sont tous deux des systèmes de messagerie qui fonctionnent dans un environnement distribué.
Également appelé broker de message .

Les systèmes de messagerie distribués offrent généralement évolutivité, haute disponibilité et fiabilité.

Pour l’évolutivité, kafka et rabbitmq peuvent configurer un cluster.
Cela permet une mise à l’échelle horizontale en augmentant le nombre de nœuds.
Le débit peut être augmenté grâce à la mise à l’échelle horizontale.
La haute disponibilité signifie que le système de messagerie reste opérationnel même si certains nœuds sont en panne.
La fiabilité est le comportement fiable de la livraison des messages, comme ne pas perdre les messages publiés et ne pas envoyer de messages en double aux abonnés.

kafka et rabbitmq satisfont aux critères ci-dessus en tant que systèmes de messagerie distribués.

Et publisher publish un message à la fois, mais via le système de messagerie, ce message peut être répliqué et distribué à plusieurs queue.

Par exemple,

kafka divise les messages en topic.
Et ce topic est à nouveau divisé en plusieurs partition.
Et du côté des abonnés, plusieurs worker peuvent utiliser un message via des groupes de consumer .

rabbitmq se compose d’un échange et queue.
Les échanges déterminent le routage vers quelles queue les messages sont livrés.
Rabbitmq a 4 types d’échanges : direct, fanout, topic et en-têtes.
Non seulement les messages peuvent être transmis à divers échanges, mais le routage peut également être effectué d’un échange à l’autre.
Comparé à kafka, rabbitmq a une conception de routage de messages très flexible et pratique.

Au lieu de cela, étant donné que rabbitmq est une queue , si un consumer retire un message de la queue , le message est supprimé de la queue.
D’autre part, dans kafka , les unités de stockage sont des topic et des partition , pas des queue .
Une topic est une unité logique qui distingue les messages, et une unité réellement stockée est une partition.
De plus, lorsqu’un consumer consomme des messages d’ une partition, il ne supprime pas les messages comme une queue.
Mémorisez un offset spécifique et abonnez-vous aux données après le offset . C’est comme un tableau.

Dans cette différence, rabbitmq peut attacher plusieurs abonnés à une queue, mais kafka ne peut attacher qu’un seul groupe de consumer à une partition .

La différence entre les deux est aussi la différence de stockage.
rabbitmq est principalement en mémoire et kafka est sur disque.

C’est pourquoi nous utilisons kafka comme magasin de données persistant, comme une base de données.

Cette différence de comportement se reflète dans la conception du système de messagerie en fonction de ce que le système de messagerie vise.
rabbit mq est destiné à la mise en file d’attente des message .
Ainsi, par rapport à kafka, la mise en file d’attente des messages est très flexible en ce qui concerne le routage et la création et la suppression de files d’ queue .
kafka vise le traitement de messages volumineux par rapport à rabbitmq.
Ainsi, par rapport à rabbitmq, il offre des performances supérieures pour le travail par lots de masse.

Ci-dessus, nous avons examiné les systèmes de messagerie distribués et brièvement regardé rabbitmq et kafka.
Nous allons examiner de plus près kafka et rabbitmq à travers le code.

Enfin, nous avons résumé 5 raisons pour lesquelles nous utilisons des systèmes de messagerie.

Communication : les données peuvent être transmises entre publisher et l’abonné. Cela vous libère des contraintes entre les différents langages, plates-formes et hétérogénéités.
Asynchrone : par rapport à la communication synchrone, la communication asynchrone peut augmenter les performances par rapport à la communication procédurale.
Haute disponibilité : Dans un système de messagerie distribué, le fonctionnement normal est garanti même si certains systèmes de messagerie sont en panne, même si les performances peuvent être dégradées.
Réessayer : Même si le worker s’arrête, les messages restent dans la queue, donc si le worker revient, il peut continuer après l’échec de l’opération précédente. Même si le temps réel est réduit, la cohérence des données devient fiable.
Couplage lâche : grâce à des appels indirects via le système de messagerie plutôt qu’à des appels directs, le publisher n’a pas besoin de connaître toute la logique métier après la publication du message. C’est le rôle de publisher uniquement jusqu’à la publication. Le message est ensuite délivré à l’abonné via le système de messagerie. C’est maintenant l’abonné qui est responsable du traitement du message. Le couplage lâche obtenu par des appels indirects, plutôt que directs, des publisher permet à notre logiciel d’être plus flexible et évolutif.

Les paramètres de notification d’abonnement et de like sont très utiles pour les créateurs de contenu.

merci