Endlich hier...RocketMQ Literacy-Kapitel

Die Kolumne

Java Basic Tutorial stellt heute das Wissen über RocketMQ ausführlich vor.

Es ist schon lange her, seit ich gebloggt habe. Obwohl ich unzählige Gründe finden kann, warum ich nicht blogge, ist es letzten Endes immer noch „faul“. Heute habe ich endlich eine Pille gegen faulen Krebs genommen und beschlossen, einen Blog zu schreiben. Was soll ich vorstellen? Nach langem Überlegen möchte ich RocketMQ vorstellen. Immerhin habe ich mehr als 30 Blogs geschrieben, aber ich habe noch keinen guten Blog über MQ geschrieben. Dieser Blog ist relativ einfach und beinhaltet keine Quellcode-Analyse, sondern nur Lese- und Schreibkenntnisse.

Was nützt MQ?

Entkopplung

Ich denke, aus einer bestimmten Perspektive haben Microservices die starke Entwicklung von MQ vorangetrieben. Ursprünglich hatte ein System N mehrere Module und alle Module waren stark miteinander gekoppelt. Ein Modul ist ein System, und Systeme müssen unbedingt interagieren. Es gibt drei gängige Interaktionsmethoden: eine ist RPC, eine ist HTTP und die andere ist MQ.

Asynchron

Ursprünglich ist ein Geschäft in N Schritte unterteilt, die Schritt für Schritt verarbeitet werden müssen, bevor das Endergebnis an den Benutzer zurückgegeben werden kann. Bei MQ wird nun zuerst der kritischste Teil verarbeitet, und dann wird die Nachricht verarbeitet An MQ gesendet und direkt an OK zurückgegeben, Benutzer. Lassen Sie uns die folgenden Schritte langsam im Hintergrund verarbeiten. Dies ist wirklich ein Artefakt, um die Benutzererfahrung zu verbessern.

Peak Shaving

Ein plötzlicher Anstieg der Anzahl der Anfragen für eine bestimmte Schnittstelle wird zwangsläufig großen Druck auf den Anwendungsserver und den Datenbankserver ausüben. Mit MQ müssen Sie sich jetzt keine Gedanken darüber machen, wie viele Anfragen eingehen. und sie werden langsam im Hintergrund verarbeitet.

Einführung in RocketMQ

RocketMQ ist in Java geschrieben. Es handelt sich um Alibabas Open-Source-Nachrichten-Middleware, die viele der Vorteile von Kafka nutzt. Kafka ist ebenfalls eine beliebte Nachrichten-Middleware, aber Kafka ist in Scala geschrieben, was für Java-Programmierer nicht förderlich ist, den Quellcode zu lesen, und es ist für Java-Programmierer auch nicht förderlich, benutzerdefinierte Entwicklungen durchzuführen. Freunde, die Kafka kennengelernt haben, wissen, dass es nicht einfach ist, Kafka gut zu nutzen. Relativ gesehen ist RocketMQ viel einfacher, und RocketMQ wurde von Alibaba gesegnet und hat den Test von N Double 11 erlebt. Es ist besser für inländische Internetunternehmen geeignet Daher wird es im Inland von vielen RocketMQ-Unternehmen verwendet.

Die vier Hauptkomponenten von RocketMQ

Bilder von gitee.com/mirrors/roc...

Sie können sehen, dass RocketMQ vier Hauptkomponenten hat:

NameServer

• Statusloser Dienst, Registrierungscenter, Clusterbereitstellung, aber NameServer Es gibt keine Dateninteraktion zwischen Knoten.
• Borker meldet regelmäßig Topic-Routing-Informationen an alle NameServer. Produzent und Verbraucher wählen zufällig ein NameServer-Thema aus, um die Routing-Informationen regelmäßig zu aktualisieren.
• Topic-Routing-Informationen übernehmen letztendliche Konsistenz im NameServer-Cluster.
• Garantierter AP.

Borker

• Der Server von RocketMQ wird zum Speichern und Verteilen von Nachrichten verwendet.
• Borker meldet regelmäßig alle Topic-Routing-Informationen, die es besitzt, an NameServer.
• Borker hat zwei Rollen: Master und Follower. Der Master ist für das Lesen (Nachrichten konsumieren) und das Schreiben (Erzeugen von Nachrichten) verantwortlich. Wenn der Master beschäftigt oder nicht verfügbar ist, kann der Follower die Lesevorgänge durchführen. BorkerId=0 bedeutet Matser, BorkerId!=0 bedeutet Follower. Es sind zwei Punkte zu beachten: Erstens können bisher nur Follower mit BorkerId=1 Lesevorgänge durchführen; Zweitens unterstützen nur höhere Versionen von RocketMQ das automatische Upgrade von Follower auf Master, wenn der Master-Knoten auflegt.

