Was sind die Unterschiede zwischen Redis und Memcached?

redis ist eine Datenbank, aber im Gegensatz zu herkömmlichen Datenbanken werden Redis-Daten im Speicher gespeichert, sodass die Lese- und Schreibgeschwindigkeit sehr hoch ist und Redis daher häufig die Cache-Richtung verwendet . memcached ist ein leistungsstarker verteilter Speicher-Cache-Server . Der allgemeine Verwendungszweck besteht darin, die Geschwindigkeit und Skalierbarkeit dynamischer Webanwendungen zu erhöhen, indem Datenbankabfrageergebnisse zwischengespeichert und die Anzahl der Datenbankzugriffe reduziert werden.

Maßgeblicher Vergleich

Der Autor von Redis, Salvatore Sanfilippo, hat einmal diese beiden speicherbasierten Datenspeichersysteme verglichen: # 🎜🎜#

1. Redis unterstützt serverseitige Datenoperationen: Im Vergleich zu Memcached verfügt Redis über mehr Datenstrukturen und unterstützt umfangreichere Datenoperationen. Normalerweise müssen Sie in Memcached die Daten abrufen Client, ähnliche Änderungen vorzunehmen und sie dann zurückzusetzen. Dadurch erhöht sich die Anzahl der Netzwerk-IOs und das Datenvolumen erheblich. Im Vergleich zu allgemeinem GET/SET sind diese komplexen Vorgänge in Redis normalerweise genauso effizient. Wenn Sie also den Cache benötigen, um komplexere Strukturen und Vorgänge zu unterstützen, ist Redis eine gute Wahl.

2. Vergleich der Speichernutzungseffizienz: Wenn Sie einfachen Schlüsselwertspeicher verwenden, hat Memcached eine höhere Speicherauslastung, und wenn Redis eine Hash-Struktur für den Schlüsselwertspeicher verwendet, Aufgrund der kombinierten Komprimierung ist die Speicherauslastung höher als bei Memcached.

3. Leistungsvergleich: Da Redis nur einen einzelnen Kern verwendet und Memcached mehrere Kerne verwenden kann, weist Redis im Durchschnitt eine höhere Leistung als Memcached auf, wenn auf jedem Kern kleine Daten gespeichert werden . Bei Daten von mehr als 100.000 ist die Leistung von Memcached höher als die von Redis. Obwohl Redis kürzlich für die Leistung beim Speichern großer Datenmengen optimiert wurde, ist es Memcached immer noch etwas unterlegen.

Der konkrete Grund, warum die obige Schlussfolgerung erscheint, sind die folgenden gesammelten Informationen:

1 Verschiedene Datentypen werden unterstützt

# 🎜🎜# Im Gegensatz zu Memcached, das nur Datensätze mit einfachen Schlüssel-Wert-Strukturen unterstützt, unterstützt Redis viel umfangreichere Datentypen. Zu den gebräuchlichsten Datentypen gehören String, Hash, List, Set und Sorted Set. Redis verwendet redisObject-Objekte, um alle Schlüssel und Werte darzustellen. Die Hauptinformationen von redisObject sind in der Abbildung dargestellt:

type stellt den spezifischen Datentyp eines Wertobjekts dar, und die Codierung ist die Art und Weise, wie verschiedene Datentypen in redis gespeichert werden. Beispiel: type=string Stellt den Wertspeicher als gewöhnlichen String dar, kann die entsprechende Codierung raw oder int sein. Dies bedeutet, dass der eigentliche Redis den String entsprechend der numerischen Klasse speichert und darstellt selbst kann durch numerische Werte dargestellt werden, zum Beispiel: eine Zeichenfolge wie „123″ „456“. Nur wenn die virtuelle Speicherfunktion von Redis aktiviert ist, weist das VM-Feld tatsächlich Speicher zu. Diese Funktion ist standardmäßig deaktiviert.

# 🎜🎜#1) String

Allgemeine Befehle: set/get/decr/incr/mget usw.; #🎜🎜 #Anwendungsszenarien: String ist der am häufigsten verwendete Datentyp. Der normale Schlüssel-/Wertspeicher kann in diese Kategorie eingeordnet werden.

Implementierungsmethode: String wird standardmäßig intern in Redis als String gespeichert wird von redisObject referenziert. Es wird zur Berechnung in einen numerischen Typ konvertiert. Zu diesem Zeitpunkt ist das Codierungsfeld von redisObject usw. Anwendungsszenario: Wir möchten die Daten eines Benutzerinformationsobjekts speichern, einschließlich Benutzer-ID, Benutzername, Alter und Geburtstag. Über die Benutzer-ID hoffen wir, den Namen oder das Alter des Benutzers zu erhalten.

