Grafische Analyse des Redis-Thread-Modells

Dieser Artikel bringt Ihnen relevantes Wissen über Redis, das hauptsächlich Probleme im Zusammenhang mit dem Thread-Modell vorstellt. Ich hoffe, es wird für alle hilfreich sein.

Empfohlenes Lernen: Redis-Video-Tutorial

Redis ist ein einzelner Thread, der beachtet werden muss.

Zuallererst werden wir einen Client haben, der tatsächlich ein Tool wie den Redis-Client verwendet hat, um eine Verbindung zum Redis-Server vor uns herzustellen.
Wenn wir es später in Java integrieren, wird der entsprechende Client tatsächlich in Java bereitgestellt.

Dann haben wir einen Redis-Server, der eigentlich einer unserer Redis ist. Nachdem der gesamte Dienst gestartet wurde, wird er einen Prozess haben.
In unserer Veröffentlichung gibt es tatsächlich zwei interne Dinge.

Zuallererst wird es einen Multiplexer haben, den wir bereits in der vorherigen Lektion vorgestellt haben. Es handelt sich um ein nicht blockierendes Modell.
Dann gibt es tatsächlich einen Dateiereigniszuordner, der speziell zum Zuweisen einiger Ereignisse verwendet wird.

Darunter wird es in drei verschiedene Prozessoren unterteilt, schauen wir uns jeden einzelnen an.

Zuerst gibt es einen Verbindungsantwort-Handler, und schließlich gibt es einen Befehlsanforderungs-Handler und einen Befehlsantwort-Handler.

Wie ist es zu verstehen? Schauen wir uns zunächst einen Verbindungsantwort-Handler an.

Bei der Verbindung mit dem Antwortprozessor besteht eine seiner Hauptfunktionen darin, eine Verbindung mit unserem Kunden aufrechtzuerhalten.
Sobald einer unserer Redis-Server gestartet ist, wird tatsächlich ein Leseereignis mit unserem Verbindungs-Responder gebündelt.
Der vollständige Name lautet eigentlich AE_readable. Sie können es sich als Zeichen vorstellen, es wird ein solches Ereignis haben und dieses Ereignis wird mit unserem Verbindungsantwortprozessor gebündelt.

Wenn einer unserer Clients schließlich eine Verbindung zu unserem Server herstellen möchte, bedeutet dies tatsächlich, dass wir zu Beginn einen Redis-Client eingegeben haben, der mit unserem Server verbunden werden muss eine Verbindung herstellen. Beim Herstellen einer Verbindung wird tatsächlich ein Leseflag gesendet, was tatsächlich eine Lesezeit ist. Zu diesem Zeitpunkt verfügt unser Redis-Server tatsächlich über einen Server-Socket.

Der Server-Socket entspricht tatsächlich einem unserer Client-Sockets. Sie sind ein Teil des Inhalts in der Netzwerkprogrammierung und die Kommunikation zwischen ihnen ist ein Socket. Nachdem wir mit einem Ereignis wie „read“ in Kontakt gekommen sind, übergeben wir es zur Verarbeitung an unseren Multiplexer.
Wenn Sie es ihm zur Verarbeitung überlassen, blockiert er es tatsächlich nicht. Sobald er es erhält, wird er es in einen Pfeil wie unseren stecken.

Diesen Pfeil hier können wir tatsächlich als Pipeline oder auch als Warteschlange bezeichnen. Es wird hier eingeworfen. Nach dem Einwerfen erreicht diese Welt tatsächlich unseren Dateiereignis-Dispatcher. Wenn dieser Allokator erkennt, dass es sich um ein Leseereignis handelt, gleicht er unseren Verbindungsantwortprozessor ab, dh übergibt ihn zur Verarbeitung an ihn.
Es ist eine Lektüre, die zueinander passt.
Zu diesem Zeitpunkt kann tatsächlich angezeigt werden, dass unser Client und unser Server eine Verbindung hergestellt haben. Nachdem die Verbindung hergestellt wurde und das Leseflag verwendet wird, wird dieses Ereignis tatsächlich an unseren Befehlsanforderungsprozessor übergeben. Wenn dieser Befehl den Prozessor anfordert, können Sie ihn sich als eine spezifische Verarbeitungsanfrage, also eine Anfrage, vorstellen. Dann kann der Befehlsantwortprozessor als Antwort, also als Antwort, verstanden werden.

Dann müssen wir vielleicht etwas auf der Client-Seite tun, zum Beispiel einen Wert festlegen, oder? Wenn Sie einen Wert festlegen, beispielsweise set name ***, handelt es sich tatsächlich um einen Befehl.
Bei diesem Befehl ist einer seiner Welttypen tatsächlich ein Lesevorgang. Dann wird es über den Server-Socket an den Multiplexer geworfen. Nach dem Empfang wird es in unsere Warteschlange gestellt und dann an den Dateiereignis-Dispatcher übergeben.

