1. Einführung

Unsere Freunde sollten genug über Message Middleware MQ geh?rt haben, wie zum Beispiel: RabbitMQ, RocketMQ, Kafka usw. Die Vorteile der Einführung von Middleware k?nnen dazu beitragen, hoher Parallelit?t, Peaking und Gesch?ftsentkopplung entgegenzuwirken.

Wie oben gezeigt:

(1) Der Bestelldienst übermittelt Nachrichten an die MQ-Middleware. (2) Der Logistikdienst überwacht die MQ-Middleware-Nachrichten auf Verbrauch.

Lassen Sie uns in diesem Artikel besprechen, wie der Bestelldienst sichergestellt werden kann Am Beispiel von RabbitMQ wird die Nachricht erfolgreich an die MQ-Middleware übermittelt.

2. Analyse des Problems

Meine Freunde haben m?glicherweise einige Fragen dazu. Wenn der Bestelldienst den Nachrichtendienst initiiert, bedeutet das nicht Erfolg, wenn die Rücksendung erfolgreich ist? Zum Beispiel der folgende Pseudocode:

Im obigen Code werden Nachrichten im Allgemeinen so gesendet. Glauben Sie, dass es ein Problem gibt?

Lassen Sie uns unten über ein Szenario sprechen. Was passiert, wenn der MQ-Server pl?tzlich ausf?llt? Sind alle Nachrichten unseres Bestellservices verschwunden? Ja, im Allgemeinen speichert die MQ-Middleware Nachrichten im Speicher, um den Durchsatz des Systems zu verbessern. Wenn keine andere Verarbeitung erfolgt, gehen alle Nachrichten verloren, sobald der MQ-Server ausf?llt. Dies wird vom Unternehmen nicht zugelassen und wird gro?e Auswirkungen haben.

3. Persistenz

Ich wei?, dass es beim Senden einer Nachricht einen dauerhaften Parameter gibt, der auf ?true“ gesetzt werden kann , es wird Persistenz.

In diesem Fall werden die Nachrichten auch bei einem Ausfall des MQ-Servers nach dem Neustart in der Festplattendatei gespeichert, sodass sie nicht verloren gehen. Ja, dadurch wird sichergestellt, dass die Nachricht mit einer gewissen Wahrscheinlichkeit nicht verloren geht.

Aber es wird ein Szenario geben, in dem die Nachricht gerade im MQ-Speicher gespeichert wurde, aber bevor sie in der Festplattendatei aktualisiert werden kann, stürzt sie pl?tzlich ab. (Verdammt, das wird in so kurzer Zeit passieren. Die Wahrscheinlichkeit ist zu gering.) Dieses Szenario wird im Prozess der kontinuierlichen Nachrichtenzustellung in gro?em Ma?stab sehr h?ufig auftreten.

Was tun? Wie k?nnen wir sicherstellen, dass es auf der Festplatte gespeichert bleibt?

4. Mechanismus best?tigen

Das obige Problem entsteht, weil uns niemand sagt, ob Persistenz erfolgreich ist. Glücklicherweise verfügen viele MQs über Rückrufbenachrichtigungsfunktionen und RabbitMQ verfügt über einen Best?tigungsmechanismus, der uns benachrichtigt, ob die Persistenz erfolgreich ist.

Prinzip des Best?tigungsmechanismus:

(1) Der Nachrichtenproduzent sendet die Nachricht an MQ. Wenn der Empfang erfolgreich ist, sendet MQ eine Best?tigungsnachricht an den Produzenten zurück ist nicht erfolgreich, MQ Eine Nack-Nachricht wird an den Produzenten zurückgegeben

Ist dadurch sichergestellt, dass nicht 100 % der Nachrichten verloren gehen?