Implementierungsmethode : Der Hash von Redis speichert den Wert tatsächlich intern als HashMap und stellt eine Schnittstelle für den direkten Zugriff auf die Map-Mitglieder bereit. Wie in der Abbildung gezeigt, ist der Schlüssel die Benutzer-ID und der Wert ist der Schlüssel dieser Map Der Attributname des Mitglieds und der Wert sind der Attributwert. Auf diese Weise können die Daten direkt über den Schlüssel der internen Karte geändert werden (der Schlüssel der internen Karte wird in Redis als Feld bezeichnet). Über Schlüssel (Benutzer-ID) + Feld (Attributbezeichnung) können die entsprechenden Attributdaten verwaltet werden. Derzeit gibt es zwei Möglichkeiten, HashMap zu implementieren: Wenn in HashMap relativ wenige Mitglieder vorhanden sind, verwendet Redis ein eindimensionales Array, um es kompakt zu speichern Um Speicher zu sparen, wird zu diesem Zeitpunkt die Codierung des entsprechenden Werts nicht verwendet. Wenn die Anzahl der Mitglieder zunimmt, wird sie automatisch in eine echte HashMap umgewandelt. die Kodierung ist ht. 🎜#3) Liste

Allgemeine Befehle: lpush/rpush/lpop/rpop/lrange usw.;

Anwendungsszenarien: Dort Es gibt viele Anwendungsszenarien für die Redis-Liste. Sie ist beispielsweise eine der wichtigsten Datenstrukturen von Redis. Beispielsweise können die Listenstruktur von Twitter verwendet werden. Implementierungsmethode: Die Redis-Liste wird als bidirektionale verknüpfte Liste implementiert, d. Verwenden Sie auch diese Datenstruktur.

4) Set

Allgemeine Befehle: sadd/spop/smembers/sunion usw.;

Anwendungsszenarien: Die von Redis bereitgestellten externen Funktionen ähneln denen von list. Das Besondere ist, dass set automatisch Duplikate entfernen muss Eine gute Auswahl, und set bietet eine wichtige Schnittstelle zur Beurteilung, ob sich ein bestimmtes Mitglied in einer set-Sammlung befindet. Diese Liste kann nicht bereitgestellt werden.

Implementierungsmethode: Die interne Implementierung von set ist eine HashMap, deren Wert tatsächlich immer null ist besteht darin, Duplikate durch Hash-Berechnung schnell auszusortieren, weshalb set eine Möglichkeit bieten kann, festzustellen, ob sich ein Mitglied in der Menge befindet.

5) Sortierter Satz

Gemeinsame Befehle: zadd/zrange/zrem/zcard usw.;

Anwendungsszenarien: Die Verwendungsszenarien des sortierten Satzes von Redis ähneln denen von Satz, der Unterschied besteht darin, dass der Satz nicht automatisch geordnet wird , während sorted set can Die Mitglieder werden durch Bereitstellung eines zusätzlichen Prioritätsparameters (Score) durch den Benutzer sortiert, und die Mitglieder werden durch Einfügen sortiert, dh automatisch sortiert. Wenn Sie eine geordnete und nicht duplizierte Set-Liste benötigen, können Sie eine sortierte Set-Datenstruktur wählen. Beispielsweise kann die öffentliche Timeline von Twitter mit der Veröffentlichungszeit als Partitur gespeichert werden, sodass sie beim Abrufen automatisch nach Zeit sortiert wird.

Implementierungsmethode: Der sortierte Redis-Satz verwendet intern HashMap und eine Sprungliste (SkipList), um die Speicherung und Reihenfolge von Daten sicherzustellen, während die Sprungliste alle Mitglieder speichert, sortiert nach der gespeicherten Punktzahl HashMap kann mithilfe der Sprungtabellenstruktur eine höhere Sucheffizienz erzielen und ist relativ einfach zu implementieren.

2. Verschiedene Speicherverwaltungsmechanismen

