Das Teilen hochfrequenter Redis-Interviewfragen wird Ihnen dabei helfen, Kernwissenspunkte zu meistern!

In diesem Artikel werden einige hochfrequente Redis-Interviewfragen zusammengestellt und mit Ihnen geteilt. Er führt Sie durch die Kernwissenspunkte von Redis, einschließlich Datenstruktur, Speichermodell, E / A-Modell, persistenter RDB usw. Ich hoffe, er wird Ihnen hilfreich sein !

Warum ist Redis so schnell?

Viele Leute wissen nur, dass es sich um eine K/V-NoSQl-In-Memory-Datenbank mit Single-Thread handelt ... Dies liegt daran, dass sie Redis nicht vollständig verstehen und nicht mehr Fragen stellen können.

Diese Frage ist ein grundlegendes Verständnis. Wir können sie aus den zugrunde liegenden Datenstrukturen verschiedener Datentypen in Redis implementieren, vollständig basierend auf Speicher, IO-Multiplexing-Netzwerkmodell, Thread-Modell, progressivem Rehash ...

Wie schnell ist es?

Wir können zunächst darüber sprechen, wie schnell es ist. Laut offiziellen Angaben kann Redis‘ QPS etwa 100.000 (Anfragen pro Sekunde) erreichen. Interessierte können sich auf das offizielle Benchmark-Programm „Wie schnell ist Redis?“ beziehen. 》, Adresse: redis.io/topics/benc…

Die horizontale Achse ist die Anzahl der Verbindungen und die vertikale Achse ist QPS.

Dieses Bild spiegelt eine Größenordnung wider und gibt dem Interviewer das Gefühl, dass Sie die offiziellen Dokumente gelesen haben und sehr streng sind.

Speicherbasiert implementiert

Redis ist eine speicherbasierte Datenbank, die im Vergleich zu Festplattendatenbanken die Geschwindigkeit von Festplatten übertrifft.

Sowohl Lese- als auch Schreibvorgänge werden im Speicher ausgeführt. Vergleichen wir die Unterschiede zwischen Speichervorgängen und Festplattenvorgängen.

Festplattenaufruf

Speicherbetrieb

Der Speicher wird direkt von der CPU gesteuert, dem in der CPU integrierten Speichercontroller, sodass der Speicher direkt mit der CPU verbunden ist und die optimale Bandbreite genießt zur Kommunikation mit der CPU.

Abschließend wird ein Bild verwendet, um die verschiedenen Verzögerungen des Systems zu quantifizieren (ein Teil der Daten stammt von Brendan Gregg).

Effiziente Datenstruktur

Als ich MySQL lernte, wusste ich, dass die B+-Baumdaten Struktur wurde verwendet, um die Abrufgeschwindigkeit zu verbessern. Daher sollte die hohe Geschwindigkeit von Redis auch mit der Datenstruktur zusammenhängen.

Redis hat insgesamt 5 Datentypen, String、List、Hash、Set、SortedSet.

Verschiedene Datentypen werden durch eine oder mehrere Datenstrukturen unten unterstützt, um eine schnellere Geschwindigkeit zu erreichen.

Die Botschaft von Bruder Ma: Wir können die Vorteile der zugrunde liegenden Datenstruktur jedes Datentyps separat erklären. Viele Menschen kennen nur den Datentyp, und das Erklären der zugrunde liegenden Datenstruktur kann die Augen der Menschen zum Leuchten bringen.

SDS Einfacher dynamischer String-Vorteil

• In SDS speichert len ​​die Länge dieser Zeichenfolge, und O(1)-Zeitkomplexität wird zum Abfragen der Zeichenfolgenlängeninformationen verwendet.

• Speicherplatz-Vorabzuweisung: Nachdem SDS geändert wurde, weist das Programm nicht nur den für SDS erforderlichen Speicherplatz zu, sondern weist auch zusätzlichen ungenutzten Speicherplatz zu.

• Lazy Space Release: Beim Verkürzen des SDS beansprucht das Programm den überschüssigen Speicherplatz nicht zurück, sondern verwendet das freie Feld, um die Anzahl der Bytes aufzuzeichnen und diese nicht freizugeben, wenn später ein Anhängevorgang erforderlich ist. Verwenden Sie es direkt. Der ungenutzte Speicherplatz verringert die Speicherzuweisung.

zipList Compressed List

Compressed List ist eine der zugrunde liegenden Implementierungen der drei Datentypen List, Hash und Sorted Set.

Wenn eine Liste nur eine kleine Datenmenge enthält und jedes Listenelement entweder ein kleiner ganzzahliger Wert oder eine relativ kurze Zeichenfolge ist, verwendet Redis eine komprimierte Liste als zugrunde liegende Implementierung des Listenschlüssels.

So ist der Speicher kompakt und spart Speicherplatz.

Quicklist

Nachfolgende Versionen haben die Listendatenstruktur geändert und Quicklist anstelle von Ziplist und Linkedlist verwendet.

Quicklist ist eine Mischung aus Ziplist und Linkedlist. Es unterteilt Linkedlist in Segmente und verwendet Ziplist zur kompakten Speicherung. Mehrere Ziplists werden mithilfe bidirektionaler Zeiger miteinander verbunden.

skipList Skip List

Die Sortierfunktion des sortierten Satztyps wird durch die Datenstruktur „Skip List“ implementiert.

