Nachdem Redis 6.0 das Design des Single-Thread-Modells aufgegeben hatte, begann Redis, selektiv das Multi-Thread-Modell zu verwenden. Es scheint, dass der Autor von Redis so großartig ist, dass es kein Entrinnen gibt ) Warum hat sich Redis am Anfang für ein Single-Thread-Modell entschieden (die Vorteile von Single-Threading)?
Eigentlich ist es nicht so, dass der Autor dem Theorem des wahren Duftes nicht entgangen wäre, aber mit der Zeit treten immer mehr Probleme auf. Das ursprüngliche Design ist definitiv veraltet und es sollten Änderungen vorgenommen werden. OK, mit zwei Fragen, analysieren wir sie sorgfältig.
2. Warum hat Redis am Anfang Single-Threads oder Multi-Threads verwendet, alles dient dazu, die Entwicklungseffizienz von Redis zu verbessern, da Redis eine speicherbasierte Datenbank ist und auch eine große Anzahl von Threads verarbeiten kann Externe Netzwerkanforderungen Es ist unvermeidlich, mehrere IOs durchzuführen. Glücklicherweise verwendet Redis viele hervorragende Mechanismen, um seine hohe Effizienz sicherzustellen. Warum ist Redis im Single-Thread-Modus konzipiert? Es lässt sich wie folgt zusammenfassen:
(1) IO-Multiplexing
Werfen wir einen Blick auf das Top-Level-Design von Redis.
FD ist ein Dateideskriptor, der angibt, ob die aktuelle Datei lesbar, beschreibbar oder abnormal ist. Verwenden Sie den E/A-Multiplexmechanismus, um den Lese- und Schreibstatus mehrerer Dateideskriptoren gleichzeitig zu überwachen.
Sie können es als Multithreading-Eigenschaft verstehen.Sobald eine Netzwerkanfrage eingeht, wird sie schnell im Speicher verarbeitet. Da die meisten Vorgänge rein speicherbasiert sind, ist die Verarbeitungsgeschwindigkeit sehr hoch.
Das heißt, im Single-Thread-Modus kann die Verarbeitung aufgrund des E/A-Multiplexings bei der Hochgeschwindigkeitsspeicherverarbeitung ignoriert werden, auch wenn viel verbundene Netzwerkverarbeitung vorhanden ist.(2) Hohe WartbarkeitObwohl das Multithreading-Modell eine gute Leistung erbringt, führt es zu Unsicherheiten in der Reihenfolge der Programmausführung, was zu Problemen im Zusammenhang mit gleichzeitigem Lesen und Schreiben führt. Der Single-Threaded-Modus ermöglicht einfaches Debuggen und Testen.
(3) Basierend auf dem Speicher ist die Effizienz im Single-Threaded-Zustand immer noch hochMulti-Threading kann die CPU-Ressourcen voll ausnutzen, aber für Redis ist die speicherbasierte Geschwindigkeit ziemlich hoch und kann 10 If verarbeiten Wenn 100.000 Benutzeranfragen pro Sekunde nicht erfüllt werden, können wir sie mithilfe der Redis-Sharding-Technologie an verschiedene Redis-Server senden. Diese Kochmethode vermeidet die Einführung vieler Multithread-Vorgänge im selben Redis-Dienst.
Sofern keine AOF-Sicherung erforderlich ist, erfordert dieser Vorgang grundsätzlich keine E/A-Vorgänge, da er speicherbasiert ist. Da das Lesen und Schreiben dieser Daten nur im Speicher erfolgt, ist die Verarbeitungsgeschwindigkeit sehr hoch. Die Verwendung eines Multithreading-Modells zur Verarbeitung aller externen Anforderungen ist möglicherweise keine gute Lösung.
Jetzt wissen wir, dass es im Grunde in zwei Sätzen zusammengefasst werden kann. Basierend auf dem Speicher und der Verwendung der Multiplexing-Technologie ist Single-Threading sehr schnell und gewährleistet die Eigenschaften von Multi-Threading. Weil es nicht notwendig ist, Multithreading zu verwenden.3. Warum wird Multithreading eingeführt?
Gerade haben wir die Vorteile von Single-Threading erwähnt, aber jetzt möchte ich darüber sprechen, warum wir Multi-Threading einführen und die damit verbundenen Unannehmlichkeiten überwinden müssen. Die Einführung von Multi-Threading zeigt, dass Single-Threading in einigen Aspekten von Redis keine Vorteile mehr hat.
Da die Lese-/Schreibsystemaufrufe zum Lesen und Schreiben im Netzwerk während der Redis-Ausführung den größten Teil der CPU-Zeit beanspruchen, wird die Leistung erheblich verbessert, wenn das Lesen und Schreiben im Netzwerk multithreading erfolgt. Das Multithreading von Redis wird nur zum Lesen und Schreiben von Netzwerkdaten sowie zum Parsen von Protokollen verwendet, während die Befehlsausführung weiterhin Single-Threading erfolgt. Der Grund für dieses Design ist, dass wir nicht möchten, dass Redis aufgrund von Multithreading kompliziert wird, und dass wir Parallelitätsprobleme wie Schlüssel, Lua, Transaktionen, LPUSH/LPOP usw. kontrollieren müssen.
Wir wissen, dass Redis den Befehl del verwenden kann, um ein Element zu löschen, das Dutzende oder Hunderte von Megabyte belegen kann. Dies erfordert asynchrone Multithread-Unterstützung.
Das Löschen kann jetzt im Hintergrund erfolgen.
Das obige ist der detaillierte Inhalt vonWarum führt Redis Multithreading ein?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!