In Redis werden nicht alle Daten immer im Speicher gespeichert. Dies ist der größte Unterschied im Vergleich zu Memcached. Wenn der physische Speicher erschöpft ist, kann Redis einige Werte, die längere Zeit nicht verwendet wurden, auf die Festplatte übertragen. Redis speichert nur alle Schlüsselinformationen zwischen, wenn Redis feststellt, dass die Speichernutzung einen bestimmten Schwellenwert überschreitet. Redis berechnet, welche Schlüssel dem erforderlichen Wert entsprechen Scheibe. Anschließend werden die diesen Schlüsseln entsprechenden Werte auf der Festplatte gespeichert und im Speicher gelöscht. Mit dieser Funktion kann Redis Daten verwalten, die die Speichergröße seiner Maschine selbst überschreiten. Natürlich muss die Speicherkapazität der Maschine ausreichen, um alle wichtigen Daten zu speichern, da diese Daten nicht ausgetauscht werden. Wenn Redis gleichzeitig die Daten im Speicher auf die Festplatte auslagert, teilen sich der Haupt-Thread, der den Dienst bereitstellt, und der Unter-Thread, der den Auslagerungsvorgang ausführt, diesen Teil des Speichers, sodass die Daten vorhanden sein müssen Ausgetauscht wird aktualisiert. Redis blockiert den Vorgang, bis der Sub-Thread geändert wird. Änderungen können erst nach Abschluss des Auslagerungsvorgangs vorgenommen werden. Wenn sich beim Lesen von Daten aus Redis der dem Leseschlüssel entsprechende Wert nicht im Speicher befindet, muss Redis die entsprechenden Daten aus der Auslagerungsdatei laden und sie dann an den Anforderer zurückgeben. Hier liegt ein I/O-Thread-Pool-Problem vor. Standardmäßig blockiert Redis, das heißt, es reagiert erst, wenn alle Auslagerungsdateien geladen sind. Diese Strategie eignet sich besser, wenn die Anzahl der Clients gering ist und Batch-Vorgänge ausgeführt werden. Wenn Sie Redis in einer großen Website-Anwendung mit hoher Parallelität verwenden möchten, reicht dies offensichtlich nicht aus, um die Anforderungen zu erfüllen. Daher legen wir beim Ausführen von Redis die Größe des E/A-Thread-Pools fest und führen gleichzeitige Vorgänge für Leseanforderungen aus, die entsprechende Daten aus der Auslagerungsdatei laden müssen, um die Blockierungszeit zu reduzieren.

Bei speicherbasierten Datenbanksystemen wie Redis und Memcached ist die Effizienz der Speicherverwaltung ein Schlüsselfaktor für die Systemleistung. Die malloc/free-Funktion in der traditionellen C-Sprache ist die am häufigsten verwendete Methode zum Zuweisen und Freigeben von Speicher, aber diese Methode weist große Mängel auf: Erstens können nicht übereinstimmende malloc und free für Entwickler leicht zu Speicherverlusten führen eine große Menge an Speicherfragmenten, die nicht recycelt und wiederverwendet werden können, wodurch die Speicherauslastung schließlich verringert wird, da bei einem Systemaufruf der Systemaufwand viel größer ist als bei gewöhnlichen Funktionsaufrufen. Um die Effizienz der Speicherverwaltung zu verbessern, verwenden effiziente Speicherverwaltungslösungen daher Malloc/Free-Aufrufe nicht direkt. Sowohl Redis als auch Memcached verwenden ihre eigenen Speicherverwaltungsmechanismen, ihre Implementierungsmethoden sind jedoch sehr unterschiedlich. Die Speicherverwaltungsmechanismen der beiden werden im Folgenden separat vorgestellt.

Memcached verwendet standardmäßig den Slab Allocation-Mechanismus zur Speicherverwaltung. Die Hauptidee besteht darin, den zugewiesenen Speicher entsprechend der vorgegebenen Größe in Blöcke bestimmter Längen aufzuteilen, um Schlüsselwertdatensätze entsprechender Länge zu speichern und das Problem der Speicherfragmentierung vollständig zu lösen. Der Slab Allocation-Mechanismus dient nur zum Speichern externer Daten. Dies bedeutet, dass alle Schlüsselwertdaten im Slab Allocation-System gespeichert werden, während andere Speicheranforderungen für Memcached über gewöhnliches Malloc/Free beantragt werden, da die Anzahl dieser Anforderungen und Die Häufigkeit bestimmt, dass sie die Leistung des gesamten Systems nicht beeinträchtigen. Das Prinzip der Slab Allocation ist recht einfach. Wie in der Abbildung gezeigt, beantragt es zunächst einen großen Speicherblock vom Betriebssystem, unterteilt ihn in Blöcke unterschiedlicher Größe und teilt Blöcke derselben Größe in Gruppen von Slab-Klassen auf. Chunk wird als kleinste Einheit zum Speichern von Schlüsselwertdaten verwendet. Die Größe jeder Slab-Klasse kann durch Angabe des Wachstumsfaktors beim Start von Memcached gesteuert werden. Nehmen Sie an, dass der Wert des Wachstumsfaktors in der Abbildung 1,25 beträgt. Wenn die Größe der ersten Gruppe von Chunks 88 Byte beträgt, beträgt die Größe der zweiten Gruppe von Chunks 112 Byte und so weiter.