Die Sprungliste ist eine geordnete Datenstruktur, die in jedem Knoten mehrere Zeiger auf andere Knoten verwaltet, um den Zweck eines schnellen Zugriffs auf Knoten zu erreichen.

Die Sprungliste fügt mehrstufige Indizes auf der Grundlage der verknüpften Liste hinzu. Durch mehrere Sprünge in der Indexposition können die Daten schnell positioniert werden, wie in der folgenden Abbildung dargestellt:

Integer-Array (intset)

Wenn ein Satz nur ganzzahlige Elemente enthält und die Anzahl der Elemente in diesem Satz gering ist, verwendet Redis einen ganzzahligen Satz als zugrunde liegende Implementierung des Satzschlüssels, um Speicher zu sparen.

Single-Threaded-Modell

Meldung von Bruder Ma: Wir müssen beachten, dass sich der Single-Thread von Redis auf das Netzwerk-IO von Redis (Netzwerk-IO verwendet Multithreading nach Version 6.x) und den Schlüsselwert bezieht Das Lesen und Schreiben von Paaranweisungen wird von einem Thread ausgeführt. Redis-Persistenz, Cluster-Datensynchronisierung, asynchrones Löschen usw. werden alle von anderen Threads ausgeführt.

Sagen Sie nicht, dass Redis nur einen Thread hat.

Einzelner Thread bezieht sich auf die Ausführung von Redis-Schlüssel-Wert-Paar-Lese- und Schreibanweisungen in einem einzelnen Thread.

Lassen Sie uns zunächst über die offizielle Antwort sprechen, die den Leuten das Gefühl gibt, streng genug zu sein, anstatt nur einige Blogs auf der Grundlage dessen zu rezitieren, was andere sagen.

Offizielle Antwort: Da Redis ein speicherbasierter Vorgang ist, ist die CPU nicht der Engpass von Redis. Der Engpass von Redis liegt höchstwahrscheinlich in der Größe des Maschinenspeichers oder der Netzwerkbandbreite. Da Single-Threading einfach zu implementieren ist und die CPU nicht zum Engpass wird, ist es logisch, eine Single-Thread-Lösung zu übernehmen. Ursprüngliche Adresse: redis.io/topics/faq.

Warum nicht die Multithread-Ausführung nutzen, um die CPU voll auszunutzen?

Bevor jede Aufgabe ausgeführt wird, muss die CPU wissen, wo die Aufgabe geladen und ausgeführt wird. Das heißt, das System benötigt vorab Hilfe beim Einrichten der CPU-Register und des Programmzählers, was als CPU-Kontext bezeichnet wird.

Wenn wir den Kontext wechseln, müssen wir eine Reihe von Arbeiten erledigen, was ein sehr ressourcenintensiver Vorgang ist.

Die Einführung einer Multithread-Entwicklung erfordert die Verwendung von Synchronisierungsprimitiven, um das gleichzeitige Lesen und Schreiben gemeinsam genutzter Ressourcen zu schützen, was die Komplexität des Codes und die Schwierigkeit beim Debuggen erhöht.

Was sind die Vorteile von Single Thread?

Es entsteht kein Leistungsverbrauch durch die Thread-Erstellung.

1. Vermeiden Sie den CPU-Verbrauch durch Kontextwechsel, und es entsteht kein Overhead durch Multi-Thread-Wechsel Bei Sperren, toten Sperren usw. müssen verschiedene Sperrprobleme nicht berücksichtigt werden.
2. Der Code ist klarer und die Verarbeitungslogik ist einfach.
3. I/O-Multiplexing-Modell
4. Redis verwendet I/O-Multiplexing-Technologie, um Verbindungen gleichzeitig zu verarbeiten. Mit epoll + einem einfachen, von mir selbst implementierten Event-Framework.

Lesen, Schreiben, Schließen und Verbinden in Epoll werden alle in Ereignisse umgewandelt und dann die Multiplexing-Funktion von Epoll verwendet, um keine Zeit mit E/A zu verschwenden.

Der Redis-Thread blockiert nicht bei einem bestimmten Überwachungs- oder verbundenen Socket, das heißt, er blockiert nicht bei der Verarbeitung einer bestimmten Clientanforderung. Aus diesem Grund kann Redis gleichzeitig eine Verbindung zu mehreren Clients herstellen und Anfragen verarbeiten, wodurch die Parallelität verbessert wird.

Redis globales Hash-Wörterbuch

Redis als Ganzes ist eine Hash-Tabelle zum Speichern aller Schlüssel-Wert-Paare, unabhängig von den 5 Datentypen. Eine Hash-Tabelle ist im Wesentlichen ein Array und jedes Element wird als Hash-Bucket bezeichnet. Unabhängig vom Datentyp enthält der Eintrag in jedem Bucket einen Zeiger auf den tatsächlichen spezifischen Wert.

Die zeitliche Komplexität der Hash-Tabelle beträgt O(1). Sie müssen nur den Hash-Wert jedes Schlüssels berechnen, um den Speicherort des entsprechenden Hash-Buckets zu ermitteln, um die entsprechenden Daten zu finden Dies ist auch einer der Gründe, warum Redis schnell ist.

