Was ist das Konzept des Reaktornetzwerkmodells in Java IO?

1. Was ist das Reaktormodell:

Der Reaktor Das Entwurfsmuster ist ein Ereignisbehandlungsmuster zur Verarbeitung von Dienstanforderungen, die gleichzeitig an einen Dienst-Handler durch eine oder mehrere Eingaben übermittelt werden. Der Dienst-Handler demultiplext dann die eingehenden Anforderungen und sendet sie synchron an die zugehörigen Anforderungs-Handler.

# 🎜 🎜#Reaktormuster, auch Reaktorentwurfsmuster genannt, ist ein Ereignisentwurfsmuster zur Verarbeitung von Serviceanfragen, die gleichzeitig an einen oder mehrere Serviceprozessoren gesendet werden. Wenn Anfragen eintreffen, werden diese demultiplext und über den Serviceprozessor an die entsprechenden Anfrageprozessoren verteilt. Das Reaktormuster besteht hauptsächlich aus zwei Kernteilen: Reaktor und Prozessor-Handler, wie in der folgenden Abbildung dargestellt. Sie sind für die folgenden Dinge verantwortlich:

• Reaktor: Verantwortlich für Überwachungs- und Verteilungsereignisse, Ereignistypen umfassen Verbindungsereignisse, Lese- und Schreibereignisse;

• Handler: Verantwortlich für die Verarbeitung von Ereignissen, wie z berechnen + kodieren) -> ; senden; Vom Socket Daten abrufen.

  ② dekodieren: Beim Dekodieren werden Daten im Netzwerk in Form von Bytes übertragen. Um die eigentliche Anforderung zu erhalten, müssen Sie dekodieren.

  ③ berechnen: Berechnung, also Geschäftsverarbeitung.
④ kodieren: Kodieren, Daten im Netzwerk werden in Form von Bytes übertragen, dh der Socket empfängt nur Bytes, daher ist eine Kodierung erforderlich.

⑤ send: Antwortdaten senden

Im Reaktormodus leitet der Service-Handler jedes Mal weiter, wenn ein Ereignis in den Server eingegeben wird (Versand). ) zur Verarbeitung an den entsprechenden Handler übergeben. Drei im Reactor-Modell definierte Rollen:

Der Reactor ist für die Überwachung und Verteilung von Ereignissen und deren Weiterleitung an die entsprechenden Handler verantwortlich. Zu den neuen Ereignissen gehören Verbindungsaufbau bereit, Lesebereit, Schreibbereit usw.

Akzeptor: Fordern Sie den Connector auf, neue Verbindungen vom Client zu verarbeiten. Nachdem Reactor das Verbindungsereignis vom Client empfangen hat, leitet er es an Acceptor weiter, der die Verbindung des Clients empfängt, den entsprechenden Handler erstellt und diesen Handler bei Reactor registriert.

Handler: Anforderungsprozessor, verantwortlich für die Ereignisverarbeitung, die Bindung an Ereignisse, die Ausführung nicht blockierender Lese-/Schreibaufgaben, das Abschließen des Kanallesens und das Schreiben der Ergebnisse nach Abschluss der Verarbeitung der Geschäftslogik Kanal. Verfügbare Ressourcenpools können verwaltet werden.

Das Modell sieht ungefähr wie unten dargestellt aus:

Für Lese-/Schreibanforderungen gilt das Reactor-Modell wie folgt Prozessverarbeitung:

(1) Die Anwendung registriert Lese-/Schreibbereitschaftsereignisse und zugehörige Ereignishandler

#🎜 🎜#(2) Der Ereignisseparator wartet auf das Eintreten des Ereignisses.

• (3) Wenn ein Lese-/Schreibbereit-Ereignis auftritt, ruft der Ereignisseparator den ersten Schritt „Registriert“ auf Event-Handler

• 2. Klassifizierung von Reaktormodellen:

Reaktor Der Reaktor im Modell kann einzeln oder mehrfach sein, der Handler kann auch einzeln sein -threaded oder multithreaded, daher gibt es ungefähr drei Kombinationsmodi: ?? -Slave-Reaktor-Multithread-Modell
Das dritte Master-Slave-Reaktor-Single-Thread-Modell hat keine praktische Bedeutung, daher wird im Folgenden auf die anderen drei Modelle eingegangen#🎜 🎜#

1. Single-Reactor-Single-Thread-Modell:

1.1. Verarbeitungsprozess:

• (1 ) Der Reactor-Thread hört das Ereignis über select ab und verteilt es über Dispatch, nachdem er das Ereignis empfangen hat
  (2) Wenn es sich um ein Verbindungsaufbauereignis handelt, wird das Ereignis an den Acceptor verteilt Der Akzeptor erhält die Verbindung über die Methode „accept()“ und erstellt ein Handler-Objekt, um nachfolgende Antwortereignisse zu verarbeiten
• (3) Wenn es sich um ein E/A-Lese- und Schreibereignis handelt, übergibt Reactor das Ereignis an Der aktuell verbundene Handler für die Verarbeitung
  (4) Der Handler schließt den gesamten Geschäftsprozess des Lesens ab –> Senden von
