Die Kernverarbeitungslogik von Redis war schon immer Single-Threaded. Einige Zweigmodule sind Multithreading (einige asynchrone Prozesse verwenden Multithreading ab 4.0, wie z. B. UNLINK, FLUSHALL ASYNC, FLUSHDB ASYNC und andere nicht blockierende Löschvorgänge. Netzwerk I/O-Lösung Das Paket nutzt Multithreading ab 6.0 ;)
Warum Single-Thread
Wie gut eignet sich Multithreading, um die Vorteile mehrerer Kerne zu nutzen?
offizielle Erklärung
Dies bedeutet, dass die Positionierung von Redis ein Speicher-KV-Speicher ist, der für die kurzfristige und schnelle Hot-Spot-Datenverarbeitung verwendet wird . Im Allgemeinen erfolgt die Ausführung sehr schnell. Die Ausführung selbst stellt keinen Engpass dar, und der Engpass ist es normalerweise Netzwerk-E/A. Die Verarbeitung logischer Multithreads wird nicht zu viel sein. Große Gewinne.
Gleichzeitig hält Redis selbst an dem Konzept der Einfachheit und Effizienz fest. Die Einfachheit und Wartbarkeit des Codes sind seit langem das Streben von Redis. Die durch die Einführung von Multithreading verursachte Komplexität ist weitaus größer als gedacht, und Multi-Threading Auch das Einfädeln selbst verursacht zusätzliche Kosten. , ausführlicher
1. Die Einführung von Multithreading bringt große Komplexität mit sich
1. Erstens existiert nach der Einführung von Multithreading die ursprüngliche sequentielle Ausführungsfunktion von Redis nicht mehr. Um die Atomizität und Isolation von Transaktionen zu unterstützen, muss Redis einige sehr komplexe Implementierungen einführen. 2. Die
Daten Die Struktur von Redis ist äußerst effizient. Viele Funktionsoptimierungen wurden im Single-Thread-Modus vorgenommen. Wenn Multi-Threading eingeführt wird,
müssen alle zugrunde liegenden Datenstrukturen in Thread-Sicherheit umgewandelt werden, was eine äußerst komplizierte Aufgabe sein wird;
3. Darüber hinaus Der Multithread-Modus erleichtert auch das Debuggen von Programmen. Komplexität und Probleme verursachen zusätzliche Entwicklungskosten und Betriebskosten, und es ist auch einfacher, Fehler zu machen (denken Sie an die Parallelität von MYSQL ...).
2. Multithreading bringt zusätzliche Kosten mit sich
1. Kosten für den Kontextwechsel. Für die Multithread-Planung ist ein Wechsel des Thread-Kontexts erforderlich. Dieser Vorgang speichert zunächst die lokalen Daten, den Programmzeiger usw. des aktuellen Threads und lädt dann die Daten eines anderen Threads. Die Kosten für diesen Kernel-Vorgang können nicht anfallen ignoriert.
2. Der Overhead des Synchronisationsmechanismus. Auf einige öffentliche Ressourcen kann direkt im Single-Thread-Modus zugegriffen werden. Multi-Threads müssen durch Sperren und andere Methoden synchronisiert werden. Dies ist auch ein CPU-Overhead, der nicht ignoriert werden kann; 3.
Ein Thread selbst belegt auch Speicher. Größe: Für In-Memory-Datenbanken wie Redis ist Speicher sehr wertvoll, und die durch Multithreading selbst verursachten Kosten für die Speichernutzung erfordern ebenfalls eine sorgfältige Entscheidungsfindung.
Warum ist Single-Thread so schnell?
Erstens werden die meisten Vorgänge von Redis im Speicher abgeschlossen, und der Speichervorgang selbst ist sehr schnell.
Zweitens strebt Redis das Ultimative an, hat viele effiziente Datenstrukturen ausgewählt und viele Optimierungen vorgenommen, z. B. Ziplist, Hash und Skip Tabellen. Manchmal gibt es mehrere zugrunde liegende Implementierungen eines Objekts, um unterschiedliche Szenarien zu bewältigen.
Drittens verwendet Redis einen Multiplex-Mechanismus, um eine große Anzahl von Client-Anfragen gleichzeitig im Netzwerk-I0-Betrieb zu verarbeiten und einen hohen Durchsatz zu erreichen.
Der erste und der zweite Punkt sind ziemlich einfach zu verstehen. Wie sagen Sie den dritten Punkt?
Was ist I/0-Multiplexing? Einfach ausgedrückt: Wenn eine I/0-Operation ausgelöst wird, wird eine Benachrichtigung generiert. Nach Erhalt der Benachrichtigung wird das der Benachrichtigung entsprechende Ereignis verarbeitet. Für I/0-Multiplexing verfügt Redis eine Verpackungsschicht namens Reaktormodell.
Das Wesentliche besteht darin, verschiedene Ereignisse abzuhören und sie bei Eintreten des Ereignisses an verschiedene Prozessoren zu verteilen.
Auf diese Weise wird es bei einem bestimmten Vorgang nicht blockiert und die Leistung kann voll genutzt werden. Man kann sagen, dass E/A-Multiplexing Redis-Einzelthreads einen höheren Grad an Parallelität ermöglicht. Beachten Sie, dass es sich dabei um Parallelität und nicht um Parallelität handelt. In diesem Modus kann man sagen, dass die Leistung des Redis-Einzelkerns vollständig genutzt wird.
Aber
Das Geschäftsvolumen ist jetzt wirklich zu groß
Wie bereits erwähnt, liegt der Hauptgrund, warum Redis sich für Single-Threading entscheidet, darin, dass Redis ausschließlich Speicheroperationen durchführt und die CPU-Verarbeitung sehr schnell ist. Der Engpass tritt eher bei E/A als bei der CPU auf, daher wurde das Single-Threaded-Modell gewählt .
Mit der Entwicklung der Zeit hat das Anforderungsvolumen vieler Unternehmen ein einst unvorstellbares Niveau erreicht. E/A-Vorgänge sind in der Tat zu einem Engpass geworden. Im vorherigen Redis-Verarbeitungsprozess waren das Lesen von Anforderungen und das Senden von Rückgabepaketen allesamt E/A Operationen. Deshalb hat Redis Multithreading eingeführt. Multithreading bedeutet hier nicht, dass die gesamte Verarbeitungslogik Multithreading ist. Wenn Sie dies tun, müssen alle Datenstrukturen threadsicher rekonstruiert werden. Dies ist mit enormen Kosten verbunden ist möglicherweise nicht möglich. Wie groß ist die Verbesserung? Sie kann aufgrund von Verlusten sogar reduziert werden. Schließlich wird der Engpass die meiste Zeit nicht behoben. Der Engpass liegt tatsächlich im Allgemeinen im Netzwerk-I/O.
Aufgrund der oben genannten Situation entschied sich Redis für die Einführung von Multithreading zur Abwicklung von Netzwerk-E/A und verwendete weiterhin ein Single-Thread-Framework zur Ausführung von Redis-Befehlen. Dadurch wird nicht nur die Single-Thread-Verarbeitungsarchitektur des Redis-Kerns beibehalten, sondern vollständig Kompatibel mit früheren Implementierungen, führt aber auch Multithreading ein. Lösen Sie das Problem der Verbesserung der Netzwerk-E/A-Leistung.
Sie müssen nicht viel über Multithreading wissen
Zunächst einmal wurde Multithreading nach 6.0 eingeführt. Um mit der zunehmenden Datenmenge fertig zu werden, ist es standardmäßig deaktiviert. Sie können es in der .conf ändern. Multithreading ist für die Verarbeitung von Netzwerk-E/A verantwortlich. Speziell
Lesen und analysieren Sie Anweisungen und senden Sie Pakete zurück.
Im Single-Thread-Modus vervollständigt ein Thread das Lesen, Parsen, Ausführen und Einfügen des Rückgabepakets in den Client-Puffer.
Im Multi-Thread-Modus werden jedoch verschiedene Clients in die Aufgabenwarteschlange „clients_pending_read“ gestellt und nachfolgende Aufrufe werden durchgeführt Round Die Round-Robin-Round-Robin-Lastausgleichsstrategie weist diese Clients anderen IO-Threads und dem Hauptthread zum Lesen und Parsen zu; bei der Rücksendung von Paketen wird auch die Round-Robin-Round-Robin-Lastausgleichsstrategie verwendet, um die Aufgaben kontinuierlich und gleichmäßig zu verteilen in der Warteschlange, die auf Paketrückgaben warten. werden den jeweiligen
lokalen FIFO-Aufgabenwarteschlangen der IO-Threads und dem Hauptthread selbst zugewiesen. Der Hauptthread fragt alle IO-Threads ab und wartet darauf, dass sie die Paketrückgabeaufgabe abschließen.