Nach Erhalt dieses Dateiereigniszuordners wird eine Beurteilung vorgenommen und festgestellt, dass das übereinstimmende Ereignis ein Leseereignis ist. Wenn es sich zu diesem Zeitpunkt um ein Leseereignis handelt, wird unser Befehlsanforderungsprozessor aufgefordert, unseren Befehl zu verarbeiten. Er wird erkennen, dass es sich bei dem aktuellen Namen um einen festen Namen handelt, also wird er einen Prozess durchführen. Er möchte einen von unserem Benutzer festgelegten Inhalt speichern und diesen Schlüsselwert in unserem Gedächtnis speichern. Dies ist eigentlich die Verarbeitung einer Befehlsanforderung, bei der es sich um eine Anfrage handelt.

Nach der Verarbeitung wird ein Weiß zugewiesen, bei dem es sich um eine schriftliche Kennung handelt. Wenn dieses Logo hier steht, können wir es tatsächlich als Antwort verwenden. Denn nachdem eine unserer Anfragen tatsächlich verarbeitet wurde, nachdem wir mit der Eingabe eines Befehls fertig sind, sehen wir möglicherweise ein OK, oder? Wenn dies in Ordnung ist, entspricht es tatsächlich einem Inhalt, der von einem unserer Befehlsantwortprozessoren an uns zurückgeschrieben wird. Er wird also eine von einem Schreiber geschriebene Markierung verwenden. Auf diese Weise wird eines unserer geschriebenen Tags tatsächlich mit unserem Befehlsantwortprozessor gebündelt. Der vollständige Name von write ist eigentlich ein Ereignistyp namens AE_writable.

Okay, dann müssen wir bei unserem Kunden tatsächlich eine Rückschreibung durchführen. Es ist in Ordnung, oder wenn wir die Liste abfragen und den gesamten Inhalt der Liste anzeigen möchten, handelt es sich tatsächlich um ein Zurückschreiben. Wir möchten den Inhalt am unteren Rand der Konsole anzeigen, bei dem es sich um einen Ereignistyp wie „Schreiben“ handelt. Anschließend wird es an unseren Multiplexer übergeben und dann in eine unserer Warteschlangen geworfen, die einem unserer Dateiereignis-Dispatcher zugewiesen ist. Diesmal werden unsere Web-Events aufeinander abgestimmt sein. Das Web-Event ist abgeglichen.

Anschließend führt unser Befehlsantwortprozessor ein Zurückschreiben durch. Darin wird unser OK oder die Nummer einer von uns erhaltenen Liste, der Inhalt der Liste usw. angegeben. Solange Inhalte angezeigt werden müssen, werden diese als Antwort verwendet. Das heißt, der Inhalt der Antwort wird an einen unserer Clients zurückgeschrieben und auf dem Client angezeigt. In unserem aktuellen Gesamtmodell gibt es tatsächlich zwei verschiedene Ereignisse, eines namens lesbar und das andere namens beschreibbar.

Natürlich richten wir jetzt nur einen Kunden ein. Wenn wir mehrere Kunden haben, sind ihre Prinzipien genau die gleichen. Dies ist eigentlich ein Threading-Release-Modell. Es kann schwierig sein, es zu verstehen, wenn man zum ersten Mal damit in Berührung kommt, aber das spielt keine Rolle. Dieses Bild kann tatsächlich jedem helfen, diese Absicht zu vertiefen.

Dann lässt sich auch sein gesamter Verarbeitungsprozess nachvollziehen, wenn man dem folgt, was ich gesagt habe. Um das Verständnis für alle zu erleichtern, zeichnen wir hier ein Bild als Beispiel.

Angenommen, wir haben jetzt einen KTV und dieser KTV ist Redis.

Dann haben wir viele Kunden, die singen wollen, es wird auf jeden Fall Mitarbeiter in unserem KTV geben. Wir werden die Mitarbeiter in zwei Kategorien einteilen.
Die erste Kategorie ist die Rezeptionistin an der Tür und die zweite Kategorie ist der Lobbymanager.
Die Rezeptionistin an der Tür ist eigentlich ein Multiplexer und der Lobbymanager ist eigentlich ein Dateiverteiler.

Dann müssen unsere Kunden entsprechende Wünsche oder Bedürfnisse haben. Zu diesem Zeitpunkt müssen sie unsere Rezeptionistin an der Tür fragen und die Rezeptionistin an der Tür eine einfache Bearbeitung überlassen.
Vielleicht möchte er sehen, an welchen Aktivitäten der Benutzer teilnehmen möchte, ob es Gutscheine gibt usw.