Produzent

Der Produzent initiiert in regelmäßigen Abständen eine Abfrage von Topic-Routing-Informationen an NameServer.

Consumer

Consumer initiiert in regelmäßigen Abständen eine Abfrage von Topic-Routing-Informationen an NameServer.

Warum das Registrierungscenter Zookeeper nicht verwendet

Tatsächlich wurde Zookeeper in der unteren Version von RocketMQ tatsächlich als Registrierungscenter verwendet, aber später wurde es auf den aktuellen NameServer geändert. Ich denke, der Hauptgrund ist:

• RocketMQ ist bereits eine Middleware und ich möchte mich nicht mehr auf andere Middleware verlassen.
• Zookeeper ist relativ schwer und verfügt über viele Funktionen, die RocketMQ nicht nutzen kann. Es ist besser, ein leichtes Registrierungscenter zu schreiben.
• Zookeeper ist CP Sobald die Wahl des Anführers ausgelöst wird, ist das Registrierungszentrum von RocketMQ nicht mehr verfügbar, solange es die endgültige Konsistenz gewährleistet.

RocketMQ-Nachrichtendomänenmodell

Nachricht

• Die übertragene Nachricht.
• Die Nachricht muss ein Thema haben.
• Eine Nachricht kann mehrere Tags und mehrere Schlüssel haben, die als zusätzliche Attribute der Nachricht betrachtet werden können.

Thema

• Eine Sammlung von Nachrichten.
• Jede Nachricht muss ein Thema haben.
• Der Nachrichtentyp der ersten Ebene.

Tag

• Zusätzlich zu einem Thema kann eine Nachricht auch Tags haben, die verwendet werden, um verschiedene Arten von Nachrichten unter demselben Thema zu unterteilen.
• Tag ist nicht erforderlich.
• Nachrichtentyp der zweiten Ebene.

Group

ist in ProducerGroup und ConsumerGroup unterteilt. Wir legen mehr Wert darauf, dass ConsumerGroup mehrere Verbraucher enthält.

Im Cluster-Verbrauchsmodus verbrauchen Verbraucher unter einer Verbrauchergruppe gemeinsam ein Thema, und jeder Verbraucher wird N Warteschlangen zugewiesen, aber eine Warteschlange wird nur von einem Verbraucher konsumiert. Verschiedene Verbrauchergruppen können dasselbe Thema konsumieren wird von allen ConsumerGroups verbraucht, die dieses Thema abonniert haben.

Warteschlange

• Ein Thema enthält standardmäßig vier Warteschlangen.
• Im Cluster-Verbrauchsmodus können Verbraucher in derselben Verbrauchergruppe Nachrichten aus mehreren Warteschlangen konsumieren, eine Warteschlange kann jedoch nur von einem Verbraucher konsumiert werden.
• Nachrichten in der Warteschlange werden geordnet.
• Es ist in Lesewarteschlangen und Schreibwarteschlangen unterteilt. Im Allgemeinen sind die Anzahl der Lesewarteschlangen und die Anzahl der Schreibwarteschlangen konsistent, da es sonst leicht zu Problemen kommen kann.

Verbrauchsmodus

Es gibt zwei Verbrauchsmodi: Clustering (Cluster-Verbrauch) und Broadcasting (Broadcast-Verbrauch).

Im Gegensatz zu anderen MQs, die beim Senden von Nachrichten den Cluster-Verbrauch oder den Broadcast-Verbrauch angeben, legt RocketMQ den Cluster-Verbrauch oder den Broadcast-Verbrauch auf der Verbraucherseite fest.

Clustering (Clusterverbrauch)

Der Standardwert ist der Clusterverbrauchsmodus. In diesem Modus konsumieren alle Verbraucher in der ConsumerGroup gemeinsam Nachrichten aus einem Thema. Jeder Verbraucher ist für den Konsum von Nachrichten aus N Warteschlangen verantwortlich (N kann auch 1 sein). (even ist 0, nicht der Warteschlange zugewiesen), aber eine Warteschlange wird nur von einem Verbraucher genutzt. Wenn ein Verbraucher stirbt, übernehmen andere Verbraucher der ConsumerGroup die Leitung und konsumieren weiter.