Redis verwendet Objekte (redisObject), um Schlüsselwerte in der Datenbank darzustellen. Wenn wir in Redis ein Schlüsselwertpaar erstellen, werden mindestens zwei Objekte erstellt other ist der Schlüssel. Ein Wertobjekt von Wertepaaren.

Das heißt, jeder Eintrag speichert ein redisObject-Objekt eines „Schlüssel-Wert-Paares“ und die entsprechenden Daten werden über den Zeiger von redisObject gefunden.

typedef struct redisObject{
    //类型
   unsigned type:4;
   //编码
   unsigned encoding:4;
   //指向底层数据结构的指针
   void *ptr;
    //...
 }robj;

Was tun, wenn ein Hash-Konflikt vorliegt?

Redis löst Konflikte durch

verkettetes Hashing

:

das heißt, Elemente im selben Bucket werden mithilfe einer verknüpften Liste gespeichert

. Wenn die verknüpfte Liste jedoch zu lang ist, kann sich die Suchleistung verschlechtern. Aus Gründen der Geschwindigkeit verwendet Redis daher zwei globale Hash-Tabellen. Wird für Rehash-Vorgänge verwendet, um die Anzahl vorhandener Hash-Buckets zu erhöhen und Hash-Konflikte zu reduzieren. Beginnen Sie standardmäßig mit der Verwendung von „Hash-Tabelle 1“, um Schlüssel-Wert-Paar-Daten zu speichern, und „Hash-Tabelle 2“ hat derzeit keinen zugewiesenen Speicherplatz. Wenn immer mehr Daten den Rehash-Vorgang auslösen, werden die folgenden Vorgänge ausgeführt:

1. Weisen Sie mehr Platz für „Hash-Tabelle 2“ zu.
2. Machen Sie die Daten von „Hash-Tabelle 1“ neu zu und kopieren Sie sie in „Hash-Tabelle 2“.
3. Geben Sie den Platz von Hash-Tabelle 1 frei.

Es ist zu beachten, dass der Vorgang der Neuzuordnung der Daten in Hash-Tabelle 1 zu Hash-Tabelle 2 kein einmaliger Vorgang ist. Dies führt dazu, dass Redis blockiert wird und keine Dienste bereitstellen kann.

Stattdessen wird progressive Rehash verwendet. Jedes Mal, wenn eine Client-Anfrage verarbeitet wird, beginnt sie mit dem ersten Index in „Hash-Tabelle 1“ und kopiert alle Daten an dieser Stelle in „Hash-Tabelle 2“, wodurch sie verteilt wird den Rehash in mehrere Anfragen aufteilen, um zeitaufwändiges Blockieren zu vermeiden.

Wie erreicht Redis Persistenz? Wie kann man Daten nach einem Absturz wiederherstellen?

Die Datenpersistenz von Redis nutzt die „RDB-Daten-Snapshot“-Methode, um eine schnelle Wiederherstellung nach Ausfallzeiten zu erreichen. Das zu häufige Ausführen vollständiger Daten-Snapshots führt jedoch zu zwei schwerwiegenden Leistungseinbußen:

1. Generieren Sie häufig RDB-Dateien und schreiben Sie sie auf die Festplatte, was zu einer übermäßigen Belastung der Festplatte führt. Es sieht so aus, als ob die vorherige RDB noch nicht ausgeführt wurde, und die nächste beginnt erneut zu generieren und gerät in eine Endlosschleife.
2. Das Verlassen des bgsave-Unterprozesses blockiert den Hauptthread. Je größer der Speicher des Hauptthreads ist, desto länger ist die Blockierungszeit.

Daher hat Redis auch das AOF-Post-Write-Protokoll entworfen, um die Anweisungen zum Ändern des Speichers aufzuzeichnen.

Interviewer: Was ist ein RDB-Speicher-Snapshot?

Während Redis den Befehl „Schreiben“ ausführt, ändern sich die Speicherdaten weiterhin. Der sogenannte Speicher-Snapshot bezieht sich auf die Statusdaten der Daten im Redis-Speicher zu einem bestimmten Zeitpunkt.

Es ist, als ob die Zeit in einem bestimmten Moment eingefroren ist. Wenn wir Fotos machen, können wir den Moment in einem bestimmten Moment vollständig durch Fotos festhalten.

Redis ähnelt diesem, es erfasst die Daten zu einem bestimmten Zeitpunkt in Form einer Datei und schreibt sie auf die Festplatte. Diese Snapshot-Datei heißt RDB-Datei. RDB ist die Abkürzung für Redis DataBase.

Lesen Sie bei der Datenwiederherstellung die RDB-Datei direkt in den Speicher, um die Wiederherstellung abzuschließen.

Interviewer: Kann Redis während der RDB-Generierung gleichzeitig Schreibanforderungen verarbeiten?

Ja, Redis nutzt die Multiprozess-Copy-on-Write-Technologie COW (Copy On Write) des Betriebssystems, um Snapshot-Persistenz zu erreichen und Datenkonsistenz sicherzustellen. Redis ruft die Glibc-Funktion fork auf, um während der Persistenz einen untergeordneten Prozess zu generieren. Die Snapshot-Persistenz wird vollständig vom untergeordneten Prozess verwaltet und der übergeordnete Prozess verarbeitet weiterhin Clientanforderungen.

Wenn der Hauptthread den Schreibbefehl ausführt, um die Daten zu ändern, wird eine Kopie der Daten erstellt und der untergeordnete Prozess bgsave liest die kopierten Daten und schreibt sie in die RDB-Datei. fork产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。