Dann kann der Besteller an der Tür, wenn er sicher ist, dass der Kunde singen möchte, sagen, bitte geh nach hinten, da ist ein Durchgang dahinter. Dieser Durchgang ist eigentlich eine Warteschlange, um zu diesem Durchgang zu gelangen. Wenn Sie hineingehen, ist es ein Geschäftsraum für unser gesamtes KTV. In der Geschäftshalle wird es einen Lobbymanager geben. Der Lobbymanager wird eine echte Anfrage eines unserer Kunden bearbeiten.

Dann werden wir in einem unserer KTVs tatsächlich eine Box haben, in der sich Benutzer und unterschiedliche Anfragen von Kunden bearbeiten lassen. In unserer Box werden sich drei junge Damen oder junge Brüder befinden, die sich um die unterschiedlichen Bedürfnisse der Benutzer kümmern.

Beim ersten geht es zum Beispiel darum, den Kunden die Tür zu öffnen. Das Öffnen der Tür entspricht der Herstellung einer Verbindung zwischen einem unserer Kunden und der Veröffentlichung. Sobald sich die Tür öffnet, kannst du reinkommen, oder? Nach seinem Eintritt ist diese junge Dame nicht mehr für seine entsprechende Arbeit verantwortlich. Er wird ihn an einen unserer Untergebenen übergeben. Die folgende junge Dame oder sein Bruder werden einige Anfragen speziell für Benutzer bearbeiten.

Wenn beispielsweise ein Kunde einen Song anfordert, wird die Person, die den Song angefordert hat, gebeten, eine entsprechende Bearbeitung vorzunehmen. Die Lösung für dieses Problem besteht darin, den Computer einzuschalten, um Lieder zu bestellen und auszuwählen. Nachdem Sie den Song ausgewählt haben, müssen Sie dem Kunden antworten. Du hast Recht, oder? Sie müssen den Kunden auch einige Mikrofone geben, daher wird zu diesem Zeitpunkt eine Benachrichtigung angezeigt, dass es eine solche junge Dame gibt, und diese junge Dame wird dem Kunden das Mikrofon geben. Du kannst jetzt singen gehen. Wir haben dieses Lied bereits für dich bestellt.

Zu diesem Zeitpunkt ist die gesamte Aktion eines Kunden, der ein Lied anfordert und im KTV singt, tatsächlich abgeschlossen. Dies entspricht tatsächlich einem von einem Client ausgeführten Vorgang, den wir zuvor im Release-Thread-Modell erwähnt haben. Zuerst wird die Verbindung aufgebaut, dann wird die Anfrage bearbeitet und dann wird auf eine der Anfragen geantwortet. Insgesamt gibt es drei Schritte.

In unserem Bereich werden der gesamte Lobbymanager und seine Songanfragebenachrichtigungen tatsächlich intern bearbeitet. Das basiert auf einer unserer Boxen. Können wir den privaten Raum in unserem Redis als Speicher verwenden, da Vorgänge wie Speichern und Lesen in Redis tatsächlich auf dem Speicher basieren? Es ist also sehr schnell, wenn es im Speicher ist.

Wenn Sie sich in unserem Privatraum befinden, können Sie im Privatraum singen, Obst bestellen, Bier trinken usw. Wenn alle Vorgänge auf einer unserer internen Boxen basieren, werden deren Aktionsreihen usw. tatsächlich sehr schnell abgeschlossen.

Dies kann tatsächlich ein einfaches Verständnis für eines unserer Thread-Modelle sein. Bei unserem Redis handelt es sich tatsächlich um einen Single-Threaded-Modus. Warum ist die Verwendung eines Single-Threaded-Modells sehr schnell?

Eigentlich gibt es zwei Hauptpunkte.
Der erste Punkt ist, dass einer unserer Türsprecher eigentlich ein Multiplexer ist. Dieser Multiplexer basiert auf einem nicht blockierenden Modell und wird daher sehr schnell verarbeitet. Aufgrund des vorherigen Blockierungsmodus wird nicht nacheinander auf Antworten gewartet. Wenn nun ein Modell wie ein IO-Multiplexer verwendet wird, ist seine Verarbeitungsleistung tatsächlich sehr, sehr schnell.

Der andere Teil ist unser Lobby-Manager. Dieser Teil basiert tatsächlich auf dem Gedächtnis. Bei reinen Speicheroperationen wird es tatsächlich sehr, sehr schnell sein.

Natürlich wurde nach der Verwendung eines einzelnen Threads auch eine seiner Funktionen erwähnt. Wenn ein einzelner Thread verwendet wird, kann Multithreading vermieden werden. Denn wenn Sie mehrere Threads haben, können Sie einen seiner Kontextschalter verwenden. Nach dem Umschalten kann es zu Problemen kommen. Darüber hinaus können auch entsprechende Verluste vermieden werden. Wenn wir also das Trunk-Modell verwenden, sind seine Parallelität und Effizienz sehr, sehr hoch.

Empfohlenes Lernen: Redis-Video-Tutorial

Das obige ist der detaillierte Inhalt vonGrafische Analyse des Redis-Thread-Modells. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!