Im Cluster-Verbrauchsmodus wird der Verbrauchsfortschritt auf der Borker-Seite beibehalten und der Speicherpfad ist ${ROCKET_HOME}/store/config/ consumerOffset.json，如下图所示：使用topicName@consumerGroupName为Key，消费进度为Value，Value的形式是queueId:offset Dies bedeutet, dass bei mehreren Verbrauchergruppen der Verbrauchsfortschritt jeder Verbrauchergruppe unterschiedlich ist und separat gespeichert werden muss.

Broadcasting (Broadcast-Verbrauch)

Broadcast-Verbrauchsnachrichten werden an alle Verbraucher in der ConsumerGroup gesendet.

Im Broadcast-Verbrauchsmodus wird der Verbrauchsfortschritt auf der Verbraucherseite beibehalten.

Algorithmus zum Laden der Verbrauchswarteschlange und Ausgleichsmechanismus

Algorithmus zum Laden der Verbrauchswarteschlange

Wir wissen, dass im Cluster-Verbrauchsmodus alle Verbraucher unter der Verbrauchergruppe gemeinsam Nachrichten aus einem Thema konsumieren und jeder Verbraucher für den Konsum von Nachrichten aus N Warteschlangen verantwortlich ist. Wie erfolgt also die Zuordnung? Dies beinhaltet den Algorithmus zum Laden der Verbrauchswarteschlange.

RocketMQ bietet zahlreiche Algorithmen zum Laden von Verbrauchswarteschlangen, von denen die beiden am häufigsten verwendeten Algorithmen AllocateMessageQueueAveragely und AllocateMessageQueueAveragelyByCircle sind. Werfen wir einen Blick auf die Unterschiede zwischen diesen beiden Algorithmen.

Angenommen, ein Thema hat jetzt 16 Warteschlangen, dargestellt durch q0~q15, und 3 Verbraucher, dargestellt durch c0-c2.

Die Ergebnisse der Verwendung von AllocateMessageQueueAveragely zur Nutzung des Warteschlangenladealgorithmus sind wie folgt:

• c0：q0 q1 q2 q3 q4 q5
• c1：q6 q7 q8 q9 q10
• c2：q11 q12 q13 q14 q15

Verwenden AllocatemessagequeueaveragelyByCircle zum Konsum von Warteschlangenlastalgorithmus Die Ergebnisse sind wie folgt:

• c0: Q0 Q3 Q6 Q9 Q12 Q15
• C1: Q1 Q4 Q7 Q10 Q13
• c2: Q2 Q5 Q14 Q14

Alle Verbraucher unter dem Verbraucherkonsum konsumiert Bei einer Topic-Nachricht ist jeder Verbraucher dafür verantwortlich, Nachrichten aus N Warteschlangen zu konsumieren, aber eine Warteschlange kann nicht gleichzeitig von N Verbrauchern konsumiert werden. Was bedeutet das?

Wenn Sie schlau sind, müssen Sie gedacht haben, dass, wenn ein Thema nur 4 Warteschlangen und 5 Verbraucher hat, kein Verbraucher einer Warteschlange zugewiesen wird. Daher bestimmt in RocketMQ direkt die Anzahl der Warteschlangen unter dem Thema Die maximale Anzahl an Verbrauchern bedeutet, dass Sie die Verbrauchsgeschwindigkeit nicht einfach durch das Hinzufügen weiterer Verbraucher erhöhen können.

Rebalancing

Obwohl empfohlen wird, die Anzahl der Warteschlangen beim Erstellen eines Themas vollständig zu berücksichtigen, ist die tatsächliche Situation oft unbefriedigend. Selbst wenn sich die Anzahl der Warteschlangen nicht ändert, wird sich die Anzahl der Verbraucher definitiv ändern, z Online und offline legt beispielsweise ein Consumer auf oder ein neuer Consumer kommt hinzu. Die Erweiterung und Kontraktion der Warteschlange sowie die Erweiterung und Kontraktion des Verbrauchers führen zu einer Neuausrichtung, dh die Verbrauchswarteschlange wird an den Verbraucher neu verteilt.