Werfen wir einen Blick auf den Best?tigungsmechanismus? Stellen Sie sich vor, jedes Mal, wenn unser Produzent eine Nachricht sendet, muss MQ auf der Festplatte gespeichert werden und dann einen Best?tigungs- oder Nack-Rückruf initiieren. In diesem Fall ist der Durchsatz unseres MQ sehr gering, da die Nachricht jedes Mal auf der Festplatte gespeichert werden muss. Das Schreiben auf die Festplatte ist sehr langsam. Dies ist in Szenarien mit hoher Parallelit?t nicht akzeptabel und der Durchsatz ist zu gering.

Die eigentliche Implementierung der persistenten MQ-Festplatte erfolgt über einen bestimmten Mechanismus. Wenn beispielsweise Tausende von Nachrichten vorhanden sind, werden diese auf einmal geleert. Anstatt die Festplatte jedes Mal zu leeren, wenn eine Nachricht eingeht.

Der Best?tigungsmechanismus ist also tats?chlich ein asynchroner Abh?rmechanismus, der den hohen Durchsatz des Systems sicherstellen soll. Dies bedeutet, dass die Nachricht nicht zu 100 % verloren geht, denn selbst wenn der Best?tigungsmechanismus hinzugefügt wird , die Nachricht befindet sich immer noch im MQ-Speicher. Der Computer ist ohne Flashen auf die Festplatte abgestürzt und kann immer noch nicht bearbeitet werden.

Nachdem ich so viel gesagt habe, kann ich es immer noch nicht garantieren. Was soll ich also tun? ? ?

5. Nachrichtenpersistenz im Voraus + geplante Aufgaben

Tats?chlich ist der wesentliche Grund, dass es unm?glich ist, festzustellen, ob sie persistiert? K?nnen wir die Botschaft also selbst dauerhaft machen? Die Antwort lautet: Ja, unser Plan wird sich weiterentwickeln.

Der Prozess im obigen Bild:

(1) Vor der übermittlung der Nachricht übertr?gt der Bestelldienstersteller die Nachricht zun?chst an Redis oder Redis, um eine hohe Leistung zu erzielen. Der Status der Nachricht ist Wird gesendet.

(2) Wurde die überwachungsnachricht des Best?tigungsmechanismus erfolgreich gesendet? Wenn die Best?tigung erfolgreich ist, l?schen Sie diese Nachricht in Redis.

(3) Wenn Nack fehlschl?gt, k?nnen Sie w?hlen, ob Sie die Nachricht je nach Ihrem eigenen Unternehmen erneut senden m?chten. Abh?ngig von Ihrer gesch?ftlichen Entscheidung k?nnen Sie diese Nachricht auch l?schen.

(4) Hier wird eine geplante Aufgabe hinzugefügt, um die Nachricht nach einer bestimmten Zeitspanne abzurufen. Der Nachrichtenstatus wird immer noch gesendet. Dieser Status zeigt an, dass der Bestelldienst die Best?tigungs-Erfolgsnachricht nicht erhalten hat.

(5) Geplante Aufgaben liefern kompensatorische Nachrichten. Wenn zu diesem Zeitpunkt die MQ-Rückrufbest?tigung erfolgreich empfangen wird, wird die Nachricht in Redis gel?scht.

Dieser Mechanismus ist eigentlich ein Kompensationsmechanismus. Es ist mir egal, ob MQ ihn tats?chlich empf?ngt. Solange der Nachrichtenstatus in meinem Redis [Sendet] lautet, bedeutet dies, dass die Nachricht nicht erfolgreich korrekt zugestellt wurde. Starten Sie dann die geplante Aufgabe zur überwachung und Einleitung der Entsch?digungslieferung.

Natürlich k?nnen wir auch eine Kompensationsnummer für die geplante Aufgabe hinzufügen und immer noch keine Best?tigungsnachricht erhalten, dann setzen Sie den Status der Nachricht direkt auf [Fehlgeschlagen] und lassen Sie die Leute manuell überprüfen, warum ?