当主线程执行写指令修改数据的时候，这个数据就会复制一份副本， bgsave 子进程读取这个副本数据写到 RDB 文件。

这既保证了快照的完整性，也允许主线程同时对数据进行修改，避免了对正常业务的影响。

面试官：那 AOF 又是什么？

AOF 日志记录了自 Redis 实例创建以来所有的修改性指令序列，那么就可以通过对一个空的 Redis 实例顺序执行所有的指令，也就是「重放」，来恢复 Redis 当前实例的内存数据结构的状态。

Redis 提供的 AOF 配置项appendfsync写回策略直接决定 AOF 持久化功能的效率和安全性。

• always：同步写回，写指令执行完毕立马将 aof_buf缓冲区中的内容刷写到 AOF 文件。
• everysec：每秒写回，写指令执行完，日志只会写到 AOF 文件缓冲区，每隔一秒就把缓冲区内容同步到磁盘。
• no： 操作系统控制，写执行执行完毕，把日志写到 AOF 文件内存缓冲区，由操作系统决定何时刷写到磁盘。

没有两全其美的策略，我们需要在性能和可靠性上做一个取舍。

面试官：既然 RDB 有两个性能问题，那为何不用 AOF 即可。

AOF 写前日志，记录的是每个「写」指令操作。不会像 RDB 全量快照导致性能损耗，但是执行速度没有 RDB 快，同时日志文件过大也会造成性能问题。

所以，Redis 设计了一个杀手锏「AOF 重写机制」，Redis 提供了 bgrewriteaof

Dies stellt nicht nur die Integrität des Snapshots sicher, sondern ermöglicht es dem Hauptthread auch, die Daten gleichzeitig zu ändern, wodurch jegliche Auswirkungen auf das normale Geschäft vermieden werden.

Interviewer: Was ist AOF?

Das AOF-Protokoll zeichnet alle geänderten Befehlssequenzen seit der Erstellung der Redis-Instanz auf. Anschließend können Sie die Speicherdaten der aktuellen Redis-Instanz wiederherstellen, indem Sie alle Anweisungen nacheinander auf einer leeren Redis-Instanz ausführen, also „wiederholen“. Der Zustand der Struktur. 🎜🎜Die von Redis bereitgestellte Rückschreibstrategie für das AOF-Konfigurationselement appendfsync bestimmt direkt die Effizienz und Sicherheit der AOF-Persistenzfunktion. 🎜

🎜🎜immer🎜: Synchrones Zurückschreiben, der Inhalt im aof_buf-Puffer wird sofort nach Ausführung des Schreibbefehls in die AOF-Datei geleert. 🎜🎜🎜jede Sekunde🎜: Jede Sekunde zurückschreiben Nachdem der Schreibbefehl ausgeführt wurde, wird das Protokoll nur in den AOF-Dateipuffer geschrieben und der Pufferinhalt wird jede Sekunde mit der Festplatte synchronisiert. 🎜🎜🎜Nein: 🎜 Nach Abschluss der Schreibausführung wird das Protokoll vom Betriebssystem gesteuert in den AOF-Dateispeicherpuffer geschrieben und das Betriebssystem entscheidet, wann es auf die Festplatte geleert wird. 🎜

🎜Es gibt keine Strategie, die das Beste aus beiden Welten vereint, wir müssen einen Kompromiss zwischen Leistung und Zuverlässigkeit eingehen. 🎜🎜🎜Interviewer: Da RDB zwei Leistungsprobleme hat, warum nicht AOF verwenden? 🎜🎜🎜Das AOF-Vorschreibprotokoll zeichnet jede „Schreib“-Befehlsoperation auf. Es verursacht keinen Leistungsverlust wie der vollständige RDB-Snapshot, aber die Ausführungsgeschwindigkeit ist nicht so schnell wie bei RDB. Gleichzeitig führen zu große Protokolldateien auch zu Leistungsproblemen. 🎜🎜Daher hat Redis einen Killer-„AOF-Rewrite-Mechanismus“ entwickelt. Redis stellt den Befehl bgrewriteaof zur Verfügung, um das AOF-Protokoll zu verschlanken. 🎜🎜Das Prinzip besteht darin, einen Unterprozess zu öffnen, um den Speicher zu durchqueren und ihn in eine Reihe von Redis-Betriebsanweisungen umzuwandeln, die in eine neue AOF-Protokolldatei serialisiert werden. Nach Abschluss der Serialisierung wird das inkrementelle AOF-Protokoll, das während des Vorgangs erstellt wurde, an die neue AOF-Protokolldatei angehängt. Nach Abschluss des Anhängens wird die alte AOF-Protokolldatei sofort ersetzt und die Schlankheitsarbeit ist abgeschlossen. 🎜🎜🎜🎜🎜🎜Interviewer: Wie erreicht man unter Berücksichtigung der Performance möglichst wenig Datenverlust? 🎜

Beim Neustart von Redis verwenden wir selten RDB, um den Speicherstatus wiederherzustellen, da eine große Datenmenge verloren geht. Normalerweise verwenden wir die AOF-Protokollwiedergabe, aber die Leistung der AOF-Protokollwiedergabe ist viel langsamer als die von RDB. Wenn die Redis-Instanz also groß ist, dauert der Start lange.