In RocketMQ fragt der Verbraucher regelmäßig die Anzahl der Themenwarteschlangen ab. Wenn sich die Anzahl der Verbraucher ändert, wird eine Neuverteilung ausgelöst.

Die Neuausrichtung wird intern von RocketMQ implementiert und Programmierer müssen sich nicht darum kümmern.

Ziehen ODER Drücken?

Im Allgemeinen verfügt MQ über zwei Methoden zum Abrufen von Nachrichten:

• Pull: Der Verbraucher ruft Nachrichten aktiv ab. Der Vorteil besteht darin, dass der Verbraucher die Häufigkeit und Anzahl der abgerufenen Nachrichten steuern kann, also auf der Verbraucherseite Es ist nicht einfach, eine Nachrichtenakkumulation zu verursachen, aber die Echtzeitleistung ist nicht sehr gut und die Effizienz ist relativ gering.
• Push: Der Broker sendet aktiv Nachrichten, was den Vorteil von Echtzeit und hoher Effizienz hat. Wenn jedoch zu viele Nachrichten an den Verbraucher gesendet werden, kommt es zu einer Anhäufung Anzahl der Nachrichten auf der Verbraucherseite; wenn die an den Verbraucher gesendeten Daten zu groß sind, führt dies zu Leerlauf auf der Verbraucherseite.

Ob Pull oder Push, der Verbraucher interagiert immer mit dem Broker. Die Interaktionsmethoden umfassen im Allgemeinen kurze Verbindungen, lange Verbindungen und Abfragen.

Es scheint, dass RocketMQ sowohl Pull als auch Push unterstützt, aber tatsächlich wird Push auch mithilfe von Pull implementiert. Wie interagiert der Verbraucher also mit dem Broker?

Das ist die Genialität des RocketMQ-Designs. Es handelt sich weder um eine kurze Verbindung noch um eine lange Verbindung, noch um eine Abfrage, sondern um eine lange Abfrage.

Lange Abfrage

Der Verbraucher initiiert eine Anforderung zum Abrufen von Nachrichten, die in zwei Situationen unterteilt ist:

• Nachricht: Nachdem der Verbraucher die Nachricht erhalten hat, wird die Verbindung getrennt.
• Keine Nachricht: Borker Halten Sie die Verbindung für einen bestimmten Zeitraum aufrecht. Überprüfen Sie alle 5 Sekunden, ob eine Nachricht vorliegt. Diese wird an den Verbraucher gesendet und die Verbindung wird getrennt.

Transaktionsnachrichten

RocketMQ unterstützt Transaktionsnachrichten. Nachdem der Produzent die Transaktionsnachricht an den Broker gesendet hat, speichert der Broker die Nachricht im Systemthema: RMQ_SYS_TRANS_HALF_TOPIC, sodass der Verbraucher diese nicht konsumieren kann Nachricht. RMQ_SYS_TRANS_HALF_TOPIC，这样Consumer就无法消费到这条消息了。

Broker会有一个定时任务，消费RMQ_SYS_TRANS_HALF_TOPIC的消息，向Producer发起回查，回查的状态有三种：提交、回滚、未知。

• 如果回查的状态是提交，回滚，会触发消息的提交和回滚；
• 如果是未知，会等待下一次回查，RocketMQ可以设置一条消息的回查间隔与回查次数，超过一定的回查次数，消息会自动回滚。

延迟消息

延迟消息是指息发到Broker后，不能立刻被Consumer消费，需要等待一定的时间才可以被消费到，RocketMQ只支持特定的延迟时间：1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h

Broker hat eine geplante Aufgabe, um RMQ_SYS_TRANS_HALF_TOPIC-Nachrichten zu verarbeiten und eine Überprüfung an den Produzenten zu initiieren. Es gibt drei Status der Überprüfung: eingereicht, zurückgesetzt und unbekannt.

Wenn der Status der Überprüfung „Übermittlung“ oder „Rollback“ lautet, wird die Übermittlung und das Rollback der Nachricht ausgelöst.

Wenn der Status unbekannt ist, kann RocketMQ das Überprüfungsintervall und die Anzahl der Überprüfungen festlegen für eine Nachricht Nach Überschreiten einer bestimmten Anzahl von Rückmeldungen wird die Nachricht automatisch zurückgesetzt.

Verzögerte Nachricht