In diesem Fall ist die L?sung perfekter und stellt sicher, dass 100 % der Nachrichten nicht verloren gehen (dabei ist der Festplattenausfall natürlich nicht berücksichtigt, sodass eine Master-Slave-L?sung verwendet werden kann).

Mit dieser L?sung ist es jedoch m?glich, dieselbe Nachricht mehrmals zu senden. Es ist sehr wahrscheinlich, dass MQ die Nachricht bereits empfangen hat, beim Rückruf der Best?tigungsnachricht jedoch ein Netzwerkfehler aufgetreten ist, der Produzent jedoch nicht Erhalte es.

Dann müssen wir von Verbrauchern verlangen, beim Konsum auf Idempotenz zu achten!

Sechs, die Bedeutung von Idempotenz

Lassen Sie uns zun?chst verstehen, was Idempotenz ist. In verteilten Anwendungen ist Idempotenz sehr wichtig. Das hei?t, wenn ein Unternehmen unter denselben Bedingungen betrieben wird, ist das Ergebnis dasselbe, unabh?ngig davon, wie oft es ausgeführt wird.

6.1. Warum gibt es ein solches Szenario wie idempotent?

Warum gibt es ein Szenario wie idempotent? Denn in gro?en Systemen werden sie alle verteilt eingesetzt. Beispielsweise k?nnen Auftragsgesch?ft und Lagergesch?ft unabh?ngig voneinander eingesetzt werden und sind separate Dienste. Wenn ein Benutzer eine Bestellung aufgibt, werden der Bestellservice und der Lagerservice aufgerufen.

Aufgrund der verteilten Bereitstellung ist es sehr wahrscheinlich, dass der Aufruf des Bestellservices aus Netzwerk- und anderen Gründen fehlschl?gt. Tats?chlich wurde der Inventarservice jedoch verarbeitet, bei der Verarbeitung ist jedoch eine Ausnahme aufgetreten Das Ergebnis wurde an den Bestellservice zurückgegeben. Zu diesem Zeitpunkt erstellt das System im Allgemeinen einen Vergütungsplan, d. h. der Bestelldienst ruft dann den Lagerdienst an und der Lagerbestand wird um 1 reduziert.

Es liegt tats?chlich ein Problem vor, der letzte Anruf wurde um 1 reduziert, aber der Bestellservice hat das Bearbeitungsergebnis nicht erhalten. Jetzt wird es erneut aufgerufen und muss um 1 reduziert werden. Dies entspricht nicht dem Gesch?ft und ist ein zus?tzlicher Abzug.

Das Konzept der Idempotenz besteht darin, dass das Verarbeitungsergebnis dasselbe ist, egal wie oft der Inventardienst unter denselben Bedingungen aufgerufen wird. Nur so kann die Durchführbarkeit des Vergütungsplans sichergestellt werden. 6.2. Optimistisches Sperrschema Führen Sie die Bestandsaufnahme durch und bringen Sie dann diese Versionsnummer mit. Lassen Sie uns das kl?ren. Als wir die Inventur zum ersten Mal durchführten, bekamen wir Version 1, und als wir den Inventurservice anriefen, gab es ein Problem, als wir zum Bestellservice zurückkehrten Wenn der Bestelldienst als Version übergeben wird und die obige SQL-Anweisung erneut ausgeführt wird, wird sie nicht ausgeführt, da die Version auf 2 ge?ndert wurde. Dies stellt sicher, dass es, egal wie oft es aufgerufen wird, nur einmal tats?chlich verarbeitet wird.

6.3. Eindeutige ID + Fingerabdruckcode

Das Prinzip besteht darin, den Datenbank-Prim?rschlüssel zu verwenden, um Duplikate zu entfernen. Geben Sie nach Abschluss des Gesch?fts die Prim?rschlüssel-ID ein ist der einzige Prim?rschlüssel der Gesch?ftstabelle, z. B. die Produkt-ID