In diesem Artikel erfahren wir mehr über die neuen Funktionen in Redis 6.0. Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird für alle hilfreich sein.
Redis 6.0 ist da
Die stabile Version (GA) von Redis 6.0.0 ist endlich veröffentlicht. Diese Version bietet viele aufregende neue Features und funktionale Verbesserungen, wie das neue Netzwerkprotokoll RESP3 und den neuen Cluster-Agenten. ACL usw. Unter ihnen sollte „Multithreading“ am meisten beunruhigt sein. Lassen Sie uns mit vielen Fragen gemeinsam mit „Neue Funktionen von Redis 6.0“ beginnen. [Verwandte Empfehlungen: Redis-Video-Tutorial]
1 Sind Versionen vor Redis 6.0 wirklich Single-Threaded?
Wenn Redis Client-Anfragen verarbeitet, einschließlich Erfassung (Socket-Lesen), Parsen, Ausführung, Inhaltsrückgabe (Socket-Schreiben) usw., werden sie alle von einem sequentiellen und seriellen Hauptthread verarbeitet. Dies ist der sogenannte „Single“. Faden". Aber streng genommen handelt es sich seit Redis 4.0 nicht mehr um einen Single-Thread. Zusätzlich zum Haupt-Thread verfügt es auch über Hintergrund-Threads, die einige langsamere Vorgänge ausführen, z. B. das Bereinigen schmutziger Daten, das Freigeben nutzloser Verbindungen, das Löschen großer Schlüssel usw.
2. Warum wurde Multithreading vor Redis6.0 nicht verwendet?
Der Beamte hat auf eine ähnliche Frage geantwortet: Bei der Verwendung von Redis gibt es fast keine Situation, in der die CPU zu einem Engpass wird. Redis wird hauptsächlich durch Speicher und Netzwerk begrenzt. Auf einem normalen Linux-System kann Redis beispielsweise mithilfe von Pipelining 1 Million Anfragen pro Sekunde verarbeiten. Wenn die Anwendung also hauptsächlich O(N)- oder O(log(N))-Befehle verwendet, wird sie kaum viel CPU beanspruchen.
Nach der Verwendung eines einzelnen Threads ist die Wartbarkeit hoch. Obwohl das Multithreading-Modell in einigen Aspekten eine gute Leistung erbringt, führt es zu Unsicherheiten in der Reihenfolge der Programmausführung, führt zu einer Reihe von Problemen beim gleichzeitigen Lesen und Schreiben, erhöht die Systemkomplexität und kann zu einem Thread-Wechsel oder sogar zu einem Sperren führen durch Entsperren und Deadlock. Redis verfügt über eine sehr hohe Verarbeitungsleistung durch AE-Ereignismodell und IO-Multiplexing sowie andere Technologien, sodass kein Multithreading erforderlich ist. Der Single-Thread-Mechanismus reduziert die Komplexität der internen Implementierung von Hash erheblich. Rehash, Lpush und andere „Thread-unsichere“ Befehle können ohne Sperren ausgeführt werden.
3. Warum führt Redis6.0 Multithreading ein?
Redis legt alle Daten im Speicher ab und beträgt etwa 100 Nanosekunden. Für 80 % der Unternehmen ist dies auch die Grenze für die Verarbeitung kleiner Datenpakete Dieses Single-Thread-Redis reicht aus.
Aber bei immer komplexeren Geschäftsszenarien können einige Unternehmen problemlos Hunderte Millionen Transaktionen erreichen und benötigen daher größere QPS. Eine gängige Lösung besteht darin, die Daten in einer verteilten Architektur zu partitionieren und mehrere Server zu verwenden. Diese Lösung weist jedoch sehr große Nachteile auf, z. B. zu viele Redis-Server zur Verwaltung und hohe Wartungskosten. Einige Lösungen sind für einen einzelnen Redis-Server geeignet Funktioniert nicht mit Datenpartitionen; Datenpartitionen können Hotspot-Lese-/Schreibprobleme nicht lösen; Neuzuweisung und Skalierung nach oben/unten werden komplexer usw.
Da die Lese-/Schreibsystemaufrufe des Lese- und Schreibnetzwerks während der Redis-Ausführung den größten Teil der CPU-Zeit beanspruchen, ist der Engpass hauptsächlich der E/A-Verbrauch des Netzwerks. Es gibt zwei Hauptrichtungen für die Optimierung :
• Verbessern Sie die Netzwerk-IO-Leistung, typische Implementierungen wie die Verwendung von DPDK als Ersatz für den Kernel-Netzwerkstapel
• Verwenden Sie Multithreading, um Multi-Cores vollständig zu nutzen, typische Implementierungen wie Memcached.
Diese Methode zur Protokollstapeloptimierung hat wenig mit Redis zu tun. Die Unterstützung von Multithreading ist die effektivste und bequemste Betriebsmethode. Zusammenfassend unterstützt Redis Multithreading aus zwei Hauptgründen:
• Es kann die CPU-Ressourcen des Servers vollständig nutzen. Derzeit kann der Hauptthread nur einen Kern verwenden.
• Multithread-Aufgaben können den synchronen IO-Lesevorgang von Redis teilen und schreibe „load
4“. Aktiviert Redis6.0 standardmäßig Multithreading?
Multithreading in Redis 6.0 ist standardmäßig deaktiviert und es wird nur der Hauptthread verwendet. Wenn Sie es aktivieren möchten, müssen Sie die Konfigurationsdatei redis.conf ändern: io-threads-do-reads ja
5 Wenn Redis6.0-Multithreading aktiviert ist, wie wird die Anzahl festgelegt? Threads?
Nachdem Sie Multithreading aktiviert haben, müssen Sie die Anzahl der Threads festlegen, da es sonst nicht wirksam wird. Ändern Sie auch die Konfigurationsdatei redis.conf
Bezüglich der Einstellung der Anzahl der Threads gibt es einen offiziellen Vorschlag: Es wird empfohlen, 4-Kern-Maschinen auf 2 oder 3 Threads einzustellen, 8-Kern-Maschinen werden empfohlen Es muss auf 6 Threads eingestellt werden, und die Anzahl der Threads muss kleiner als die Anzahl der Maschinenkerne sein. Es sollte auch beachtet werden, dass die Beamten glauben, dass mehr als 8 Threads grundsätzlich bedeutungslos sind, je größer die Anzahl der Threads ist.
6. Welchen Effekt hat die Einführung von Multithreading durch Redis6.0?
Redis-Autor Antirez erwähnte beim Teilen auf der RedisConf 2019: Die in Redis 6 eingeführte Multithread-IO-Funktion kann die Leistungsverbesserung mindestens verdoppeln. Inländische Experten haben auch die instabile Version verwendet, um Tests auf Alibaba Cloud esc durchzuführen. Die Leistung des GET/SET-Befehls in 4-Thread-IO ist im Vergleich zu einem einzelnen Thread fast verdoppelt.
Testumgebung:
Redis Server: Alibaba Cloud Ubuntu 18.04, 8 CPU 2,5 GHZ, 8G Speicher, Hostmodell ecs.ic5.2xlarge
Redis Benchmark Client: Alibaba Cloud Ubuntu 18.04, 8 2,5 GHZ CPU, 8G Speicher , Hostmodell ecs.ic5.2xlarge
Testergebnisse:
Einzelheiten finden Sie unter: https://zhuanlan.zhihu.com/p/76788470
Hinweis 1: Diese Leistungsüberprüfungstests sind nicht möglich Strenge Verzögerungskontrolle und Stresstests unter verschiedenen Parallelitätsszenarien. Die Daten dienen lediglich der Verifizierung und können nicht als Online-Indikator verwendet werden.
Hinweis 2: Wenn Sie Multithreading aktivieren, wird empfohlen, mindestens eine 4-Kern-Maschine zu verwenden und die Redis-Instanz viel CPU-Zeit beansprucht hat. Andernfalls macht die Verwendung von Multithreading keinen Sinn. Es wird geschätzt, dass 80 % der Unternehmensentwickler einfach einen Blick darauf werfen werden.
7.Redis6.0 Multithreading-Implementierungsmechanismus? Der Prozess wird wie folgt kurz beschrieben: Der Hauptthread verarbeitet das Leseereignis und übergibt den RR (Round Robin). Weisen Sie diese Verbindungen diesen IO-Threads zu 3. Der Hauptthread blockiert und wartet darauf, dass der IO-Thread das Lesen des Sockets beendet
4. Der Hauptthread führt den Anforderungsbefehl aus in einer Single-Thread-Methode, und die angeforderten Daten werden gelesen und analysiert, aber nicht ausgeführt 5 , der Haupt-Thread blockiert und wartet darauf, dass der IO-Thread die Daten zurück in den Socket schreibt 
6. Lösen Sie die Bindung und löschen Sie das Warten Warteschlange
(Bildquelle: https://ruby-china.org/topics/38957)
Das Design ist wie folgt: Funktionen: 1. Der IO-Thread liest entweder gleichzeitig den Socket oder schreibt darauf 2. Der E/A-Thread ist nur für das Lesen und Schreiben von Socket-Parsing-Befehlen verantwortlich und ist nicht für die Befehlsverarbeitung verantwortlich
8 , Gibt es Sicherheitsprobleme bei der Thread-Parallelität?
Wie aus dem obigen Implementierungsmechanismus ersichtlich ist, wird der Multithread-Teil von Redis nur zum Verarbeiten des Lesens und Schreibens von Netzwerkdaten und der Protokollanalyse verwendet, und die Ausführung von Befehlen erfolgt weiterhin sequentiell in einem einzelnen Thread. Daher müssen wir die Parallelitäts- und Thread-Sicherheitsprobleme bei der Steuerung von Schlüsseln, Lua, Transaktionen, LPUSH/LPOP usw. nicht berücksichtigen. 
Dies unterscheidet sich nicht von der Installation anderer Redis-Versionen. Der gesamte Prozess weist keine Fallstricke auf, daher werde ich ihn hier nicht beschreiben. Zu beachten ist lediglich, dass die Anzahl der konfigurierten Multi-Threads kleiner sein muss als die Anzahl der Kerne der CPU. Überprüfen Sie die Anzahl der Kerne mit dem Befehl:
[root@centos7.5 ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3
10. Vergleichen Sie das Multi-Threading-Modell von Redis 6.0 und das Multi-Threading-Modell von Memcached
In früheren Jahren wurden Memcached-Caching-Lösungen häufig von großen Internetunternehmen verwendet. Daher ist der Unterschied zwischen Redis und Memcached im Grunde eine Frage, die Interviewer in Bezug auf Caching stellen müssen In den letzten Jahren wurde Memcached weniger verwendet und Redis wird hauptsächlich verwendet. Mit der Hinzufügung von Multithreading-Funktionen in Redis 6.0 können jedoch weiterhin ähnliche Probleme auftreten. Als Nächstes werden wir nur einen kurzen Vergleich der Multithreading-Modelle durchführen.
Wie im Bild oben gezeigt: Der Memcached-Server arbeitet im Master-Worker-Modus und der Server verwendet Socket, um mit dem Client zu kommunizieren. Der Hauptthread und der Arbeitsthread verwenden Pipes zur Kommunikation. Der Hauptthread verwendet libevent, um die Leseereignisse von Listen und Accept zu überwachen, kapselt die Datenstruktur der Verbindungsinformationen, wählt den entsprechenden Arbeitsthread gemäß dem Algorithmus aus und verteilt die Verbindungsaufgabe, die die Verbindungsinformationen trägt Der entsprechende Thread verwendet den Verbindungsdeskriptor, um den Socket des Clients herzustellen und nachfolgende Datenzugriffsvorgänge auszuführen. Vergleich zwischen Redis6.0- und Memcached-Multithreading-Modellen:
Ähnlichkeit: Beide übernehmen das Master-Thread-Worker-Thread-Modell Unterschied: Memcached führt auch die Hauptlogik im Worker-Thread aus, das Modell ist einfacher und es gibt eine echte Thread-Isolation erreicht, was unserem herkömmlichen Verständnis der Thread-Isolation entspricht. Redis gibt die Verarbeitungslogik an den Master-Thread zurück, obwohl es die Komplexität des Modells bis zu einem gewissen Grad erhöht, aber auch Probleme wie die Thread-Parallelitätssicherheit löst.
11. Wie kommentieren die Redis-Autoren das neue Feature „Multi-Threading“?
Bezüglich der Funktion von Multithreading erklärte Antirez einmal in 6.0 RC1:
Redis unterstützt Multithreading auf zwei Arten: Die erste ist wie „memcached“, bei der eine Redis-Instanz mehrere Threads öffnet und dadurch die Anzahl der Operationen erhöht, die pro Sekunde in einfachen Befehlen wie GET/SET ausgeführt werden können. Dies beinhaltet Multithread-Verarbeitung wie E/A- und Befehlsanalyse, daher nennen wir es „E/A-Threading“. Die andere besteht darin, die Ausführung langsamerer Befehle in verschiedenen Threads zu ermöglichen, um sicherzustellen, dass andere Clients nicht blockiert werden. Wir nennen dieses Threading-Modell „Langsames Befehls-Threading“.
Nach sorgfältiger Überlegung wird Redis kein „I/O-Threading“ verwenden. Redis wird während der Laufzeit hauptsächlich durch das Netzwerk und den Speicher begrenzt, sodass die Verbesserung der Redis-Leistung hauptsächlich durch mehrere Redis-Instanzen, insbesondere Redis-Cluster, erfolgt. Als nächstes betrachten wir hauptsächlich zwei Aspekte der Verbesserung:
1. Mehrere Instanzen des Redis-Clusters können die Festplatte der lokalen Instanz durch Orchestrierung sinnvoll nutzen, um ein gleichzeitiges Umschreiben von AOF zu vermeiden.
2. Stellen Sie einen Redis-Cluster-Proxy bereit, um Benutzern das Abstrahieren eines Clusters zu erleichtern, wenn es keinen besseren Cluster-Protokoll-Client gibt.
Darüber hinaus ist Redis ein Speichersystem wie Memcached, unterscheidet sich jedoch von Memcached. Multithreading ist komplex und es muss ein einfaches Datenmodell in Betracht gezogen werden. Der Thread, der LPUSH ausführt, muss andere Threads bedienen, die LPOP ausführen.
Was ich wirklich erwarte, ist tatsächlich „langsames Operations-Threading“. In Redis6 oder Redis7 wird eine „Schlüsselebenensperre“ bereitgestellt, damit Threads die volle Kontrolle über den Schlüssel erlangen können, um langsame Operationen zu bewältigen.
Siehe: http://antirez.com/news/126
12. IO-Multiplexing wird oft in Redis-Threads erwähnt.
Dies ist eine Art IO-Modell, das klassische Reactor-Entwurfsmuster, manchmal auch als asynchrones Blocking-IO bezeichnet. 
Mehrkanal bezieht sich auf mehrere Socket-Verbindungen, und Wiederverwendung bezieht sich auf die Wiederverwendung eines Threads. Es gibt drei Hauptmultiplextechnologien: Select, Poll und Epoll. epoll ist die neueste und beste verfügbare Multiplexing-Technologie. Durch die Verwendung der Mehrkanal-E/A-Multiplexing-Technologie kann ein einzelner Thread mehrere Verbindungsanforderungen effizient verarbeiten (wodurch der Zeitaufwand für Netzwerk-E/A minimiert wird), und Redis verarbeitet Daten im Speicher sehr schnell (In-Memory-Vorgänge werden hier kein Problem darstellen). ). Leistungsengpass), die beiden oben genannten Punkte tragen hauptsächlich zum hohen Durchsatz von Redis bei.
13. Kennst du Redis’ Easter Egg LOLWUT?
Das ist tatsächlich seit Redis 5.0 verfügbar, aber verzeihen Sie mir, dass ich es einfach weiß. Der Autor beschreibt diese Funktion als „LOLWUT: ein Kunstwerk innerhalb eines Datenbankbefehls“, „ein Kunstwerk innerhalb eines Datenbankbefehls“. Man kann es „Sentiment“ nennen, oder man kann es „Easter Egg“ nennen. Ich werde nicht verraten, was es genau ist. Freunde, die nicht wissen, wie es bei mir ist, können auf http://antirez.com/news/123 verweisen. Es wird bei jeder Ausführung zufällig generiert.
Weitere Kenntnisse zum Thema Programmierung finden Sie unter: Einführung in die Programmierung! !
Das obige ist der detaillierte Inhalt vonWas sind die neuen Funktionen in Redis6.0? Werfen wir einen Blick darauf!. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!