• 1.2. 🎜🎜#

  Der Vorteil des Single-Reactor-Single-Thread-Modells besteht darin, dass die gesamte Verarbeitungslogik in einem Thread implementiert ist und es keine Probleme mit Multithreading, Prozesskommunikation oder Konkurrenz gibt. Allerdings weist dieses Modell erhebliche Leistungs- und Zuverlässigkeitsprobleme auf:

  • ① Leistung: Im Code werden nur die Komponenten unterschieden, der Gesamtvorgang ist immer noch Single-Threaded, die CPU-Ressourcen können nicht vollständig genutzt werden und der Handler-Geschäftsverarbeitungsteil ist nicht asynchron , und ein Reaktor muss sowohl für die Verarbeitung von Verbindungsanforderungen als auch für die Verarbeitung von Lese- und Schreibanforderungen verantwortlich sein. Im Allgemeinen ist die Verarbeitung von Verbindungsanforderungen sehr schnell, aber die Verarbeitung von Lese- und Schreibanforderungen erfordert eine Geschäftslogikverarbeitung, die relativ langsam ist. Da Reactor Lese- und Schreibanfragen verarbeitet, werden andere Anfragen blockiert, was leicht zu Engpässen bei der Systemleistung führen kann Eine Endlosschleife führt dazu, dass das gesamte Systemkommunikationsmodul nicht verfügbar ist und externe Nachrichten nicht empfangen und verarbeiten kann, was zu einem Knotenausfall führt

  • Daher ist der Einzelreaktor-Einzelprozess Modell ist nicht für intensive Berechnungen geeignet. Diese Art von Szenario eignet sich nur für Szenarien, in denen die Geschäftsabwicklung sehr schnell ist. Das Threading-Modell von Redis basiert auf dem Single-Thread-Modell von Reactor. Da die Geschäftsverarbeitung von Redis hauptsächlich im Speicher erfolgt, ist die Betriebsgeschwindigkeit sehr hoch und der Leistungsengpass liegt nicht auf der CPU, sodass Redis Befehle in a verarbeitet Einzelprozess.

  2. Single-Reactor-Multithread-Modell:

  Um die Leistungsprobleme des Single-Reactor-Single-Thread-Modells zu lösen, wird das Single-Reactor-Multi-Thread-Modell verwendet Dieses Modell wird in Ereignissen verwendet.

  2.1 Verarbeitungsprozess:

  (1) Der Reaktor-Thread übergibt ausgewählte Listen für Ereignisse und verteilt sie nach Empfang des Ereignisses über Dispatch.

  (2) Wenn es sich um ein Verbindungsaufbauereignis handelt, wird das Ereignis an den Akzeptor verteilt . Der Acceptor erhält die Verbindung über die Methode „accept()“ und erstellt ein Handler-Objekt zur Verarbeitung nachfolgender Antwortereignisse

  (3) Wenn es sich um ein IO-Lese- und Schreibereignis handelt, übergibt Reactor das Ereignis an den Handler, der der aktuellen Verbindung zur Verarbeitung entspricht Durch Lesen der Daten werden die Daten zur Geschäftsverarbeitung an den nachfolgenden Worker-Thread-Pool gesendet.

  (5) Der Worker-Thread-Pool weist Threads für die Geschäftsverarbeitung zu. Nach Abschluss werden die Antwortergebnisse zur Verarbeitung an den Handler gesendet.

  (6) Nach Erhalt des Antwortergebnisses sendet der Handler das Antwortergebnis per Senden an den Client zurück.

  2.2. Vor- und Nachteile:

  Nach der Verarbeitung der Geschäftslogik, also nach Erhalt der IO-Lese- und Schreibereignisse, wird diese übergeben Nach der Verarbeitung gibt der Handler das Antwortergebnis per Senden an den Client zurück, nachdem er die Antwort empfangen hat. Dadurch kann der Leistungsaufwand von Reactor reduziert werden, sodass er sich stärker auf die Ereignisverteilung konzentrieren und den Durchsatz der gesamten Anwendung verbessern kann. Darüber hinaus nutzt der Handler den Multithreading-Modus, um die CPU-Leistung voll auszunutzen. Bei diesem Modell gibt es jedoch Probleme:

  (1) Der Handler verwendet den Multithreading-Modus, was natürlich den Overhead des Multithread-Wettbewerbs um Ressourcen mit sich bringt und auch den gegenseitigen Ausschluss- und Schutzmechanismus von mit sich bringt gemeinsame Daten, was die Implementierung komplizierter macht# 🎜🎜#

  (2) Ein einzelner Reaktor ist für die Überwachung, Verteilung und Reaktion auf alle Ereignisse verantwortlich, was in Szenarien mit hoher Parallelität leicht zu Leistungsengpässen führen kann.
  3. Master-Slave-Reactor-Multithread-Modell:
  Das Single-Reactor-Multithread-Modell löst das Leistungsproblem des Handler-Single-Threads, aber Reactor ist immer noch Single-Threaded Für Szenarien mit hoher Parallelität wird es immer noch einen Leistungsengpass geben, daher muss Reactor auf den Multithread-Modus umgestellt werden, bei dem es sich um das Master-Slave-Reactor-Multithread-Modell handelt, das als nächstes eingeführt wird. Im Master-Slave-Reactor-Multithreading-Modell ist der Reactor in zwei Teile unterteilt
  (1) MainReactor: Nur verantwortlich für die Verarbeitung von Verbindungsaufbauereignissen, das Abhören des Server-Sockets über Select und die Registrierung SocketChannel zum SubReactor eingerichtet, normalerweise reicht ein Thread aus
  (2) SubReactor: Verantwortlich für das Lesen und Schreiben von Ereignissen, die Pflege eines eigenen Selektors und das Durchführen von mehrkanaligen, getrennten E/A-Lese- und Schreibereignissen basierend auf dem SocketChannel Wird von MainReactor registriert, liest und schreibt Netzwerkdaten und die Geschäftsverarbeitung wird vom Worker-Thread-Pool abgeschlossen. Die Anzahl der Subreaktoren entspricht im Allgemeinen der Anzahl der CPUs Der Hauptthread Das MainReactor-Objekt hört Ereignisse über Select ab und verteilt sie nach dem Empfang des Ereignisses über Dispatch. Wenn es sich bei dem Ereignistyp um ein Verbindungsaufbauereignis handelt, wird es zum Verbindungsaufbau an den Akzeptor verteilt
  # 🎜🎜#Verbindungsaufbau:

  ① Wählen Sie zufällig einen Reactor-Thread aus dem Haupt-Thread-Pool als Akzeptor-Thread aus, um den Überwachungsport zu binden und Client-Verbindungen zu empfangen.
  ② Nachdem der Akzeptor-Thread die Client-Verbindungsanforderung empfangen hat, erstellt er einen neuen SocketChannel und registriert ihn bei anderen Threads im Haupt-Thread Im Thread-Pool ist er für die Zugriffsauthentifizierung, die IP-Black- und Whitelist-Filterung, den Handshake und andere Vorgänge verantwortlich.
  ③ Nachdem Schritt ② abgeschlossen ist, wird die Verbindung der Geschäftsschicht offiziell hergestellt. Entfernen Sie den SocketChannel aus dem Multiplexer des Reactor-Threads des Haupt-Thread-Pools, registrieren Sie ihn erneut im Thread des SubReactor-Thread-Pools und erstellen Sie einen Handler zur Verarbeitung verschiedener Verbindungsereignisse

  (2) Wenn das empfangene Ereignis kein Verbindungsaufbauereignis ist, wird es an SubReactor verteilt, und SubReactor ruft den Handler auf, der der aktuellen Verbindung zur Verarbeitung entspricht

  (3) Nachdem der Handler das gelesen hat Durch Lesen der Daten werden die Daten an den Worker verteilt. Der Thread-Pool führt die Geschäftsverarbeitung durch, und der Worker-Thread-Pool weist Threads für die Geschäftsverarbeitung zu. Nach Abschluss wird das Antwortergebnis an den Handler gesendet

  (4) Nachdem der Handler die empfangen hat Antwortergebnis: Es gibt das Antwortergebnis über Senden an den Client zurück Es ist klar, dass der Haupt-Thread nur für den Empfang neuer Verbindungen verantwortlich ist und die Unter-Threads für den Abschluss der nachfolgenden Geschäftsverarbeitung verantwortlich sind. Gleichzeitig ist die Interaktion zwischen dem Haupt-Thread und den Unter-Threads sehr einfach -Threads erhalten den Hauptthread, sodass Sie sich auf die Geschäftsverarbeitung konzentrieren können, ohne auf den Hauptthread zu achten. Sie können die Verarbeitungsergebnisse direkt im Unterthread an den Client senden.

             Dieses Reactor-Modell eignet sich für Szenarien mit hoher Parallelität, und das Netty-Netzwerkkommunikations-Framework übernimmt diese Implementierung ebenfalls

  4. Vor- und Nachteile von Reactor:

  (1) Schnelle Reaktion, keine Notwendigkeit, durch eine einzige Synchronisationszeit blockiert zu werden. obwohl Reactor selbst immer noch synchron ist;

  (2) Kann komplexe Multithreading- und Synchronisierungsprobleme weitestgehend vermeiden und Multithread-/Prozesswechsel-Overhead vermeiden

  (3) Skalierbarkeit, Sie können die Anzahl von Reactors leicht erhöhen Instanzen nutzen die CPU-Ressourcen voll aus;

  (4) Wiederverwendbarkeit, das Reaktormodell selbst hat nichts mit spezifischer Ereignisverarbeitungslogik zu tun und weist eine hohe Wiederverwendbarkeit auf.

Das obige ist der detaillierte Inhalt vonWas ist das Konzept des Reaktornetzwerkmodells in Java IO?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!