Redis 4.0 bietet eine neue Persistenzoption zur Lösung dieses Problems – Hybridpersistenz. Speichern Sie den Inhalt der RDB-Datei zusammen mit der inkrementellen AOF-Protokolldatei. Das AOF-Protokoll ist hier nicht mehr das vollständige Protokoll, sondern das inkrementelle AOF-Protokoll, das im Zeitraum vom Beginn der Persistenz bis zum Ende der Persistenz auftritt. Normalerweise ist dieser Teil des AOF-Protokolls sehr klein. Also

Wenn Redis neu gestartet wird, können Sie zuerst den RDB-Inhalt laden und dann das inkrementelle AOF-Protokoll erneut abspielen, wodurch die vorherige AOF-Volldateiwiedergabe vollständig ersetzt werden kann und die Effizienz des Neustarts erheblich verbessert wird

. Datensynchronisierung der Redis-Master-Slave-Architektur

Redis bietet einen Master-Slave-Modus, der durch Master-Slave-Replikation eine redundante Kopie der Daten auf andere Redis-Server kopiert.

Interviewer: Wie kann die Datenkonsistenz zwischen Master und Slave sichergestellt werden?

Um die Konsistenz der Replikatdaten sicherzustellen, verwendet die Master-Slave-Architektur eine Lese-/Schreib-Trennmethode.

Lesevorgang: Sowohl die Master- als auch die Slave-Bibliothek können ausgeführt werden.

• Schreibvorgang: Die Master-Bibliothek führt ihn zuerst aus und synchronisiert dann den Schreibvorgang mit der Slave-Bibliothek. Slave-Replikation hat andere Funktionen Was?

Fehlerbehebung: Wenn der Master-Knoten ausgefallen ist, können andere Knoten weiterhin Dienste bereitstellen.

Lastausgleich: Der Master-Knoten stellt Schreibdienste bereit, und der Slave-Knoten stellt Lesedienste bereit, um den Druck zu teilen.

Der Eckpfeiler von Hochverfügbarkeit: Sentinel- und Cluster-Implementierung Die Grundlage ist der Eckpfeiler der Hochverfügbarkeit.

Interviewer: Wie wird die Master-Slave-Replikation implementiert?
2. Die Synchronisierung ist in drei Situationen unterteilt:
3. Vollständige Replikation der Master-Slave-Datenbank zum ersten Mal;

Synchronisierung während des normalen Betriebs der Master-Slave-Datenbank;

Netzwerktrennung und Synchronisierung der Master-Slave-Datenbank.

Interviewer: Wie erreicht man die erste Synchronisation?
2. Der erste Kopiervorgang der Master-Slave-Bibliothek kann grob in drei Phasen unterteilt werden: die Phase des Verbindungsaufbaus (d. h. die Vorbereitungsphase), die Phase der Synchronisierung von Daten von der Master-Bibliothek zur Slave-Bibliothek und die Phase des Sendens neuer Schreibbefehle während der Synchronisierung an die Slave-Bibliothek Bibliothek, dass die Synchronisierung stattfinden wird. Nachdem die Master-Bibliothek die Antwort bestätigt hat, beginnt die Synchronisierung zwischen der Master- und der Slave-Bibliothek.
3. Die Master-Bibliothek synchronisiert Daten mit der Slave-Bibliothek: Der Master führt den Befehl bgsave aus, um eine RDB-Datei zu generieren und sendet die Datei an die Slave-Bibliothek. Gleichzeitig wird die

Hauptbibliothek

geöffnet ein Replikationspuffer für jeden Slave, um den Slave aufzuzeichnen. Der Aufbau der RDB-Datei beginnt mit allen empfangenen Schreibbefehlen. Speichern Sie die RDB aus der Bibliothek, löschen Sie die Datenbank und laden Sie dann die RDB-Daten in den Speicher.

Senden Sie den nach der RDB empfangenen neuen Schreibbefehl an die Slave-Bibliothek: Der Schreibvorgang nach dem Generieren der RDB-Datei wird derzeit nicht in der RDB-Datei aufgezeichnet. Um die Konsistenz der Master-Slave-Bibliotheksdaten sicherzustellen, ist die Master-Bibliothek wird im Speicher sein. Verwenden Sie einen Replikationspuffer, um alle Schreibvorgänge aufzuzeichnen, nachdem die RDB-Datei generiert wurde. Und senden Sie die Daten an den Slave.

Interviewer: Was soll ich tun, wenn das Netzwerk zwischen der Master- und der Slave-Datenbank getrennt ist? Muss ich das gesamte Volume nach dem Trennen der Verbindung erneut kopieren?

Wenn es vor Redis 2.8 bei der Master-Slave-Bibliothek während der Befehlsweitergabe zu einer Netzwerkunterbrechung kam, führte die Slave-Bibliothek erneut eine vollständige Kopie mit der Master-Bibliothek durch, was sehr teuer war.

