Verteiltes Messaging- system, message broker (Grundlagen vor dem Verständnis von kafka, rabbitmq)

Hallo, das ist codeshow.
In diesem Kurs lernen wir das verteilte Messaging-System kennen.
In einem Nachrichtensystem sind Nachrichten Daten, die zwischen zwei oder mehr Beziehungen ausgetauscht werden können.
Die Daten hier sind normalerweise binäre Daten. Senden und empfangen Sie Daten mit Serializern wie json oder Protocol Buffers.
Mit dem Nachrichtensystem in der Mitte hat eine Seite eine publisher und die andere Seite eine Abonnentenbeziehung.
Ein publisher ist ein Client, der Nachrichten erstellt und an Nachrichtenwarteschlangen sendet. Das Senden einer Nachricht an eine Warteschlange wird als publish bezeichnet.
Ein Abonnent ist ein Client, der Nachrichten aus einer Nachrichtenwarteschlange empfängt. Das Abrufen von Nachrichten aus der Warteschlange wird als consume bezeichnet.
Nachrichten werden von publisher publish , und Nachrichten werden über das Nachrichtensystem an die Abonnenten weitergeleitet.
Nachrichten fließen immer in eine Richtung: vom publisher zum Nachrichtensystem zu den Abonnenten.
Zur Bezugnahme verwenden wir die Begriffe producer statt publisher und consumer statt Subscriber.
Darüber hinaus werden Pub und Sub verwendet, um publisher und Subscriber zu kürzen.

Um die Beziehung zwischen publisher und Abonnent zu verstehen, erkläre ich den Code als Beispiel.

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

In diesem Code wird in der Hauptfunktion ein Kanal vom Typ String erstellt.
Die Pub-Funktion publish ein „Hello World“-Zeichen.
Und der Sub gibt “Hello World” aus, wenn eine Nachricht im Kanal in der Endlosschleife ankommt.
Innerhalb der Pub-Funktion publish wir eine Zeichenfolge für den Kanal,
Die Unterfunktion consume die Zeichenfolge durch den Kanal.
Ein Modul, das Nachrichten consume und verarbeitet, wird auch als worker bezeichnet.

Die Beziehung zwischen publisher, Messagingsystem und Abonnent wurde bereits besprochen.
Im obigen alten Sprachcode fungiert die pub-Funktion als publisher und die sub-Funktion als Abonnent.
Und Sie können sich die c-Variable des String-Kanaltyps zwischen diesem Pub und Sub als Messaging-System vorstellen.

Wenn eine Sprache keine Nachrichten bereitstellt, wie GoLanguage, tut es das Framework.
Am Beispiel des Spring Framework von Java werden Nachrichten vom Typ ApplicationEvent ausgegeben.
Und Sie können publish Nachrichten über die EventListener-Annotation abonnieren.
Zu diesem Zeitpunkt wird das Messaging-System vom Spring-Framework übernommen.
Beachten Sie, dass Nachrichten und Ereignisse ähnlich sind.
Der Unterschied zwischen den beiden besteht darin, dass Messaging Nachrichten normalerweise in einem Speicher namens Warteschlange speichert, sodass Abonnenten sie später und nicht sofort verarbeiten können.
Ereignisse werden in dem Moment, in dem sie auftreten, an die Abonnenten gesendet, und Ereignisse werden zerstört.

Wie oben erläutert, hat Messaging einen Speicher namens Queue.
Deshalb heißt es Message Queue.

Im Allgemeinen sind Messaging-Systeme für die Übermittlung und Verarbeitung von Nachrichten in einer verteilten Umgebung ausgelegt.
Weder die Kanäle der Go-Sprache noch die EventListener von Spring Framework sind also Messaging-Systeme in einem begrenzten Kontext.
Jedoch folgen sowohl das vorangehende als auch das folgende einer ereignisgesteuerten Architektur und können im weiteren Sinne als Messaging-Systeme angesehen werden.

Schauen wir uns von nun an kafka und rabbitmq an, die am häufigsten verwendeten verteilten Messaging-Systeme.

Erstens sind kafka und rabbitmq beide Messaging-Systeme, die in einer verteilten Umgebung arbeiten.
Auch message broker .

Verteilte Nachrichtensysteme bieten typischerweise Skalierbarkeit, hohe Verfügbarkeit und Zuverlässigkeit.

1. Für die Skalierbarkeit können kafka und rabbitmq einen cluster konfigurieren.
   Dies ermöglicht eine horizontale Skalierung, indem die Anzahl der Knoten erhöht wird.
   Durch horizontale Skalierung kann der Durchsatz gesteigert werden.
2. Hochverfügbarkeit bedeutet, dass das Messaging-System auch dann betriebsbereit bleibt, wenn einige Knoten ausfallen.
3. Zuverlässigkeit ist das zuverlässige Verhalten der Nachrichtenzustellung, wie z. B. kein Verlust veröffentlichter Nachrichten und kein Senden doppelter Nachrichten an Abonnenten.