Wenn Memcached die vom Client gesendeten Daten empfängt, wählt es zunächst basierend auf der Größe der empfangenen Daten die am besten geeignete Slab-Klasse aus und findet dann eine verfügbare Slab-Klasse, indem es die Liste der freien Blöcke in der von ihm gespeicherten Slab-Klasse abfragt Zwischengespeicherter Chunk zum Speichern von Daten. Wenn eine Datenbank abläuft oder verworfen wird, kann der Chunk, in dem sie sich befindet, recycelt und erneut zur Liste der freien Datenbanken hinzugefügt werden.

Aus dem obigen Prozess können wir ersehen, dass das Speicherverwaltungssystem von Memcached hocheffizient ist und keine Speicherfragmentierung verursacht, sein größter Nachteil jedoch darin besteht, dass es zu einer Platzverschwendung führt. Daten variabler Länge können die spezifische Länge des jedem Chunk zugewiesenen Speicherplatzes nicht vollständig nutzen. Wie in der Abbildung dargestellt, werden 100 Byte Daten in einem 128-Byte-Block zwischengespeichert und die restlichen 28 Byte werden verschwendet.

Die Art und Weise, wie Redis die Speicherverwaltung implementiert, umfasst hauptsächlich die beiden Dateien zmalloc.h und zmalloc.c im Quellcode. Um die Speicherverwaltung zu erleichtern, speichert Redis die Größe dieses Speichers im Kopf des Speicherblocks, nachdem ein Teil des Speichers zugewiesen wurde. real_ptr zeigt auf den Speicherblock, der zurückgegeben wird, nachdem Redis malloc aufgerufen hat. Redis speichert die Größe des Speicherblocks im Header. Die von size belegte Speichergröße ist die Länge des Typs size_t und gibt dann ret_ptr zurück. Wenn Speicher freigegeben werden muss, wird ret_ptr an den Speichermanager übergeben. Über ret_ptr kann das Programm einfach den Wert von real_ptr berechnen und dann real_ptr an free übergeben, um den Speicher freizugeben.

Redis zeichnet alle Speicherzuweisungen auf, indem es ein Array definiert. Die Länge dieses Arrays ist ZMALLOC_MAX_ALLOC_STAT. Jede Zahl stellt die Anzahl der derzeit vom Programm zugewiesenen Speicherblöcke dar, und die Größe jedes Speicherblocks entspricht dem Array-Index, in dem er sich befindet. Im Quellcode lautet dieses Array zmalloc_allocations. zmalloc_allocations[16] stellt die Anzahl der zugewiesenen Speicherblöcke mit einer Länge von 16 Bytes dar. In zmalloc.c gibt es eine statische Variable used_memory, um die Gesamtgröße des aktuell zugewiesenen Speichers aufzuzeichnen. Daher verwendet Redis im Allgemeinen das gepackte Mallc/Free, was viel einfacher ist als die Speicherverwaltungsmethode von Memcached.

3. Unterstützung der Datenpersistenz

Obwohl Redis ein speicherbasiertes Speichersystem ist, unterstützt es selbst die Persistenz von Speicherdaten und bietet zwei Hauptpersistenzstrategien: RDB-Snapshot und AOF-Protokoll. Memcached unterstützt keine Datenpersistenzvorgänge.

1) RDB-Snapshot

RDB-Snapshot ist ein Persistenzmechanismus von Redis, der es Benutzern ermöglicht, den aktuellen Daten-Snapshot als Datendatei zu speichern. Redis nutzt den Copy-on-Write-Mechanismus des fork-Befehls, um einen Snapshot zu generieren, der kontinuierlich in die Datenbank geschrieben wird. Verwenden Sie beim Generieren eines Snapshots die Fork-Operation, um einen untergeordneten Prozess zu erstellen, durchlaufen Sie alle Daten im untergeordneten Prozess und schreiben Sie sie in die RDB-Datei. Wir können den Zeitpunkt der RDB-Snapshot-Generierung über den Speicherbefehl von Redis konfigurieren. Wir können den Snapshot beispielsweise so konfigurieren, dass er in 10 Minuten generiert wird, oder wir können ihn so konfigurieren, dass nach 1.000 Schreibvorgängen ein Snapshot generiert wird, oder wir können mehrere Regeln zusammen implementieren. Die Definition dieser Regeln befindet sich in der Redis-Konfigurationsdatei. Sie können die Regeln auch festlegen, während Redis über den Redis-Befehl CONFIG SET ausgeführt wird, ohne Redis neu zu starten.