Verzögerte Nachricht bedeutet, dass die Informationen nach dem Senden an den Broker nicht sofort vom Verbraucher verarbeitet werden können. Sie müssen eine bestimmte Zeit warten Bevor es verbraucht werden kann, unterstützt RocketMQ nur bestimmte Verzögerungszeiten: 1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h.
• Konsumformen
• RocketMQ unterstützt zwei Konsumformen: gleichzeitiger Konsum und sequenzieller Konsum. Wenn es nacheinander verbraucht wird, müssen Sie sicherstellen, dass sich die sortierten Nachrichten in derselben Warteschlange befinden. Wie wähle ich eine Warteschlange zum Senden aus? RocketMQ verfügt über mehrere Überladungen zum Senden von Nachrichten, von denen eine die Warteschlangenauswahl unterstützt.

Synchrones Flushing, asynchrones Flushing

Der Produzent sendet Nachrichten an Borker, um die Nachricht beizubehalten. RocketMQ unterstützt zwei Persistenzstrategien:

• Synchrones Flushing: Borker kehrt zurück, nachdem die Nachricht an den Produzenten weitergeleitet wurde Die Nachricht ist sehr zuverlässig, aber die Effizienz ist langsam.
• Asynchrones Flushing: Broker schreibt die Nachricht in PageCache und gibt ACK an den Produzenten zurück. Der Vorteil besteht darin, dass es äußerst effizient ist. Wenn jedoch der Server auflegt, gehen möglicherweise Nachrichten verloren. Wenn nur der RocketMQ-Dienst auflegt, gehen keine Nachrichten verloren.

Synchronische Replikation, asynchrone Replikation

Um die Zuverlässigkeit und Verfügbarkeit von MQ sicherzustellen, werden in der Produktionsumgebung im Allgemeinen Follower-Knoten bereitgestellt, und die Follower-Knoten kopieren die Daten des Masters. RocketMQ unterstützt zwei Replikationsstrategien:

Synchronisierte Replikation: Sowohl Master als auch Follower schreiben die Nachricht erfolgreich, bevor sie ACK an den Produzenten zurücksenden. Die Zuverlässigkeit ist hoch, aber die Effizienz ist langsam. 🎜🎜Asynchrone Replikation: Solange der Master erfolgreich schreibt, wird ACK an den Produzenten zurückgegeben, was effizienter ist, aber Nachrichten können verloren gehen. 🎜🎜🎜Ob „schreibend“ in den PageCache oder auf die Festplatte geschrieben wird, hängt von der Konfiguration des Follower Brokers ab. 🎜🎜Sprechen wir über Producer🎜🎜RocketMQ bietet drei Methoden zum Senden von Nachrichten:🎜

• oneway: Fire and Forget, unidirektionale Nachricht, was bedeutet, dass die Nachricht nach dem Senden ignoriert wird. Diese Methode hat keinen Rückgabewert.
• Synchronisation: Nachdem die Nachricht gesendet wurde, wartet sie synchron auf die Antwort des Borkers.
• Asynchron: Nachdem die Nachricht gesendet wurde, kehrt sie sofort zurück. Nach Erhalt der Antwort von Boker wird die Funktionsaufrufmethode ausgeführt.

In der tatsächlichen Entwicklung wird im Allgemeinen die Synchronisierungsmethode verwendet. Wenn Sie die Leistung von RocketMQ verbessern möchten, ändern Sie normalerweise die Parameter auf der Borker-Seite, insbesondere die Disk-Brushing-Strategie und die Replikationsstrategie.

Versenden von Nachrichten erneut versuchen

Wenn beim Senden einer Nachricht MessageQueueSelector verwendet wird, ist der Wiederholungsmechanismus des Nachrichtenversands ungültig.

Die Antwort auf das Senden einer Nachricht kann die folgenden vier sein:

public enum SendStatus {
    SEND_OK,
    FLUSH_DISK_TIMEOUT,
    FLUSH_SLAVE_TIMEOUT,
    SLAVE_NOT_AVAILABLE,
}复制代码

Außer der ersten sind die anderen Situationen problematisch. Um sicherzustellen, dass die Nachricht nicht verloren geht, müssen Sie den Producer-Parameter festlegen: RetryAnotherBrokerWhenNotStoreOK auf true. RetryAnotherBrokerWhenNotStoreOK为true。

故障规避机制

