Wie ruft das Storm-Framework intern die nextTuple () -Methode fortlaufend auf.

Ich glaube, dass dies eine sehr detaillierte Diskussion über den gesamten Lebenszyklus einer Sturm-Topologie sowie ein klares Konzept verschiedener Entitäten wie Arbeiter, Ausführer, Aufgaben usw. beinhaltet. Die eigentliche Verarbeitung einer Topologie erfolgt durch die StormSubmitter class mit der Methode submitTopology .

Das allererste, was es macht, ist, das Glas mit Nimbus Thrift-Interface hochzuladen und ruft dann die submitTopology auf, die schließlich die Topologie an Nimbus übermittelt.

Der Nimbus startet dann mit der Normalisierung der Topologie ( von doc: Der Hauptzweck der Normalisierung besteht darin, sicherzustellen, dass jede einzelne Task die gleichen Serialisierungsregistrierungen hat, was für das korrekte Funktionieren der Serialisierung entscheidend ist. ) gefolgt von Serialisierung , zookeeper Handschütteln , Supervisor und Worker Prozessstart und so weiter. Es ist zu weit zu diskutieren, aber wenn Sie wirklich mehr graben wollen, können Sie den Lebenszyklus von Storm durchlaufen Topologie , in der die Schritt-für-Schritt-Aktionen während der gesamten Zeit gut erklärt werden.
( schnelle Notiz aus der Dokumentation )

  

Zuerst ein paar wichtige Hinweise zu Topologien:

     

Die tatsächliche Topologie, die ausgeführt wird, unterscheidet sich von der Topologie des Benutzers   spezifiziert. Die tatsächliche Topologie hat implizite Ströme und eine implizite   "acker" bolt hinzugefügt, um das acking-Framework zu verwalten (wird verwendet, um zu garantieren   Datenverarbeitung).

     

Die implizite Topologie wird über die   System-Topologie! Funktion. System-Topologie! wird an zwei Orten verwendet:   
- - wenn Nimbus Aufgaben für den Topologie-Code
- - im Worker erstellt   es weiß, wo es Nachrichten an Code

weiterleiten muss

Nun, hier ist ein paar Anhaltspunkte, die ich teilen könnte ...
Tüllen oder Bolzen sind eigentlich die Komponenten, die die eigentliche Verarbeitung (die Logik) ausführen. In der Sturmterminologie führen sie so viele Aufgaben in der Struktur aus.
Auf der Dokumentseite: Jede Aufgabe entspricht einem Ausführungsthread

Nun, neben vielen anderen, eine typische Verantwortung eines worker process (lesen hier ) im Sturm ist, um zu überwachen, ob eine Topologie aktiv ist oder nicht, und diesen bestimmten Zustand in einer Variablen mit dem Namen storm-active-atom zu speichern. Diese Variable wird von den Tasks verwendet, um zu bestimmen, ob die nextTuple -Methode aufgerufen werden soll oder nicht. Solange Ihre Topologie aktiv ist (Sie haben Ihren Ausgangscode nicht eingegeben, sondern angenommen), bis der Timer aktiv ist (z Sie sagten für eine bestimmte Zeit) es wird weiterhin die nextTuple Methode aufrufen. Sie können noch tiefer graben, um die Acking-Framework-Implementierung des Storms zu verstehen, um zu verstehen, wie sie es einmal versteht und anerkennt Ein Tupel wird erfolgreich verarbeitet und Guarantee-message-processing

  

Ich bin mir sicher, dass meinem Verständnis hier etwas fehlt und ich aufgrund dieser Lücke nicht in der Lage bin, mich mit der internen Logik dieses Rahmens zu verbinden

Nachdem ich das gesagt habe, denke ich, dass es wichtiger ist, ein klares Verständnis dafür zu bekommen, wie man mit Sturm arbeitet, als wie man Sturm in der frühen Phase versteht. Zum Beispiel, anstatt den internen Mechanismus des Sturms zu lernen, ist es wichtig zu erkennen, dass, wenn wir einen Ausfluss einstellen, um eine Datei Zeile für Zeile zu lesen, er weiterhin jede Zeile mit der Methode _collector.emit ausgibt, bis er EOF erreicht. Und die damit verbundene Schraube erhält in ihrer execute(tuple input) -Methode das gleiche.

Hoffen Sie, dass dies Ihnen hilft, in Zukunft mehr mit uns zu teilen

Gewöhnliche Ausläufe

Es gibt eine Schleife im% da_de% -Dämon des Gewitters, der wiederholt executor (sowie nextTuple und ack , falls zutreffend) für die entsprechende fail -Instanz aufruft.

Es gibt kein Warten auf die Verarbeitung von Tupeln. Spout erhält einfach spout für Tupel, die bei einer bestimmten Zeitüberschreitung nicht verarbeitet werden konnten. Dies kann leicht mit einer Topologie eines Schnellauslaufs und eines langsamen Bearbeitungsbolzens simuliert werden: Der Auslauf erhält viele fail -Anrufe.

Siehe auch ISpout javadoc :

  

nextTuple, ack und fail werden alle in einer engen Schleife in einem einzelnen Thread in der Spout-Task aufgerufen. Wenn keine Tupel zu emittieren sind, ist es höflich, nextTuple für eine kurze Zeit (wie eine einzelne Millisekunde) zu schlafen, um nicht zu viel CPU zu verschwenden.

Dreizackausläufe

Für Trident-Spouts ist die Situation völlig anders:

  

Standardmäßig verarbeitet Trident einen einzelnen Stapel gleichzeitig und wartet darauf   Der Stapel muss erfolgreich sein oder fehlschlagen, bevor ein anderer Stapel versucht wird. Du kannst bekommen   deutlich höherer Durchsatz - und geringere Latenz bei der Verarbeitung von   jede Charge - durch Pipelining der Chargen . Sie konfigurieren das Maximum   Menge der Chargen, die gleichzeitig mit der    fail Eigenschaft.

     

Auch wenn mehrere Stapel gleichzeitig verarbeitet werden, ordnet Trident alle Statusaktualisierungen in der Topologie unter den Stapeln an.