In der Vergangenheit gab es immer ein Missverständnis, dass Hochleistungsserver mit Multithreads implementiert werden müssen
Der Grund ist ganz einfach verursacht durch Missverständnis 2: Multithreading muss besser sein als Singlethreading. Threads sind hocheffizient. Nicht wirklich.
Redis Core bedeutet, dass mein Single-Thread-Vorgang am effizientesten ist, wenn sich alle meine Daten im Speicher befinden. Warum, denn das Wesentliche beim Multithreading ist, dass die CPU mehrere simuliert Threads Diese simulierte Situation hat Kosten, nämlich Kontextwechsel. Für ein Speichersystem ist es am effizientesten, wenn kein Kontextwechsel erfolgt.
Redis verwendet eine einzelne CPU, um ein Stück Speicherdaten zu binden, und wenn dann die Daten in diesem Speicher mehrmals gelesen und geschrieben werden, erfolgt alles auf einer CPU, es handelt sich also um eine einzelne -Thread-Prozess. Im Speicherbereich ist diese Lösung die beste Lösung. (Empfohlen: „Redis-Video-Tutorial“)
Da ein CPU-Kontextwechsel etwa 1500 ns dauert.
Das Lesen von 1 MB kontinuierlicher Daten aus dem Speicher dauert etwa 250 us. Angenommen, 1 MB Daten werden 1000 Mal von mehreren Threads gelesen, dann gibt es 1000 Zeitkontextwechsel,
Dann sind es 1500 ns * 1000 = 1500 us. Es dauert nur 250 us, um 1 MB Daten in einem einzelnen Thread zu lesen. Ich berücksichtige nicht die Zeit, die Sie jedes Mal zum Lesen einiger Daten benötigen 🎜>Wann sollten Sie eine Multithread-Lösung verwenden?
Die Antwort lautet: Der untere Speicher ist langsam. Zum Beispiel ist der Festplattenspeicher
ein System mit sehr hohen IOPS, denn wenn ich einen Teil des Speichers beantragen möchte, beantrage ich einen Teil des Speichers, und wenn ich einen Teil des Speichers zerstöre, zerstöre ich ihn ein Stück Erinnerung Es ist sehr einfach, Erinnerung zu beantragen und zu zerstören. Und die Speichergröße kann dynamisch angepasst werden.
Die Eigenschaften von Festplatten sind: IPOS ist sehr niedrig, aber der Durchsatz ist sehr hoch. Dies bedeutet, dass eine große Anzahl von Lese- und Schreibvorgängen gesammelt und dann an die Festplatte übergeben werden muss, um die höchste Leistung zu erzielen. Warum?
Wenn ich eine Transaktionsgruppenoperation (dh mehrere separate Transaktionsanforderungen wie Schreiben, Lesen, Schreiben, Lesen und Schreiben, diese fünf Operationen sind zusammen) im Speicher habe, weil die IOPS sehr hoch sind hoch, ich Es kann einzeln abgeschlossen werden, aber wenn sich auch diese Anforderungsmethode auf der Festplatte befindet,
Mein erster Schreibvorgang wird folgendermaßen abgeschlossen: Ich adressiere zuerst auf der Festplatte, was etwa 10 ms dauert , und dann lese ich Ein Datenelement kann 1 ms dauern und dann berechne ich es erneut (ignoriere es) und schreibe es dann zurück auf die Festplatte und es dauert weitere 10 ms, insgesamt 21 ms
Der zweite Vorgang Das Lesen dauert 10 ms, das Schreiben des dritten Vorgangs dauert 10 ms und das Schreiben dauert insgesamt 83 ms weniger als 1ms.
Für die Festplatte, deren Durchsatz so hoch ist, besteht die beste Lösung definitiv darin, N Anfragen in einem Buff zusammenzufassen und sie dann zusammen einzureichen.
Die Methode besteht darin, asynchron zu verwenden: Binden Sie die Anforderung nicht an den Verarbeitungsthread, der anfordernde Thread fügt die Anforderung in einen Buff ein und wartet dann, bis der Buff fast voll ist, und dann verarbeitet der Verarbeitungsthread die Anforderung polieren. Dann wird dieser Buff verwendet, um gleichmäßig auf die Festplatte zu schreiben oder die Festplatte zu lesen, sodass die Effizienz am höchsten ist. Wird IO in Java nicht so gemacht?
Für langsame Geräte ist diese Verarbeitungsmethode die beste. Zu den langsamen Geräten gehören Festplatten, Netzwerke, SSDs usw.,
mehr Es ist sehr Es ist üblich, diese Probleme auf Thread- und asynchrone Weise zu lösen. Dies ist, was das berühmte Netty tut.
Abschließend habe ich klargestellt, warum Redis Single-Threading ist und wann Single-Threading und Multi-Threading verwendet werden sollten. Tatsächlich ist es auch eine sehr einfache Sache, aber es ist wirklich peinlich, wenn es darum geht ist nicht gut. . . .
Zitate des Biyifa-Meisters: Lassen Sie uns darüber sprechen, warum eine Single-Core-CPU am effizientesten ist, wenn sie an einen Teil des Speichers gebunden ist
„Wir können die Last des Betriebssystems nicht ausgleichen lassen, weil wir unsere eigene kennen.“ Programme besser, sodass wir ihm manuell CPU-Kerne zuweisen können, ohne die CPU zu sehr zu beanspruchen.“ Standardmäßig verwendet ein einzelner Thread zufällig CPU-Kerne, wenn er Systemaufrufe durchführt. Um Redis zu optimieren, können wir Tools verwenden, um einzelne Thread Binden Sie feste CPU-Kerne, um unnötige Leistungsverluste zu reduzieren!
Als Einzelprozessmodellprogramm startet Redis oft mehrere Instanzen auf einem Server, um Multi-Core-CPUs voll auszunutzen.Um die Kosten für den Wechsel zu reduzieren, ist es notwendig, die CPU anzugeben, auf der jede Instanz läuft. Taskset unter Linux kann einen Prozess an eine bestimmte CPU binden. Sie kennen Ihr Programm besser als das Betriebssystem, um zu vermeiden, dass der Scheduler Ihr Programm dumm plant, oder um den Overhead der Cache-Ungültigmachung in Multithread-Programmen zu vermeiden.
Das obige ist der detaillierte Inhalt vonWarum ist Redis Single-Threaded?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!