如果消息发送失败了，重试的时候，还是发送给这个Borker，那么大概率发送还是失败的，RockteMQ设计精巧之处在于，重试的时候，会自动避开这个Borker，而选择其他Borker，但是目前为止，异步发送没有那么智能，只会在一个Borker上重试，所以强烈建议选择同步发送方式。

RocketMQ提供了两种故障规避机制。用参数SendLatencyFaultEnable来控制。

• false：默认值，只有在重试的时候，才会启用故障规避机制，比如发送消息给BorkerA失败了，重试的时候，会选择BorkerB，但是下次发送消息，还是会选择发送给BorkerA。
• true：开启延迟退避机制，一旦消息发送给BorkerA失败，就会悲观的认为在一段时间内，BorkerA不可用，在将来的一段时间内，不会再向BorkerA发送消息。

延迟退避机制看起来很好用，但是一般来说Borker端繁忙，导致Borker不可用或者网络不可用只是一瞬间的事情，马上就可以恢复，如果开启了延迟退避机制，本来可用的Borker在一段时间内却被规避了，其他Borker更加繁忙，那可能情况更糟糕。

再谈谈Consumer

Consumer线程注意事项

Consumer有两个参数，可以消费的并行度，即ConsumeThreadMin、ConsumeThreadMax，看起来给人的感觉是，如果Consumer端堆积消息比较少，消费线程数为ConsumeThreadMin；如果Consumer端堆积消息比较多，就自动开启新的线程来消费，直到消费线程数为ConsumeThreadMax。但是并不是这样，Consumer内部持有一个线程池，选用的是无界队列，也就是ConsumeThreadMax参数是无效的，所以在实际开发中，ConsumeThreadMin、ConsumeThreadMax往往设置成一样。

ConsumeFromWhere

如果查询不到消费进度的时候，Consumer从哪里开始消费，RocketMQ支持从最新消息、最早消息、指定时间戳这三种方式进行消费。

消费消息重试

RocketMQ会为每个ConsumerGroup都设置一个Topic名称为%RETRY%+consumerGroup的重试队列，用来保存需要给ConsumerGroup重试的消息，但是重试需要一定的延时时间，RocketMQ对于重试消息的处理是先保存至Topic名称为SCHEDULE_TOPIC_XXXX的延迟队列中，后台定时任务按照对应的时间进行Delay后重新保存至%RETRY%+consumerGroup

Fehlervermeidungsmechanismus

Wenn das Senden der Nachricht fehlschlägt und beim erneuten Versuch immer noch an den Borker gesendet wird, schlägt das Senden mit hoher Wahrscheinlichkeit immer noch fehl Der Punkt ist, dass beim erneuten Versuch dieser Borker automatisch vermieden und ein anderer Borker ausgewählt wird. Bisher ist das asynchrone Senden jedoch nicht so intelligent und wird nur bei einem Borker wiederholt. Daher wird dringend empfohlen, den synchronen zu wählen Sendemethode.

RocketMQ bietet zwei Fehlervermeidungsmechanismen. Verwenden Sie zur Steuerung den Parameter SendLatencyFaultEnable.

• false: Standardwert, der Fehlervermeidungsmechanismus wird nur bei einem erneuten Versuch aktiviert. Wenn beispielsweise das Senden einer Nachricht an BorkerA fehlschlägt, wird BorkerB beim erneuten Versuch ausgewählt, aber beim nächsten Senden einer Nachricht wird dies weiterhin der Fall sein an BorkerA gesendet.
• true: Aktivieren Sie den verzögerten Backoff-Mechanismus. Sobald die Nachricht nicht an BorkerA gesendet werden kann, wird pessimistisch davon ausgegangen, dass BorkerA für einen bestimmten Zeitraum nicht verfügbar sein wird und für einen bestimmten Zeitraum keine weiteren Nachrichten an BorkerA gesendet werden in der Zukunft.
• Der verzögerte Backoff-Mechanismus scheint sehr nützlich zu sein, aber im Allgemeinen ist die Borker-Seite ausgelastet, was dazu führt, dass der Borker nicht verfügbar ist oder das Netzwerk nicht verfügbar ist, wenn die Verzögerung auftritt Wenn der Backoff-Mechanismus aktiviert ist, wird der ursprünglich verfügbare Borker eine Zeit lang umgangen, und andere Borker waren beschäftigter, sodass die Situation möglicherweise noch schlimmer ist.

Sprechen wir über Consumer

Überlegungen zum Consumer-Thread