Ab Redis 2.8 wird die Master-Slave-Bibliothek nach dem Trennen der Netzwerkverbindung weiterhin mithilfe der inkrementellen Replikation synchronisiert.
1. Inkrementelle Replikation: Wird für die Replikation nach Netzwerkunterbrechungen und anderen Situationen verwendet. Nur die vom Masterknoten während der Unterbrechung ausgeführten Schreibbefehle werden an die Slave-Knoten gesendet, was effizienter ist als die vollständige Replikation.
2. bgsave命令生成 RDB 文件，并将文件发送给从库，同时主库为每一个 slave 开辟一块 replication buffer 缓冲区记录从生成 RDB 文件开始收到的所有写命令。从库保存 RDB 并清空数据库再加载 RDB 数据到内存中。
3. 发送 RDB 之后接收到的新写命令到从库：在生成 RDB 文件之后的写操作并没有记录到刚刚的 RDB 文件中，为了保证主从库数据的一致性，所以主库会在内存中使用一个叫 replication buffer 记录 RDB 文件生成后的所有写操作。并将里面的数据发送到 slave。

面试官：主从库间的网络断了咋办？断开后要重新全量复制么？

在 Redis 2.8 之前，如果主从库在命令传播时出现了网络闪断，那么，从库就会和主库重新进行一次全量复制，开销非常大。

从 Redis 2.8 开始，网络断了之后，主从库会采用增量复制的方式继续同步。

增量复制：用于网络中断等情况后的复制，只将中断期间主节点执行的写命令发送给从节点，与全量复制相比更加高效。

断开重连增量复制的实现奥秘就是 repl_backlog_buffer 缓冲区，不管在什么时候 master 都会将写指令操作记录在 repl_backlog_buffer 中，因为内存有限， repl_backlog_buffer 是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖前面的内容。

master 使用 master_repl_offset记录自己写到的位置偏移量，slave 则使用 slave_repl_offset记录已经读取到的偏移量。

当主从断开重连后，slave 会先发送 psync 命令给 master，同时将自己的 runID，slave_repl_offset发送给 master。

master 只需要把 master_repl_offset与 slave_repl_offsetDas Geheimnis des Trennens und Wiederverbindens der inkrementellen Replikation ist der Puffer repl_backlog_buffer. Egal wann, der Master zeichnet den Schreibbefehlsvorgang im repl_backlog_buffer auf, da der Speicher begrenzt ist. repl_backlog_buffer ist ein kreisförmiges Array fester Länge.

Wenn der Array-Inhalt voll ist, wird der vorherige Inhalt von Anfang an überschrieben. 🎜🎜Master verwendet master_repl_offset, um den Positionsoffset aufzuzeichnen, den er schreibt, und Slave verwendet slave_repl_offset, um den Offset aufzuzeichnen, den er gelesen hat. 🎜🎜🎜🎜Sei der Master Nach dem Trennen und erneuten Verbinden sendet der Slave zunächst den psync-Befehl an den Master und sendet gleichzeitig seine runID und slave_repl_offset an den Master. 🎜🎜Der Master muss lediglich die Befehle zwischen master_repl_offset und slave_repl_offset mit der Slave-Bibliothek synchronisieren. 🎜

Der inkrementelle Kopierausführungsprozess ist wie folgt:

Interviewer: Wie können Daten nach Abschluss der vollständigen Synchronisierung im normalen Betrieb synchronisiert werden?

Wenn die Master-Slave-Bibliothek die vollständige Replikation abschließt, wird eine Netzwerkverbindung zwischen ihnen aufrechterhalten. Die Master-Bibliothek synchronisiert die nacheinander empfangenen Befehlsvorgänge mit der Slave-Bibliothek über diese Verbindung Bei der Befehlsweitergabe besteht der Zweck der Verwendung langer Verbindungen darin, den durch häufigen Verbindungsaufbau verursachten Overhead zu vermeiden.

Fragen und Antworten zum Sentinel-Prinzip

Interviewer: Klar, ich weiß so viel, kennen Sie das Sentinel-Cluster-Prinzip?

Sentinel ist ein Betriebsmodus von Redis. Er konzentriert sich auf die Überwachung des Betriebsstatus von Redis-Instanzen (Masterknoten, Slave-Knoten) und kann über eine Reihe von Mechanismen eine Master-Auswahl und Master-Slave-Auswahl erreichen, wenn der Master-Knoten ausfällt . Schalten Sie um und implementieren Sie ein Failover, um die Verfügbarkeit des gesamten Redis-Systems sicherzustellen. Sein Architekturdiagramm sieht wie folgt aus:

Redis Sentinel verfügt über die folgenden Funktionen:

Überwachung: Kontinuierliche Überwachung, ob Master und Slave im erwarteten Arbeitsstatus sind.
• Master-Datenbank automatisch wechseln
: Wenn der Master ausfällt, startet Sentinel den automatischen Fehlerwiederherstellungsprozess: Wählen Sie einen der Slaves als neuen Master aus.
• Benachrichtigung
: Lassen Sie den Slave „replicaof“ ausführen, um sich mit dem neuen Master zu synchronisieren, und benachrichtigen Sie den Client, um eine Verbindung mit dem neuen Master herzustellen.
Interviewer: Woher kennen sich die Wächter?

Der Sentinel stellt die Kommunikation mit dem Master her und verwendet den vom Master bereitgestellten Veröffentlichungs-/Abonnementmechanismus, um seine eigenen Informationen zu veröffentlichen, z. B. Größe und Gewicht, ob Sie Single sind, IP, Port ...

Der Master verfügt über einen dedizierten __sentinel__:hello Kanäle werden zum Veröffentlichen und Abonnieren von Nachrichten zwischen Sentinels verwendet.