kafka und rabbitmq erfüllen die oben genannten Kriterien als verteilte Messaging-Systeme.

Und der publisher publish jeweils eine Nachricht, aber über das Nachrichtensystem kann diese Nachricht repliziert und an mehrere queue übermittelt werden .

Zum Beispiel,

kafka teilt Botschaften in topic ein.
Und dieses topic ist wieder in mehrere partition unterteilt.
Und auf der Abonnentenseite können mehrere worker eine Nachricht über consumer verwenden.

rabbitmq besteht aus exchange und queue.
Exchanges bestimmen das Routing, an welche queue Nachrichten übermittelt werden.
Rabbitmq hat 4 Arten von Austausch: direkt, Fanout, topic und Header.
Es können nicht nur Nachrichten an verschiedene Vermittlungsstellen weitergeleitet werden, sondern es kann auch ein Routing von Vermittlungsstelle zu Vermittlungsstelle durchgeführt werden.
Im Vergleich zu kafka hat rabbitmq ein sehr flexibles und praktisches Nachrichtenrouting-Design.

Da es sich bei rabbitmq um eine queue handelt, wird die Nachricht stattdessen aus der queue entfernt, wenn ein consumer eine Nachricht aus der queue entfernt.
Andererseits sind die Speichereinheiten in kafka topic und partition , keine queue .
Ein topic ist eine logische Einheit, die Nachrichten unterscheidet, und eine tatsächlich gespeicherte Einheit ist eine partition.
Wenn ein consumer Nachrichten aus einer partition verarbeitet, löscht er außerdem keine Nachrichten wie eine queue.
Erinnern Sie sich an einen bestimmten offset und abonnieren Sie Daten nach dem offset . Es ist wie ein Array.

In diesem Unterschied kann rabbitmq mehrere Abonnenten an eine queue anhängen, aber kafka kann nur eine consumer an eine partition anhängen.

Der Unterschied zwischen den beiden ist auch der Unterschied in der Lagerung.
rabbitmq befindet sich hauptsächlich im Speicher und kafka befindet sich auf der Festplatte.

Deshalb verwenden wir kafka als persistenten Datenspeicher, wie eine Datenbank.

Dieser Unterschied im Verhalten spiegelt sich im Design des Messaging-Systems wider, je nachdem, was das Messaging-System vorhat.
rabbit mq zielt auf message Queuing ab.
Im Vergleich zu kafka ist Message Queuing also sehr flexibel in Bezug auf das Routing sowie das Erstellen und Löschen von queue .
kafka zielt im Vergleich zu rabbitmq auf die Verarbeitung großer Nachrichten ab.
Im Vergleich zu rabbitmq hat es also eine überlegene Leistung für Massenstapelarbeit.

Oben haben wir uns verteilte Messaging-Systeme angesehen und uns kurz rabbitmq und kafka angesehen.
Wir werden uns kafka und rabbitmq durch Code genauer ansehen.

Abschließend haben wir 5 Gründe zusammengefasst, warum wir Messaging-Systeme verwenden.

1. Kommunikation: Daten können zwischen publisher und Abonnent ausgetauscht werden. Dies befreit Sie von Zwängen zwischen verschiedenen Sprachen, Plattformen und Heterogenitäten.
2. Asynchron: Im Vergleich zur synchronen Kommunikation kann die asynchrone Kommunikation die Leistung im Vergleich zur prozeduralen Kommunikation steigern.
3. Hochverfügbarkeit: In einem verteilten Messaging-System ist der normale Betrieb garantiert, selbst wenn einige Messaging-Systeme ausgefallen sind, obwohl die Leistung beeinträchtigt sein kann.
4. Wiederholen: Selbst wenn ein worker ausfällt, bleiben Nachrichten in der queue, sodass der worker nach dem vorherigen fehlgeschlagenen Vorgang fortgesetzt werden kann, wenn er wieder hochfährt. Selbst wenn die Echtzeit reduziert wird, wird die Konsistenz der Daten zuverlässig.
5. Lose Kopplung: Durch indirekte Aufrufe über das Messaging-System anstelle von direkten Aufrufen muss die publisher nach der Veröffentlichung der Nachricht nicht die gesamte Geschäftslogik kennen. Es ist die Rolle des publisher nur bis zur Veröffentlichung. Die Nachricht wird dann über das Nachrichtensystem an den Teilnehmer geliefert. Jetzt ist der Abonnent für die Bearbeitung der Nachricht verantwortlich. Die lose Kopplung, die durch indirekte statt direkte publisher Aufrufe erreicht wird, macht unsere Software flexibler und skalierbarer.

Benachrichtigungseinstellungen für Abonnieren und Liken sind sehr hilfreich für Inhaltsersteller.

Danke