Consumer hat zwei Parameter: den Grad der Parallelität, der verbraucht werden kann istConsumeThreadMin, ConsumeThreadMax, es scheint, dass, wenn auf der Verbraucherseite relativ wenige Nachrichten angesammelt werden, die Anzahl der Verbraucherthreads ConsumeThreadMin ist; Auf der Verbraucherseite werden weniger Nachrichten gesammelt. Wenn viele Nachrichten vorhanden sind, wird automatisch ein neuer Thread für den Konsum geöffnet, bis die Anzahl der konsumierenden Threads ConsumeThreadMax erreicht. Dies ist jedoch nicht der Fall. Der Verbraucher verfügt intern über einen Thread-Pool und verwendet eine unbegrenzte Warteschlange. Das heißt, der Parameter ConsumeThreadMax ist ungültig, sodass in der tatsächlichen Entwicklung ConsumeThreadMin gilt. ConsumeThreadMax wird oft auf den gleichen Wert gesetzt.

ConsumeFromWhere

Wenn der Verbrauchsfortschritt nicht abgefragt werden kann, wo beginnt der Verbraucher mit dem Konsum? RocketMQ unterstützt den Verbrauch ab der neuesten Nachricht, der frühesten Nachricht und dem angegebenen Zeitstempel.

VerbrauchernachrichtenwiederholungRocketMQ richtet für jede Verbrauchergruppe, die Nachrichten speichert, eine Wiederholungswarteschlange mit dem Themennamen %RETRY%+consumerGroup ein von ConsumerGroup erneut versucht werden, aber für die Wiederholung ist eine bestimmte Verzögerungszeit erforderlich. RocketMQ verarbeitet Wiederholungsnachrichten zunächst in der Verzögerungswarteschlange mit dem Themennamen SCHEDULE_TOPIC_XXXX. Die im Hintergrund geplanten Aufgaben folgen der entsprechenden Zeitverzögerung Speichern Sie es dann erneut in der Wiederholungswarteschlange von %RETRY%+consumerGroup. Was soll ich tun, wenn sich Nachrichten ansammeln und die Verbrauchskapazität nicht ausreicht? Die Verbesserung des Verbrauchsfortschritts ist der beste Weg. 🎜🎜Warteschlange hinzufügen und Verbraucher hinzufügen. 🎜🎜Der ursprüngliche Verbraucher fungiert als Brick-Mover und „verschiebt“ Nachrichten gemäß bestimmten Regeln in mehrere neue Themen und öffnet dann mehrere Verbrauchergruppen, um verschiedene Themen zu konsumieren. 🎜🎜Eröffnen Sie eine neue ConsumerGroup für den Konsum, das heißt, zwei ConsumerGroups konsumieren gleichzeitig ein Thema, aber Sie müssen auf die Beurteilung des Offsets achten. Beispielsweise konsumiert eine ConsumerGroup Nachrichten mit einer ungeraden Zahl und eine ConsumerGroup konsumiert Nachrichten mit einer geraden Nummer. 🎜🎜🎜Ich dachte ursprünglich, dass ich reibungslos schreiben könnte, wenn ich Alphabetisierungstext schreibe, aber ich habe es trotzdem überlegt. Da es sich um Alphabetisierungstext handelt, richtet er sich an Freunde, die nicht viel Kontakt mit RocketMQ hatten, RocketMQ aber schon Einfach, dass es unmöglich ist, es mit nur einer Person zu verwenden? Dieser Blog ermöglicht Freunden, die noch nicht viel Kontakt mit RocketMQ hatten, einen reibungslosen Einstieg. Als ich den Blog schrieb, habe ich darüber nachgedacht, ob das wichtig ist und ob das so sein muss sorgfältig beschrieben werden? Diese Sache kann ignoriert werden, kann sie nicht eingeführt werden usw. Es ist ersichtlich, dass in diesem Artikel grundsätzlich verschiedene Konzepte vorgestellt werden und die API-Ebene fast nicht berücksichtigt wird, da sie geschätzt wird, sobald die API beteiligt ist dass es nicht in zwei Wochen fertig sein wird. 🎜🎜Ende🎜🎜🎜🎜Verwandte kostenlose Lernempfehlungen: 🎜🎜🎜Java-Grundlagen-Tutorial🎜🎜🎜

Das obige ist der detaillierte Inhalt vonEndlich hier...RocketMQ Literacy-Kapitel. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!