Dies ist wie die WeChat-Gruppe __sentinel__:hello. Sentinel verwendet die vom Master eingerichtete WeChat-Gruppe, um seine eigenen Nachrichten zu veröffentlichen und gleichzeitig auf die von anderen Sentinels veröffentlichten Nachrichten zu achten.

__sentinel__:hello 的专用通道，用于哨兵之间发布和订阅消息。这就好比是 __sentinel__:hello 微信群，哨兵利用 master 建立的微信群发布自己的消息，同时关注其他哨兵发布的消息。

面试官：哨兵之间虽然建立连接了，但是还需要和 slave 建立连接，不然没法监控他们呀，如何知道 slave 并监控他们的？

关键还是利用 master 来实现，哨兵向 master 发送 INFO 命令， master 掌门自然是知道自己门下所有的 salve 小弟的。所以 master 接收到命令后，便将 slave 列表告诉哨兵。

哨兵根据 master 响应的 slave 名单信息与每一个 salve 建立连接，并且根据这个连接持续监控哨兵。

Cluster 集群连环炮

面试官：除了哨兵以外，还有其他的高可用手段么？

有 Cluster 集群实现高可用，哨兵集群监控的 Redis 集群是主从架构，无法很想拓展。使用 Redis Cluster 集群，主要解决了大数据量存储导致的各种慢问题，同时也便于横向拓展。

在面向百万、千万级别的用户规模时，横向扩展的 Redis 切片集群会是一个非常好的选择。

面试官：什么是 Cluster 集群？

Redis 集群是一种分布式数据库方案，集群通过分片（sharding）来进行数据管理（「分治思想」的一种实践），并提供复制和故障转移功能。

将数据划分为 16384 的 slots，每个节点负责一部分槽位。槽位的信息存储于每个节点中。

它是去中心化的，如图所示，该集群有三个 Redis 节点组成，每个节点负责整个集群的一部分数据，每个节点负责的数据多少可能不一样。

三个节点相互连接组成一个对等的集群，它们之间通过 GossipInterviewer: Obwohl die Wächter eine Verbindung untereinander hergestellt haben, müssen sie noch eine Verbindung zum Slave herstellen. Andernfalls können sie den Slave nicht überwachen.

Der Schlüssel liegt darin, den Meister zu nutzen, um dies zu erreichen. Der Wächter sendet den Befehl INFO an den Meister. Der Meister kennt natürlich alle Salbenjungen unter ihm. Nachdem der Master den Befehl erhalten hat, teilt er dem Sentinel die Slave-Liste mit.

Der Sentinel stellt eine Verbindung mit jedem Slave basierend auf den vom Master beantworteten Slave-Listeninformationen her und überwacht den Sentinel kontinuierlich auf Grundlage dieser Verbindung.

1. 

Cluster Cluster Serial Cannon

3. Interviewer: Gibt es neben Sentrys noch andere Hochverfügbarkeitsmethoden?

Es gibt einen Cluster-Cluster, um eine hohe Verfügbarkeit zu erreichen. Der vom Sentinel-Cluster überwachte Redis-Cluster verfügt über eine Master-Slave-Architektur und kann nicht einfach erweitert werden.

Die Verwendung des Redis-Cluster-Clusters löst hauptsächlich verschiedene Langsamkeitsprobleme, die durch großen Datenspeicher verursacht werden, und erleichtert auch die horizontale Erweiterung.

Wenn es Millionen oder Dutzende Millionen Benutzer gibt, sind horizontal skalierbare Redis-Slicing-Cluster eine sehr gute Wahl.

🎜🎜Interviewer: Was ist ein Cluster? 🎜🎜🎜Redis-Cluster ist eine verteilte Datenbanklösung. Der Cluster verwaltet Daten durch Sharding (eine Praxis des „Teilens und Herrschens“) und bietet Replikations- und Failover-Funktionen. 🎜🎜Teilen Sie die Daten in 16384 Slots auf, und jeder Knoten ist für einen Teil der Slots verantwortlich. Slot-Informationen werden in jedem Knoten gespeichert. 🎜🎜Es ist dezentralisiert, der Cluster besteht aus drei Redis-Knoten. Jeder Knoten ist für einen Teil der Daten des gesamten Clusters verantwortlich. 🎜🎜🎜🎜三Knoten sind miteinander verbunden, um einen Peer-to-Peer-Cluster zu bilden. Sie tauschen Clusterinformationen untereinander über das Gossip-Protokoll aus. Schließlich speichert jeder Knoten die Slot-Zuweisung anderer Knoten. 🎜🎜🎜Interviewer: Wie werden Hash-Slots Redis-Instanzen zugeordnet? 🎜🎜🎜🎜Verwenden Sie entsprechend dem Schlüssel des Schlüssel-Wert-Paares den CRC16-Algorithmus, um einen 16-Bit-Wert zu berechnen Hash-Slot, der dem Schlüssel entspricht. 🎜🎜Suchen Sie die entsprechende Instanz anhand der Slot-Informationen. 🎜🎜🎜Die Zuordnungsbeziehung zwischen Schlüssel-Wert-Paardaten, Hash-Slots und Redis-Instanzen ist wie folgt: 🎜🎜🎜🎜🎜🎜Interviewer: Wie implementiert Cluster ein Failover? 🎜

