4)Einstellen
Häufig verwendete Befehle: sadd/spop/smembers/sunion usw.;
-
Anwendungsszenarien: Die von Redis bereitgestellten externen Funktionen ähneln denen von list. Die Besonderheit besteht darin, dass set automatisch Duplikate entfernen muss nützliches Tool. Eine gute Auswahl, und Set bietet eine wichtige Schnittstelle, um festzustellen, ob sich ein Mitglied in einer Set-Sammlung befindet, die die Liste nicht bereitstellen kann
Implementierungsmethode: Die interne Implementierung von set ist eine HashMap, deren Wert immer null ist. Tatsächlich wird sie durch die Berechnung des Hash schnell sortiert. Aus diesem Grund kann set eine Möglichkeit bieten, festzustellen, ob sich ein Mitglied in der Menge befindet.
-
5) Sortiertes Set
-
Häufig verwendete Befehle: zadd/zrange/zrem/zcard usw.;
-
Anwendungsszenarien: Das Verwendungsszenario des sortierten Satzes von Redis ähnelt dem des Satzes. Der Unterschied besteht darin, dass der Satz nicht automatisch sortiert wird, während der sortierte Satz Mitglieder sortieren kann, indem er einen zusätzlichen Prioritätsparameter (Score) durch den Benutzer bereitstellt und einfügt Reihenfolge. Das heißt, automatische Sortierung. 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 SkipList, um die Speicherung und Reihenfolge der Daten von Mitgliedern zu Bewertungen sicherzustellen, während die Sprungliste alle in HashMap gespeicherten Ergebnisse speichert Durch die Verwendung der Sprungtabellenstruktur kann eine relativ hohe Sucheffizienz erzielt werden, und die Implementierung ist relativ einfach.
-
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 der Speicher der Maschine selbst alle Schlüssel aufnehmen können, schließlich werden diese Daten nicht ausgetauscht. 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 Redis jedoch in einer großen Website-Anwendung angewendet wird, kann dies offensichtlich nicht der Situation einer großen Parallelität gerecht werden. Redis führt uns also aus, um die Größe des E/A-Thread-Pools festzulegen und gleichzeitige Vorgänge für Leseanforderungen auszuführen, 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 mit bestimmten Längen zu unterteilen, um Schlüsselwertdatensätze mit entsprechenden Längen 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 unterteilt Blöcke derselben Größe in Gruppen von Slab-Klassen. Unter diesen ist Chunk die kleinste Einheit, die zum Speichern von Schlüsselwertdaten verwendet wird. 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 die am besten geeignete Slab-Klasse basierend auf der Größe der empfangenen Daten aus und fragt dann die von Memcached gespeicherte Liste der freien Blöcke in der Slab-Klasse ab, um eine Slab-Klasse zu finden, die dies kann zur Speicherung der Daten verwendet werden. Wenn ein Datenbankeintrag abläuft oder verworfen wird, kann der vom Datensatz belegte Chunk recycelt und erneut zur Liste der freien Einträge 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. Da jedem Chunk eine bestimmte Länge an Speicherplatz zugewiesen ist, können Daten variabler Länge diesen Speicherplatz 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 Speicherverwaltung von Redis wird hauptsächlich über die beiden Dateien Detaillierte Erklärung des Unterschieds zwischen Redis und Memcached.h und Detaillierte Erklärung des Unterschieds zwischen Redis und Memcached.c im Quellcode implementiert. Um die Speicherverwaltung zu erleichtern, speichert Redis die Größe dieses Speichers im Kopf des Speicherblocks, nachdem ein Teil des Speichers zugewiesen wurde. Wie in der Abbildung gezeigt, ist real_ptr der Zeiger, den Redis nach dem Aufruf von malloc zurückgibt. 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 beträgt ZMALLOC_MAX_ALLOC_STAT. Jedes Element des Arrays stellt die Anzahl der vom aktuellen Programm zugewiesenen Speicherblöcke dar, und die Größe des Speicherblocks ist der Index des Elements. Im Quellcode lautet dieses Array Detaillierte Erklärung des Unterschieds zwischen Redis und Memcached_allocations. Detaillierte Erklärung des Unterschieds zwischen Redis und Memcached_allocations[16] stellt die Anzahl der zugewiesenen Speicherblöcke mit einer Länge von 16 Bytes dar. In Detaillierte Erklärung des Unterschieds zwischen Redis und Memcached.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-Snapshots und AOF-Protokolle. Memcached unterstützt keine Datenpersistenzvorgänge.
1) RDB-Snapshot
Redis unterstützt einen Persistenzmechanismus, der einen Snapshot der aktuellen Daten in einer Datendatei, also einem RDB-Snapshot, speichert. Doch wie erzeugt eine kontinuierlich schreibende Datenbank Snapshots? Redis verwendet den Copy-on-Write-Mechanismus des fork-Befehls. Beim Generieren eines Snapshots wird der aktuelle Prozess in einen untergeordneten Prozess gespalten, und dann werden alle Daten im untergeordneten Prozess zirkuliert und die Daten werden in eine RDB-Datei geschrieben. Wir können den Zeitpunkt der RDB-Snapshot-Generierung über den Speicherbefehl von Redis konfigurieren. Beispielsweise können wir den Snapshot so konfigurieren, dass er nach 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 verwendet sie dann atomar Der Systemaufruf benennt die temporäre Datei in eine RDB-Datei um, sodass die Redis RDB-Datei immer verfügbar ist, wenn zu irgendeinem Zeitpunkt ein Fehler auftritt. Gleichzeitig ist die RDB-Datei von Redis auch Teil der internen Implementierung der Redis-Master-Slave-Synchronisation. 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 „Nur Append-Datei“, bei der es sich um eine durch Anhängen geschriebene Protokolldatei handelt. 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. Der Generierungsprozess ähnelt RDB. Außerdem wird ein Prozess gegabelt, die Daten werden direkt durchlaufen und eine neue temporäre AOF-Datei geschrieben. Während des Schreibvorgangs einer neuen Datei werden alle Schreibvorgangsprotokolle weiterhin in die ursprüngliche alte AOF-Datei geschrieben und auch im Speicherpuffer aufgezeichnet. Wenn der Redundanzvorgang abgeschlossen ist, werden alle Protokolle im Puffer auf einmal in die temporäre Datei geschrieben. Rufen Sie dann den Befehl zum atomaren Umbenennen auf, 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.
appendfsync no Wenn appendfsync auf no gesetzt ist, ruft Redis fsync nicht aktiv auf, um den AOF-Protokollinhalt mit der Festplatte zu synchronisieren, sodass dies alles vollständig vom Debuggen des Betriebssystems abhängt. Bei den meisten Linux-Betriebssystemen wird fsync alle 30 Sekunden ausgeführt, um die Daten im Puffer 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. Da der Dateideskriptor zu diesem Zeitpunkt während fsync blockiert wird, wird der aktuelle Schreibvorgang blockiert. Die Schlussfolgerung ist also, dass Redis in den meisten Fällen fsync jede Sekunde durchführt. 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 bei jedem Schreibvorgang einmal aufgerufen. Da fsync zu diesem Zeitpunkt jedes Mal ausgeführt wird, wird dies natürlich auch beeinträchtigt.
Für allgemeine Geschäftsanforderungen wird die Verwendung von RDB für die Persistenz empfohlen. Der Grund dafür ist, dass der Overhead von RDB viel geringer ist als der von AOF-Protokollen. Für Anwendungen, die keinen Datenverlust tolerieren, wird die Verwendung von AOF-Protokollen empfohlen.
4. Unterschiede im Clustermanagement
Memcached ist ein Datenpufferungssystem mit vollem Speicher. Obwohl Redis die Datenpersistenz unterstützt, ist der volle Speicher der Kern 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. Wenn die zu verarbeitende Datenmenge die physische Speichergröße einer einzelnen Maschine übersteigt, muss ein verteilter Cluster erstellt werden, um die Speicherkapazitäten zu erweitern.
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 jedoch Daten abfragt, muss er auch den Knoten berechnen, auf dem sich die Abfragedaten befinden, und dann direkt eine Abfrageanforderung an den Knoten senden, um die Daten abzurufen.
Im Vergleich zu Memcached, das den Client nur 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 des Redis-Clusters, 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.
Um die Datenverfügbarkeit bei Single Point of Failure sicherzustellen, führt Redis Cluster einen Master-Knoten und einen Slave-Knoten ein. Im Redis-Cluster verfügt jeder Master-Knoten aus Redundanzgründen über zwei entsprechende Slave-Knoten. Auf diese Weise führt die Ausfallzeit zweier beliebiger Knoten im gesamten Cluster nicht zu einer Nichtverfügbarkeit der Daten. Wenn der Master-Knoten beendet wird, wählt der Cluster automatisch einen Slave-Knoten aus, der zum neuen Master-Knoten wird.
