In welchen Situationen blockiert Redis?

Befehlsblockierung

Die Verwendung ungeeigneter Befehle führt zur Clientblockierung:

• Tasten *: Alle Tastenoperationen abrufen; 🎜🎜#

Hgetall: Gibt die Summe aller Felder in der Hash-Tabelle zurück;
smembers: Gibt alle Mitglieder im Satz zurück ;# 🎜🎜#

• Die zeitliche Komplexität dieser Befehle beträgt O(n), und manchmal wird mit zunehmendem n auch die zeitliche Komplexität erhöht, was zu einer Blockierung des Clients führt .

SAVE-Blockierung

Jeder weiß, dass Redis beim Erstellen eines RDB-Snapshots die Systemfunktion fork() aufruft und einen untergeordneten Thread erstellt, um das Schreiben temporärer Dateien abzuschließen. Auslösebedingung ist das Speichern der Konfiguration in der Konfigurationsdatei.

Wenn unsere Konfiguration erreicht ist, wird der Befehl bgsave ausgelöst, um einen Snapshot zu erstellen. Diese Methode blockiert den Hauptthread nicht und die manuelle Ausführung des Speicherbefehls wird im Hauptthread ausgeführt, #🎜 🎜# Blockiere den

Hauptthread.

Synchronische PersistenzWenn Redis AOF-Protokolle direkt aufzeichnet, wenn eine große Anzahl von Schreibvorgängen vorhanden ist und für synchrone Persistenz konfiguriert ist

appendfsync always

Das Jede Datenänderung wird sofort auf der Festplatte aufgezeichnet. Da das Schreiben auf die Festplatte zeitaufwändig ist und eine schlechte Leistung aufweist, wird manchmal der Hauptthread blockiert.

AOF rewrite

fork erstellt einen Unterthread, um die Datei neu zu schreiben, wenn der Befehl BGREWRITEAOF ausgeführt wird Der Redis-Server verwaltet einen AOF-Rewrite-Puffer, der alle vom Server während der Erstellung einer neuen AOF-Datei durch den untergeordneten Thread ausgeführten Schreibbefehle aufzeichnet.

• Wenn der untergeordnete Thread die Arbeit zum Erstellen einer neuen AOF-Datei abschließt, hängt der Server den gesamten Inhalt im Umschreibepuffer an das Ende der neuen AOF-Datei an. Erstellen des neuen Datenbankstatus, der in der AOF-Datei gespeichert wird, stimmt mit dem vorhandenen Datenbankstatus überein. BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子线程创建新 AOF 文件期间，记录服务器执行的所有写命令。

• 当子线程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾，使得新的 AOF 文件保存的数据库状态与现有的数据库状态一致。

• 最后，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完成 AOF 文件重写操作。

阻塞就是出现在第2步的过程中，将缓冲区中新数据写到新文件的过程中会产生阻塞。

AOF 日志

AOF 的日志记录不像关系型数据库那样在执行命令之前记录日志（方便故障恢复），而是采用先执行命令后记录日志的方式。

原因就是 AOF 记录日志是不会对命令进行语法检查的，这样就能减少额外的检查开销，不会对当前命令的执行产生阻塞，但可能会给下一个操作带来阻塞风险。

这是因为 AOF 日志也是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了。

大 Key 问题

大 key 并不是指 key 的值很大，而是 key 对应的 value 很大。

大 key 造成的阻塞问题如下：

• 客户端超时阻塞：由于 Redis 执行命令是单线程处理，然后在操作大 key 时会比较耗时，那么就会阻塞 Redis，从客户端这一视角看，就是很久很久都没有响应。

• 引发网络阻塞：每次获取大 key 产生的网络流量较大，如果一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是灾难性的。

• 阻塞工作线程：如果使用 del 删除大 key 时，会阻塞工作线程，这样就没办法处理后续的命令。

查找大 key

当我们在使用 Redis 自带的 --bigkeys

Schließlich ersetzt der Server die alte AOF-Datei durch die neue AOF-Datei, um den Vorgang zum Umschreiben der AOF-Datei abzuschließen.

• Blockierung tritt im Prozess von Schritt 2 auf. Beim Schreiben neuer Daten im Puffer in eine neue Datei
Blockierung#🎜🎜 #.

• AOF-Protokoll

Die Protokollierung von AOF ähnelt nicht einer relationalen Datenbank, die Protokolle aufzeichnet, bevor Befehle ausgeführt werden (um die Fehlerbehebung zu erleichtern), sondern verwendet Befehle, die zuerst ausgeführt und dann protokolliert werden. Weg.
• Der Grund dafür ist, dass die AOF-Protokollierung keine Syntaxprüfung für Befehle durchführt, was den zusätzlichen Prüfaufwand reduzieren kann und die Ausführung des aktuellen Befehls nicht blockiert, aber möglicherweise zu Problemen bei der nächsten zu blockierenden Operation führt Risiken.

Dies liegt daran, dass das AOF-Protokoll auch im Hauptthread ausgeführt wird.
• Wenn der Schreibdruck auf die Festplatte beim Schreiben der Protokolldatei auf die Festplatte hoch ist, führt dies dazu Das Schreiben auf die Festplatte ist sehr langsam, was dazu führt, dass nachfolgende Vorgänge nicht ausgeführt werden können.
  Problem mit dem großen Schlüssel