Die RDB-Datei von Redis wird nicht beschädigt, da der Schreibvorgang in einem neuen Prozess ausgeführt wird. Wenn eine neue RDB-Datei generiert wird, schreibt der von Redis generierte Unterprozess die Daten zunächst in eine temporäre Datei und benennt sie dann um Die temporäre Datei kann über den Systemaufruf „Atomic Rename“ in eine RDB-Datei umgewandelt werden, sodass die Redis-RDB-Datei immer verfügbar ist, wenn zu irgendeinem Zeitpunkt ein Fehler auftritt. Bei der internen Implementierung der Redis-Master-Slave-Synchronisation spielen auch RDB-Dateien eine wichtige Rolle. RDB hat seine Mängel, das heißt, sobald ein Problem mit der Datenbank auftritt, sind die in unserer RDB-Datei gespeicherten Daten nicht ganz neu. Alle Daten von der letzten RDB-Dateigenerierung bis zum Herunterfahren von Redis gehen verloren. In manchen Betrieben ist dies tolerierbar.

2) AOF-Protokoll

Der vollständige Name des AOF-Protokolls lautet „Append Write File“, eine Protokolldatei, die kontinuierlich angehängt und geschrieben wird. Im Gegensatz zum Binlog allgemeiner Datenbanken handelt es sich bei AOF-Dateien um identifizierbaren Klartext, und ihr Inhalt besteht aus Redis-Standardbefehlen nacheinander. Nur Befehle, die eine Änderung der Daten bewirken, werden an die AOF-Datei angehängt. Jeder Befehl zum Ändern von Daten generiert ein Protokoll und die AOF-Datei wird immer größer, sodass Redis eine weitere Funktion namens AOF-Rewrite bereitstellt. Seine Funktion besteht darin, eine AOF-Datei neu zu generieren. In der neuen AOF-Datei gibt es nur eine Operation für einen Datensatz, im Gegensatz zu einer alten Datei, in der möglicherweise mehrere Operationen für denselben Wert aufgezeichnet werden. AOF wird auf ähnliche Weise wie RDB generiert, indem ein Prozess geforkt wird, die Daten direkt durchlaufen und in eine neue temporäre AOF-Datei geschrieben werden. Während Daten in die neue Datei geschrieben werden, werden alle Schreibvorgangsprotokolle weiterhin in der ursprünglichen AOF-Datei aufgezeichnet und gleichzeitig im Speicherpuffer aufgezeichnet. Nach Abschluss wichtiger Vorgänge werden alle Pufferprotokolle stapelweise in temporäre Dateien geschrieben. Als nächstes verwenden Sie den atomaren Befehl „rename“, um die alte AOF-Datei durch die neue AOF-Datei zu ersetzen.

AOF ist ein Dateischreibvorgang. Sein Zweck besteht darin, das Vorgangsprotokoll auf die Festplatte zu schreiben, sodass auch der oben erwähnte Schreibvorgang auftritt. Verwenden Sie nach dem Aufruf von write auf AOF in Redis die Option appendfsync, um die Zeit zu steuern, die zum Aufrufen von fsync zum Schreiben auf die Festplatte benötigt wird. Die Sicherheitsstärke der folgenden drei Einstellungen von appendfsync wird allmählich stärker. Kein Debugging. In den meisten Linux-Betriebssystemen wird alle 30 Sekunden ein fsync-Vorgang ausgeführt, um die Pufferdaten auf die Festplatte zu schreiben.