Redis-Clusterknoten verwenden das Gossip-Protokoll, um ihren Status und Änderungen in ihrem Wissen über den gesamten Cluster zu übertragen. Wenn ein Knoten beispielsweise feststellt, dass ein bestimmter Knoten verloren geht (PFail), sendet er diese Informationen an den gesamten Cluster, und andere Knoten können diese Informationen zum Verbindungsverlust ebenfalls empfangen.

Wenn ein Knoten erhält, dass die Anzahl der Verbindungsabbrüche von einem bestimmten Knoten (PFail Count) den Großteil des Clusters erreicht hat, kann er den Knoten als offline (Fail) markieren und ihn dann an den gesamten Cluster senden. Dadurch werden auch andere Knoten gezwungen, die Tatsache zu empfangen, dass der Knoten offline gegangen ist, und sofort einen Master-Slave-Schalter am verlorenen Knoten durchzuführen.

Interviewer: Wie ermittelt der Client, auf welche Instanz die abgerufenen Daten verteilt werden?

Die Redis-Instanz sendet ihre Hash-Slot-Informationen über das Gossip-Protokoll an andere Instanzen im Cluster und realisiert so die Verbreitung von Hash-Slot-Zuteilungsinformationen.

Auf diese Weise verfügt jede Instanz im Cluster über Zuordnungsbeziehungsinformationen zwischen allen Hash-Slots und Instanzen.

Wenn der Client eine Verbindung zu einer Instanz herstellt, antwortet die Instanz dem Client mit der Zuordnungsbeziehung zwischen dem Hash-Slot und der Instanz, und der Client speichert die Zuordnungsinformationen zwischen dem Hash-Slot und der Instanz lokal zwischen.

Wenn der Client eine Anfrage stellt, berechnet er den dem Schlüssel entsprechenden Hash-Slot, lokalisiert die Instanz, in der sich die Daten befinden, anhand der lokal zwischengespeicherten Hash-Slot-Instanzzuordnungsinformationen und sendet dann die Anfrage an die entsprechende Instanz.

Interviewer: Was ist der Redis-Umleitungsmechanismus?

Die Zuordnungsbeziehung zwischen Hash-Slots und Instanzen hat sich aufgrund neuer Instanzen oder einer Lastausgleichs-Umverteilung geändert. Der Client sendet die Anfrage an die Instanz. Die Redis-Instanz teilt dem Client die Anfrage mit zu anderen Instanzen.

Redis informiert den Client über MOVED-Fehler und ASK-Fehler.

MOVED

MOVED Fehler (Lastausgleich, Daten wurden auf andere Instanzen migriert): Wenn der Client eine Schlüssel-Wert-Paar-Operationsanforderung an eine Instanz sendet und der Slot, in dem sich der Schlüssel befindet, nicht in seiner eigenen Verantwortung liegt , gibt die Instanz einen MOVED-Fehler zurück und leitet sie an den Knoten weiter, der derzeit für den Slot verantwortlich ist.

Gleichzeitig aktualisiert der Client auch den lokalen Cache, um die entsprechende Beziehung zwischen dem Slot und der Redis-Instanz korrekt zu aktualisieren.

ASK

Wenn sich in einem bestimmten Slot viele Daten befinden, wird ein Teil davon auf die neue Instanz migriert und ein Teil davon nicht.

Wenn der angeforderte Schlüssel auf dem aktuellen Knoten gefunden wird, führen Sie den Befehl direkt aus, andernfalls ist eine ASK-Fehlerantwort erforderlich.

Wenn die Slot-Migration nicht abgeschlossen ist und der Slot, auf den auf den Schlüssel zugegriffen werden muss, von Instanz 1 zu Instanz 2 migriert wird (wenn sich der Schlüssel nicht mehr in Instanz 1 befindet), gibt Instanz 1 eine ASK-Fehlermeldung an zurück der Client: Client-Anfrage Der Hash-Slot, in dem sich der Schlüssel befindet, wird auf Instanz 2 migriert. Sie senden zunächst einen ASKING-Befehl an Instanz 2 und dann den Operationsbefehl .

Wenn der Client beispielsweise die Suche nach Steckplatz 16330 mit Schlüssel = „Offizielles Konto: Codebyte“ auf Instanz 172.17.18.1 anfordert, führt Knoten 1 den Befehl direkt aus, wenn er gefunden werden kann, andernfalls antwortet er mit einem ASK-Fehler Nachricht und weisen Sie den Client an, umzuleiten. Der Zielknoten, der migriert wird, ist 172.17.18.2.

Hinweis: ASK-Fehleranweisung aktualisiert nicht die vom Client zwischengespeicherten Hash-Slot-Zuordnungsinformationen.

Zusammenfassung

In diesem Artikel geht es hauptsächlich um den Kerninhalt von Redis, einschließlich Datenstruktur, Speichermodell, IO-Modell, persistenter RDB und AOF, Master-Slave-Replikationsprinzip, Sentinel-Prinzip und Cluster-Prinzip.

Originaladresse: https://juejin.cn/post/6976257378094481444

Autor: Code Brother Byte

Weitere Programmierkenntnisse finden Sie unter: Programmiervideo! !

Das obige ist der detaillierte Inhalt vonDas Teilen hochfrequenter Redis-Interviewfragen wird Ihnen dabei helfen, Kernwissenspunkte zu meistern!. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!