Ein großer Schlüssel bedeutet nicht, dass der Wert des Schlüssels sehr groß ist, sondern dass der dem Schlüssel entsprechende Wert sehr groß ist.

Die durch große Schlüssel verursachten Blockierungsprobleme sind wie folgt:

Client-Timeout-Blockierung: Da der Redis-Ausführungsbefehl von einem einzelnen Thread verarbeitet wird , und dann ist der Vorgang groß. Die Verwendung des Schlüssels wird zeitaufwändiger und Redis wird blockiert. Aus Sicht des Clients wird es für längere Zeit keine Antwort geben. Verursacht Netzwerküberlastung: Jedes Mal, wenn Sie einen großen Schlüssel erhalten, ist der generierte Netzwerkverkehr groß. Wenn die Größe eines Schlüssels 1 MB beträgt und die Anzahl der Besuche pro Wenn die Sekunde 1.000 beträgt, generiert die Sekunde jedes Mal 1.000 MB Datenverkehr, was für Server mit gewöhnlichen Gigabit-Netzwerkkarten katastrophal ist.

Blockieren des Arbeitsthreads: Wenn Sie mit del einen großen Schlüssel löschen, wird der Arbeitsthread blockiert, sodass nachfolgende Befehle nicht verarbeitet werden können.

Großen Schlüssel finden

Wenn wir den mit Redis gelieferten Parameter --bigkeys verwenden, um den großen Schlüssel zu finden , Es ist am besten, diesen Befehl auf dem Slave-Knoten auszuführen, da er bei Ausführung auf dem Master-Knoten #🎜🎜# den #🎜🎜# Master-Knoten blockiert. #🎜🎜##🎜🎜##🎜🎜##🎜🎜#Wir können auch den SCAN-Befehl verwenden, um den großen Schlüssel zu finden Großer Schlüssel, Sie müssen zuerst sicherstellen, dass Redis RDB-Persistenz verwendet, und die entsprechende RDB-Datei analysieren. Es gibt fertige Tools im Internet: #🎜🎜##🎜🎜##🎜🎜##🎜🎜##🎜🎜#redis-rdb-tools: Ein in Python-Sprache geschriebenes Tool zur Analyse der RDB-Snapshot-Datei von Redis #🎜🎜 ##🎜🎜##🎜🎜##🎜🎜#Dieses Tool heißt rdb_bigkeys, ist in der Sprache Go geschrieben und kann zur Analyse von Redis RDB-Snapshot-Dateien mit höherer Leistung verwendet werden. #🎜🎜##🎜🎜##🎜🎜##🎜🎜##🎜🎜#Großen Schlüssel löschen#🎜🎜##🎜🎜#Der Kern des Löschvorgangs besteht darin, den vom Schlüssel-Wert-Paar belegten Speicherplatz freizugeben . #🎜🎜##🎜🎜#Das Freigeben von Speicher ist nur der erste Schritt. Um den Speicherplatz effizienter zu verwalten, #🎜🎜#muss das Betriebssystem den freigegebenen Speicherblock in eine verknüpfte Liste einfügen freie Speicherblöcke #🎜🎜# für die spätere Verwaltung und Weiterverteilung. Dieser Vorgang selbst dauert einige Zeit und #🎜🎜# blockiert #🎜🎜# die Anwendung, die gerade Speicher freigibt. #🎜🎜##🎜🎜#Wenn also eine große Menge an Speicher auf einmal freigegeben wird, erhöht sich die Betriebszeit der verknüpften Liste mit freien Speicherblöcken, was dementsprechend zur Blockierung des Redis #🎜🎜#Hauptthread # führt 🎜🎜#, wenn der Hauptthread blockiert wird, kann es bei allen anderen Anfragen zu einer Zeitüberschreitung kommen. Immer mehr Zeitüberschreitungen führen dazu, dass die Redis-Verbindung erschöpft ist und verschiedene Ausnahmen auftreten. #🎜🎜##🎜🎜##🎜🎜#Beim Löschen großer Schlüssel wird empfohlen, die Stapellöschung und die asynchrone Löschung zu verwenden. #🎜🎜#

Datenbank löschen

Das Löschen der Datenbank ist dasselbe wie das oben beschriebene Löschen von Bigkey und Flushall. Dazu gehört auch das Löschen und Freigeben aller Schlüssel-Wert-Paare, die auch die Blockierungspunkte von Redis sind.

Cluster-Erweiterung

Redis-Cluster können Knoten dynamisch erweitern und verkleinern. Dieser Prozess befindet sich derzeit in einem halbautomatischen Zustand und erfordert manuelles Eingreifen.

Während der Expansion und Schrumpfung ist eine Datenmigration erforderlich. Um die Konsistenz der Migration sicherzustellen, sind alle Migrationsvorgänge von Redis synchroneVorgänge.

Beim Durchführen der Migration tritt Redis an beiden Enden in einen Blockierungszustand unterschiedlicher Länge ein. Bei kleinen Schlüsseln kann diese Zeit ignoriert werden, aber wenn die Speichernutzung des Schlüssels zu groß ist, führt dies in schweren Fällen dazu ein Problem innerhalb des Clusters, das zu unnötigem Umschalten führt.

Das obige ist der detaillierte Inhalt vonIn welchen Situationen blockiert Redis?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!