• appendfsync everysec Wenn appendfsync auf everysec eingestellt ist, führt Redis standardmäßig jede Sekunde einen fsync-Aufruf durch, um die Daten im Puffer auf die Festplatte zu schreiben. Aber wenn dieser fsync-Aufruf länger als 1 Sekunde dauert. Redis wird die Strategie übernehmen, fsync zu verzögern und eine weitere Sekunde zu warten. Das heißt, fsync wird nach zwei Sekunden ausgeführt, unabhängig davon, wie lange die Ausführung dauert. Der aktuelle Schreibvorgang wird blockiert, da der Dateideskriptor blockiert wird, während der fsync-Vorgang ausgeführt wird. Daher führt Redis unter normalen Umständen jede Sekunde einen Fsync-Vorgang durch. Im schlimmsten Fall findet alle zwei Sekunden ein fsync-Vorgang statt. Dieser Vorgang wird in den meisten Datenbanksystemen als Gruppenfestschreibung bezeichnet. Er kombiniert die Daten mehrerer Schreibvorgänge und schreibt das Protokoll auf einmal auf die Festplatte.

• appednfsync immer Wenn appendfsync auf immer eingestellt ist, wird fsync für jeden Schreibvorgang einmal aufgerufen. Da sind die Daten natürlich am sichersten fsync wird jedes Mal ausgeführt, sodass auch die Leistung beeinträchtigt wird.

• Für allgemeine Geschäftsanforderungen wird empfohlen, RDB für die Persistenz zu verwenden. Der Grund dafür ist, dass der Overhead von RDB viel geringer ist als der von AOF-Protokollen kann es nicht ertragen. Für Datenverlustanwendungen wird die Verwendung von AOF-Protokollen empfohlen.

4. Unterschiede in der Clusterverwaltung

Memcached ist ein Datenpufferungssystem mit vollem Speicher, aber der volle Speicher ist schließlich die Essenz seiner hohen Leistung. . Da es sich um ein speicherbasiertes Speichersystem handelt, ist die Größe des physischen Speichers der Maschine die maximale Datenmenge, die das System aufnehmen kann. Um die Speicherkapazitäten zu erweitern, muss ein verteilter Cluster eingerichtet werden, wenn die zu verarbeitende Datenmenge die physische Speichergrenze einer einzelnen Maschine überschreitet.

Memcached selbst unterstützt keine Verteilung, daher kann der verteilte Speicher von Memcached nur über verteilte Algorithmen wie konsistentes Hashing auf dem Client implementiert werden. Die folgende Abbildung zeigt die verteilte Speicherimplementierungsarchitektur von Memcached. Bevor der Client Daten an den Memcached-Cluster sendet, wird zunächst der Zielknoten der Daten über den integrierten verteilten Algorithmus berechnet und dann werden die Daten zur Speicherung direkt an den Knoten gesendet. Wenn der Client Daten abfragt, muss er zunächst den Knoten berechnen, auf dem sich die abzufragenden Daten befinden, und dann eine Abfrageanforderung an den Knoten senden, um die Daten abzurufen.

Im Vergleich zu Memcached, das nur den Client zum Implementieren verteilten Speichers verwenden kann, bevorzugt Redis den Aufbau verteilten Speichers auf der Serverseite. Die neueste Version von Redis unterstützt bereits verteilte Speicherfunktionen. Redis Cluster ist eine erweiterte Version von Redis, die die Verteilung implementiert und einzelne Fehlerpunkte zulässt. Es verfügt über keinen zentralen Knoten und ist linear skalierbar. Die folgende Abbildung zeigt die verteilte Speicherarchitektur von Redis Cluster, in der Knoten über das Binärprotokoll miteinander kommunizieren und zwischen Knoten und Clients über das ASCII-Protokoll kommunizieren. In Bezug auf die Datenplatzierungsstrategie unterteilt Redis Cluster das gesamte Schlüsselwertfeld in 4096 Hash-Slots, und jeder Knoten kann einen oder mehrere Hash-Slots speichern. Das heißt, die maximale Anzahl von Knoten, die derzeit von Redis Cluster unterstützt werden, beträgt 4096. Der von Redis Cluster verwendete verteilte Algorithmus ist ebenfalls sehr einfach: crc16(key) % HASH_SLOTS_NUMBER.

Redis Cluster führt Master-Knoten und Slave-Knoten ein, um sicherzustellen, dass Daten im Falle eines Single Point of Failure weiterhin verfügbar sind. Im Redis-Cluster verfügt jeder Master-Knoten aus Redundanzgründen über zwei entsprechende Slave-Knoten. Auf diese Weise führt der Ausfall von zwei beliebigen Knoten im gesamten Cluster nicht zu einer Nichtverfügbarkeit der Daten. Sobald der Master-Knoten offline geht, wählt der Cluster automatisch einen neuen Master-Knoten aus den Slave-Knoten aus.

Das obige ist der detaillierte Inhalt vonWas sind die Unterschiede zwischen Redis und Memcached?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!