So verwenden Sie die RDB- und AOF-Methoden von Redis

Redis-Persistenzlösung

Redis ist eine In-Memory-Datenbank, und Daten werden im Speicher gespeichert, um einen dauerhaften Datenverlust durch Prozessbeendigung zu vermeiden Redis muss regelmäßig aktualisiert werden. Speichern Sie es in irgendeiner Form (Daten oder Befehl) vom Speicher auf die Festplatte. Verwenden Sie beim nächsten Neustart von Redis die persistente Datei, um eine Datenwiederherstellung zu erreichen. Darüber hinaus können persistente Dateien für Notfallsicherungszwecke an einen Remote-Standort kopiert werden.

Redis bietet mehrere verschiedene Persistenzebenen: eine ist RDB und die andere ist AOF.

RDB-Persistenz kann einen Point-in-Time-Snapshot des Datensatzes innerhalb eines bestimmten Zeitintervalls generieren und den Datenbank-Snapshot in binärer Form auf der Festplatte speichern.

AOF zeichnet dauerhaft alle vom Server ausgeführten Änderungsoperationsbefehle auf. Alle Befehle in der AOF-Datei werden im Format des Redis-Protokolls gespeichert und neue Befehle werden am Ende der Datei angehängt. Redis kann die AOF-Datei auch im Hintergrund neu schreiben, sodass die Größe der AOF-Datei nicht die tatsächliche Größe überschreitet, die zum Speichern des Datensatzstatus erforderlich ist.

Redis kann gleichzeitig AOF-Persistenz und RDB-Persistenz verwenden. In diesem Fall wird beim Neustart von Redis der Verwendung der AOF-Datei zum Wiederherstellen des Datensatzes Vorrang eingeräumt, da der von der AOF-Datei gespeicherte Datensatz normalerweise vollständiger ist als der von der RDB-Datei gespeicherte Datensatz. Sie können die Persistenz sogar deaktivieren, sodass die Daten nur vorhanden sind, während der Server läuft.

Es ist sehr wichtig, die Ähnlichkeiten und Unterschiede zwischen RDB-Persistenz und AOF-Persistenz zu verstehen. In den folgenden Abschnitten werden diese beiden Persistenzfunktionen ausführlich vorgestellt und ihre Ähnlichkeiten und Unterschiede erläutert.

RDB-Snapshot

Lassen Sie uns über die erste Persistenzstrategie von Redis sprechen, den RDB-Snapshot. Redis unterstützt einen Persistenzmechanismus, der einen Snapshot der aktuellen Speicherdaten in einer Datendatei speichert. Wie generiert eine kontinuierlich geschriebene Datenbank einen Snapshot? Redis nutzt geschickt den Copy-on-Write-Mechanismus des fork-Befehls, um den aktuellen Prozess in einen untergeordneten Prozess zu verzweigen. Der untergeordnete Prozess speichert die Daten zyklisch in RDB-Dateien basierend auf dem Speicher-Snapshot.

Standardmäßig speichert Redis den Datenbank-Snapshot im Stammverzeichnis in einer Binärdatei mit dem Namen dump.rdb. Sie können das Speicherverzeichnis über den Parameter dir-Konfiguration angeben, und dbfilename gibt den Dateinamen an. Sie können Redis beispielsweise auf „N M speichern“ festlegen. Dies bedeutet, dass der Datensatz automatisch gespeichert wird, wenn innerhalb von N Sekunden M Änderungen an den Datenelementen vorgenommen werden und diese Bedingung erfüllt ist. Sie können beispielsweise die Erstellung eines Snapshots konfigurieren, wenn innerhalb von 10 Minuten 100 Schreibvorgänge erfolgen, oder Sie können die Erstellung eines Snapshots konfigurieren, wenn innerhalb einer Minute 1.000 Schreibvorgänge erfolgen. Es werden mehrere Regeln unterstützt, die gleichzeitig wirksam werden Die Regel wird wirksam, wenn sie übereinstimmt. 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.

Zum Beispiel führt die folgende Einstellung dazu, dass Redis automatisch einen Datensatz speichert, wenn die Bedingung „mindestens 1000 Schlüssel wurden innerhalb von 60 Sekunden geändert“ erfüllt ist:

save 60 1000

#🎜🎜 #Sie können Redis auch manuell bitten, den Datensatz zu speichern, indem Sie SAVE oder BGSAVE aufrufen. Der SAVE-Befehl führt einen Synchronisierungsvorgang durch und speichert einen Snapshot aller Daten in Form einer RDB-Datei. Der SAVE-Befehl wird selten direkt in der Produktionsumgebung verwendet, da er alle Client-Anfragen blockiert Sie können stattdessen den Befehl BGSAVE verwenden. Der BGSAVE-Befehl wird durch die Verzweigung eines untergeordneten Prozesses ausgeführt, sodass die Clientanforderung nicht blockiert wird. Nur die Verzweigung des untergeordneten Prozesses blockiert den Server. Darüber hinaus wählt Redis beim automatischen Auslösen der RDB-Persistenz auch BGSAVE anstelle von SAVE für die Persistenz.

Die automatische RDB-Persistenz von Redis wird intern durch die periodische Betriebsfunktion von ServerCron, den Dirty Counter und den Lastsave-Zeitstempel implementiert. ServerCron wird alle 100 ms ausgeführt, um den Serverstatus zu überprüfen. Dazu gehört auch die Prüfung, ob „save N M“ die Bedingungen erfüllt. Wenn ja, führt es natürlich auch BGSAVE aus. Der Dirty Counter ist ein vom Redis-Server verwalteter Status. Er zeichnet auf, wie oft der Serverstatus seit der letzten Ausführung des BGSAVE/SAVE-Befehls geändert wurde , dirty wird auf 0 zurückgesetzt. . Der Lastsave-Zeitstempel ist auch ein vom Redis-Server verwalteter Status. Er zeichnet den Zeitpunkt auf, zu dem BGSAVE/SAVE zuletzt erfolgreich ausgeführt wurde. Die aktuelle Zeit minus Lastsave muss M erfüllen.

Zusätzlich zu manuell und automatisch gibt es einige andere Situationen, die BGSAVE auslösen:

Im Master-Slave-Replikationsszenario, wenn der Slave-Knoten einen vollständigen Replikationsvorgang durchführt , führt der Master-Knoten den BGSAVE-Befehl aus und sendet die RDB-Datei an den Slave-Knoten. Beim Ausführen des Shutdown-Befehls wird die RDB-Persistenz automatisch ausgeführt. Darüber hinaus müssen Sie verstehen, dass der von Redis generierte untergeordnete Prozess beim Generieren einer neuen RDB-Datei die Daten zunächst in eine temporäre Datei schreibt und dann das atomare Umbenennungssystem aufruft, da der Schreibvorgang in einem neuen Prozess ausgeführt wird Benennen Sie 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.

这种持久化方式被称为快照（snapshot）。但是，我们可以很明显的看到，RDB有他的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。在某些业务下，如果可以忍受间隔内数据丢失，我们也推荐这些业务使用RDB的方式进行持久化，因为开启RDB的代价并不高。但是对于另外一些对数据安全性要求极高的应用，无法容忍数据丢失的应用，RDB就无能为力了，所以Redis引入了另一个重要的持久化机制，AOF日志方式持久化。

为了尽可能使RDB文件体积减小，Redis默认采用LZF算法对RDB文件进行压缩。虽然压缩耗时，但是可以大大减小RDB文件的体积，因此压缩默认开启，参数为rdbcompression。需要注意的是，RDB文件的压缩并不是针对整个文件进行的，而是对数据库中的字符串进行的，且只有在字符串达到一定长度(20字节)时才会进行。

除了压缩，你也可以检验RDB文件，通过参数rdbchecksum设置，默认为yes。在写入文件和读取文件时都起作用，关闭checksum在写入文件和启动文件时大约能带来10%的性能提升，但是数据损坏时无法发现。

另外，当bgsave出现错误时，Redis是否停止执行写命令。Redis提供了一个参数stop-writes-on-bgsave-error，设置为yes，则当硬盘出现问题时，可以及时发现，避免数据的大量丢失；设置为no，则Redis无视bgsave的错误继续执行写命令，当对Redis服务器的系统(尤其是硬盘)使用了监控时，该选项考虑设置为no。

说说FORK的开销？

父进程通过fork操作可以创建子进程，第一代Unix系统实现了一种傻瓜式的进程创建：当执行fork系统调用时，内核复制父进程的整个用户空间并把复制得到的那一份分配给子进程。这种行为时非常耗时的，因为它需要完成以下几项任务：为子进程的页表分配页面、为子进程的页分配页面、初始化子进程的页表、把父进程的页复制到子进程对应的页中。

现在Linux的fork()使用写时拷贝（copy-on-write）页实现。写时拷贝是一种可以推迟甚至免除拷贝数据的技术。内核此时并不复制整个进程地址空间，而是让父进程和子进程共享同一个拷贝。只有在需要写入的时候，数据才会被复制，从而使各个进程拥有各自的拷贝。也就是说，资源的复制只有在需要写入的时候才进行，在此之前，只是以只读方式共享。这种技术使地址空间上的页的拷贝被推迟到实际发生写入的时候。所以就算fork很大内存的进程，对内存的消耗和耗时都很小。

现在虽然fork时，子进程不会复制父进程的数据空间，但是会复制内存页表（页表相当于内存的索引、目录）；父进程的数据空间越大，内存页表越大，fork时复制耗时也会越多。这个问题也是导致Redis内存不宜过大的原因之一，当然还有导致故障恢复时间延长也是Redis内存不宜过大的原因。

AOF日志

通过上面的分析，我们知道RDB快照有大概率丢失最近写入、且仍未保存到快照中的那些数据。尽管对于某些程序来说，数据安全并不是最重要的考虑因素，但是对于那些追求数据安全的程序来说，快照功能就不太适用了。从1.1版本开始，Redis增加了一种实时性更好的持久化方式，即AOF持久化。AOF日志的全称是append only file，从名字上我们就能看出来，它是一个追加写入的日志文件。与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案。

AOF文件与MySQL数据库的binlog不同的是，AOF是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点，它记录的内容就是一个个的Redis标准命令。开启AOF持久化命令如下：

appendonly yes
appendfilename "appendonly.aof"

从现在开始，每当Redis执行一个改变数据集的命令时（比如SET），这个命令就会被追加到AOF文件的末尾。这样的话，当Redis重新启时，程序就可以通过重新执行AOF文件中的命令来达到重建数据集的目的。

由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程：

命令追加（append）

Redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。

文件写入（write）和文件同步（sync）

Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write函数和fsync函数，说明如下：

Um die Effizienz beim Schreiben von Dateien zu verbessern, speichert das Betriebssystem in modernen Betriebssystemen die Daten normalerweise vorübergehend in einem Speicherpuffer, wenn der Puffer voll ist oder den angegebenen Wert überschreitet Zeitlimit werden die Pufferdaten tatsächlich auf die Festplatte geschrieben. Obwohl ein solcher Vorgang die Effizienz verbessert, bringt er auch Sicherheitsprobleme mit sich: Wenn der Computer herunterfährt, gehen die Daten im Speicherpuffer verloren. Daher stellt das System auch Synchronisierungsfunktionen wie fsync und fdatasync bereit, die das Betriebssystem dazu zwingen können Speichern Sie die Daten sofort im Puffer. Die Daten werden auf die Festplatte geschrieben, um die Datensicherheit zu gewährleisten.

Die Synchronisationsdateistrategie des AOF-Puffers wird durch den Parameter appendfsync gesteuert. Die Bedeutung jedes Werts ist wie folgt:

always: Unmittelbar nach dem Schreiben des Befehls in aof_buf wird die System-fsync-Operation aufgerufen, um mit dem AOF zu synchronisieren Nachdem fsync abgeschlossen ist, kehrt der Thread zurück. In diesem Fall muss jeder Schreibbefehl mit der AOF-Datei synchronisiert werden, und Festplatten-E/A wird zu einem Leistungsengpass. Redis kann nur etwa ein paar hundert TPS-Schreibvorgänge unterstützen, was die Leistung von Redis selbst bei Verwendung eines Solid-State-Laufwerks erheblich beeinträchtigt. SSD) kann nur Zehntausende Befehle pro Sekunde verarbeiten und verkürzt die Lebensdauer der SSD erheblich.

Nein: Nachdem der Befehl in aof_buf geschrieben wurde, wird der Systemschreibvorgang aufgerufen und die AOF-Datei wird nicht vom Betriebssystem synchronisiert. Die Synchronisierungsdauer beträgt normalerweise 30 Sekunden. In diesem Fall kann die Dateisynchronisierungszeit nicht kontrolliert werden, und im Puffer sammeln sich viele Daten an, und die Datensicherheit kann nicht garantiert werden. everysec: Nachdem der Befehl in aof_buf geschrieben wurde, wird der Systemschreibvorgang aufgerufen. Der Thread kehrt zurück, nachdem der Schreibvorgang einmal pro Sekunde von einem dedizierten Thread aufgerufen wurde. Everysec ist ein Kompromiss zwischen den beiden oben genannten Strategien, ein Gleichgewicht zwischen Leistung und Datensicherheit. Daher handelt es sich um die Standardkonfiguration von Redis und unsere empfohlene Konfiguration.

Datei neu schreiben (rewrite)

Da AOF kontinuierlich Befehle an das Ende der Datei anhängt, wird die Größe der AOF-Datei immer größer, wenn die Anzahl der geschriebenen Befehle weiter zunimmt. Wenn Sie INCR beispielsweise 100 Mal für einen Zähler aufrufen, muss die AOF-Datei 100 Einträge verwenden, nur um den aktuellen Wert des Zählers zu speichern. In Wirklichkeit reicht jedoch die Verwendung nur eines SET-Befehls aus, um den aktuellen Wert des Zählers zu speichern, und die verbleibenden 99 Datensätze sind tatsächlich redundant. Darüber hinaus gibt es einige abgelaufene und ungültige Daten, die ebenfalls entfernt werden können.

Übermäßig große AOF-Dateien beeinträchtigen nicht nur den normalen Betrieb des Servers, sondern führen auch dazu, dass die Datenwiederherstellung zu lange dauert. Um mit dieser Situation umzugehen, unterstützt Redis eine interessante Funktion, die die AOF-Datei neu erstellen kann, ohne den Service-Client zu unterbrechen. Führen Sie den Befehl BGREWRITEAOF aus. Redis generiert eine neue AOF-Datei, die die zur Rekonstruktion des aktuellen Datensatzes erforderlichen Mindestbefehle enthält.

Der Generierungsprozess von AOF REWRITE (Umschreiben) ähnelt dem RDB-Snapshot, wobei beide den Copy-on-Write-Mechanismus geschickt nutzen. Außerdem wird ein untergeordneter Prozess gegabelt (der Hauptthread ist zu diesem Zeitpunkt blockiert). Der untergeordnete Prozess schreibt gemäß dem Speicherabriss und den Befehlszusammenführungsregeln in die neue AOF-Datei. Wenn der Hauptprozess den untergeordneten Thread verzweigt und weiterhin Anfragen akzeptiert, werden alle Schreibbefehle weiterhin in den AOF-Puffer (aof_buf) geschrieben und gemäß der appendfsync-Richtlinie mit der Festplatte synchronisiert, um die Richtigkeit des ursprünglichen AOF-Mechanismus sicherzustellen. Da der Fork-Vorgang jedoch die Copy-on-Write-Technologie verwendet, kann der untergeordnete Prozess die Speicherdaten nur während des Fork-Vorgangs gemeinsam nutzen. Da der übergeordnete Prozess immer noch auf den Befehl reagiert, verwendet Redis den AOF-Rewrite-Puffer (aof_rewrite_buf), um diesen Teil des neuen Protokolls zu speichern und zu verhindern, dass dieser Teil der Daten während der Generierung der neuen AOF-Datei verloren geht. Mit anderen Worten: Während der Ausführung von bgrewriteaof wird der Redis-Schreibbefehl gleichzeitig an die beiden Puffer aof_buf und aof_rewirte_buf angehängt.

Wenn der untergeordnete Prozess mit dem Schreiben der neuen AOF-Datei fertig ist, sendet er ein Signal an den übergeordneten Prozess und der übergeordnete Prozess aktualisiert die statistischen Informationen, die über die Informationspersistenz angezeigt werden können. Anschließend schreibt der übergeordnete Prozess die Daten im AOF-Rewrite-Puffer in die neue AOF-Datei und stellt so sicher, dass der in der neuen AOF-Datei gespeicherte Datenbankstatus mit dem aktuellen Status des Servers übereinstimmt. Rufen Sie dann den Befehl zum atomaren Umbenennen auf, um die alte AOF-Datei durch die neue AOF-Datei zu ersetzen und das AOF-Umschreiben abzuschließen.

Hier müssen Sie aufpassen, da der Hauptprozess den aof_rewrite_buf-Cache an die neue Protokolldatei anhängt. Wenn der Hauptprozess Protokolle anhängt, verarbeitet er keine anderen Anforderungen. Wenn aof_rewrite_buf besonders groß ist, z. B. Hunderte von M, kann dies dazu führen, dass Redis mehrere Sekunden oder sogar Dutzende Sekunden lang nicht antwortet.

Aus dem obigen Prozess können wir ersehen, dass sowohl RDB- als auch AOF-Vorgänge sequentielle E/A-Vorgänge sind und ihre Leistung sehr hoch ist. Bei der Wiederherstellung der Datenbank über RDB-Dateien oder AOF-Protokolle werden die Daten ebenfalls sequentiell gelesen und in den Speicher geladen. Es kommt also nicht zu einem zufälligen Lesen der Festplatte.

Das Auslösen des Umschreibens von Dateien ist in manuelles Auslösen und automatisches Auslösen unterteilt:

Manuelles Auslösen: Rufen Sie den Befehl bgrewriteaof direkt auf. Die Ausführung dieses Befehls ähnelt in gewisser Weise der von bgsave: Beide Fork-Unterprozesse führen bestimmte Arbeiten aus, und das tun sie auch Wird nur nach der Gabelzeitblockierung durchgeführt.

Automatische Auslösung: Bestimmen Sie die Auslösezeit basierend auf den Parametern „auto-aof-rewrite-min-size“ und „auto-aof-rewrite-percentage“ sowie dem Status „aof_current_size“ und „aof_base_size“.

auto-aof-rewrite-min-size gibt die Mindestgröße der Datei an, wenn das AOF-Umschreiben durchgeführt wird. Der Standardwert beträgt 64 MB.

auto-aof-rewrite-percentage表示执行AOF重写时，当前AOF大小（即aof_current_size）和上一次重写时AOF大小（aof_base_size）的比值，即增长比例达到设定值。

只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个参数同时满足时，才会自动触发AOF重写，即bgrewriteaof操作。

其中，参数可以通过config get命令查看：

127.0.0.1:6391> CONFIG GET auto-aof-rewrite-min-size
1) "auto-aof-rewrite-min-size"2) "64000000"127.0.0.1:6391> CONFIG GET auto-aof-rewrite-percentage
1) "auto-aof-rewrite-percentage"2) "100"

状态可以通过info persistence查看：

127.0.0.1:6379> info persistence# Persistenceaof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:0
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_current_size:40876638
aof_base_size:2217565
aof_pending_rewrite:0
aof_buffer_length:0
aof_rewrite_buffer_length:0
aof_pending_bio_fsync:0
aof_delayed_fsync:0

另外在aof rewrite过程中，是否采取增量”文件同步”策略，由参数aof-rewrite-incremental-fsync控制，默认为”yes”，而且必须为yes。rewrite过程中，每32M数据进行一次文件同步，这样可以减少”aof大文件”写入对磁盘的操作次数。

bgrewriteaof机制，在一个子进程中进行aof的重写，从而不阻塞主进程对其余命令的处理，同时解决了aof文件过大问题。现在问题出现了，同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，现在no-appendfsync-on-rewrite参数出场了。

如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候Redis挂掉，就会丢失数据。丢失多少数据呢？在Linux的操作系统的默认设置下，最多会丢失30s的数据。因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。

AOF刷新策略？

前面提到过，在AOF中，如果AOF缓冲区的文件同步策略为everysec，则：在主线程中，命令写入aof_buf后调用系统write操作，write完成后主线程返回；fsync同步文件操作由专门的文件同步线程每秒调用一次。这种做法的问题在于，如果硬盘负载过高，那么fsync操作可能会超过1s；如果Redis主线程持续高速向aof_buf写入命令，硬盘的负载可能会越来越大，IO资源消耗更快；如果此时Redis进程异常退出，丢失的数据也会越来越多，可能远超过1s。

为此，Redis的处理策略是这样的：主线程每次进行AOF会对比上次fsync成功的时间；如果距上次不到2s（也就是延迟了1s），主线程直接返回；如果超过2s，则主线程阻塞直到上一次fsync同步完成。因此，如果系统硬盘负载过大导致fsync速度太慢，会导致Redis主线程的阻塞；此外，使用everysec配置，AOF最多可能丢失2s的数据，而不是1s。具体看Redis AOF刷新策略分析

AOF追加阻塞问题定位的方法，监控info Persistence中的aof_delayed_fsync，当AOF追加阻塞发生时（即主线程等待fsync而阻塞），该指标累加。另外，AOF阻塞时的Redis日志：Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

如果AOF追加阻塞频繁发生，说明系统的硬盘负载太大；可以考虑更换IO速度更快的硬盘，或者通过IO监控分析工具对系统的IO负载进行分析。

对于pipelining有什么不同？

对于pipelining的操作，其具体过程是客户端一次性发送N个命令，然后等待这N个命令的返回结果被一起返回。通过采用pipilining就意味着放弃了对每一个命令的返回值确认。由于在这种情况下，N个命令是在同一个执行过程中执行的。所以当设置appendfsync为everysec时，可能会有一些偏差，因为这N个命令可能执行时间超过1秒甚至2秒。但是可以保证的是，最长时间不会超过这N个命令的执行时间和。

如果AOF文件出错了，怎么办？

服务器可能在程序正在对AOF文件进行写入时停机，如果停机造成了 AOF 文件出错（corrupt），那么Redis在重启时会拒绝载入这个AOF文件， 从而确保数据的一致性不会被破坏。当发生这种情况时，可以用以下方法来修复出错的 AOF 文件：为现有的AOF文件创建一个备份。然后使用Redis附带的redis-check-aof –fix程序对原来的AOF文件进行修复。

然后可选使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。再次重启Redis服务器，等待服务器载入修复后的AOF文件，并进行数据恢复。

Aber wenn das Ende der AOF-Datei unvollständig ist (ein plötzlicher Maschinenstillstand kann leicht dazu führen, dass das Ende der Datei unvollständig ist) und der Parameter aof-load-truncated aktiviert ist, wird im Protokoll eine Warnung ausgegeben Redis ignoriert das Ende der AOF-Datei und startet erfolgreich. Der aof-load-truncated-Parameter ist standardmäßig aktiviert.

Vor- und Nachteile von RDB und AOF

Vorteile von RDB?

RDB ist eine sehr kompakte Datei mit geringer Größe und schneller Netzwerkübertragung. Sie speichert den Redis-Datensatz zu einem bestimmten Zeitpunkt. Diese Art von Datei eignet sich sehr gut für die Sicherung und die Wiederherstellungsgeschwindigkeit ist viel schneller als bei AOF. Einer der wichtigsten Vorteile von RDB besteht natürlich darin, dass es im Vergleich zu AOF einen relativ geringen Einfluss auf die Leistung hat. Das Einzige, was der übergeordnete Prozess beim Speichern der RDB-Datei tun muss, ist, einen untergeordneten Prozess auszulagern. Anschließend übernimmt der untergeordnete Prozess alle nachfolgenden Speicherarbeiten. Der übergeordnete Prozess muss keine Festplatten-E/A-Vorgänge ausführen.

Nachteile von RDB?

Der schwerwiegende Nachteil von RDB-Dateien besteht darin, dass die Persistenzmethode von Daten-Snapshots dazu führt, dass eine Echtzeit-Persistenz nicht erreicht werden kann. Heutzutage, wenn Daten immer wichtiger werden, ist ein großer Datenverlust oft inakzeptabel, weshalb AOF-Persistenz erforderlich ist zum Mainstream werden. Darüber hinaus müssen RDB-Dateien einem bestimmten Format entsprechen und eine schlechte Kompatibilität aufweisen (z. B. ist die alte Version von Redis nicht mit der neuen Version von RDB-Dateien kompatibel).

Vorteile von AOF?

Entsprechend der RDB-Persistenz besteht der Vorteil von AOF darin, dass es die Persistenz der zweiten Ebene unterstützt und eine gute Kompatibilität aufweist. Sie können verschiedene Fsync-Richtlinien festlegen, z. B. „kein Fsync“, „fsync jede Sekunde“ oder „fsync jedes Mal, wenn ein Schreibbefehl ausgeführt wird“. Die Standardrichtlinie von AOF ist fsync einmal pro Sekunde. Unter dieser Konfiguration kann Redis immer noch eine gute Leistung aufrechterhalten, und selbst wenn ein Fehler auftritt, geht höchstens eine Sekunde an Daten verloren. Bei der AOF-Datei handelt es sich um eine Protokolldatei, die nur Anhängevorgänge ausführt (nur Protokoll anfügen), sodass beim Schreiben in die AOF-Datei keine Suche erforderlich ist, selbst wenn das Protokoll aus bestimmten Gründen (z. B. beim Schreiben) unvollständige Befehle enthält. Die Festplatte ist voll, das Schreiben ist voll während des Schreibens gestoppt wurde usw.), kann das Tool redis-check-aof dieses Problem ebenfalls leicht beheben.

Redis kann die AOF automatisch im Hintergrund neu schreiben, wenn die AOF-Datei zu groß wird: Die neu geschriebene neue AOF-Datei enthält den Mindestsatz an Befehlen, der zum Wiederherstellen des aktuellen Datensatzes erforderlich ist. Der gesamte Umschreibvorgang ist absolut sicher, da Redis während des Erstellungsprozesses einer neuen AOF-Datei weiterhin Befehle an die vorhandene AOF-Datei anhängt. Selbst wenn es während des Umschreibvorgangs zu einem Herunterfahren kommt, geht die vorhandene AOF-Datei nicht verloren. . Sobald die neue AOF-Datei erstellt wurde, wechselt Redis von der alten AOF-Datei zur neuen AOF-Datei und beginnt mit dem Anhängen an die neue AOF-Datei. Die AOF-Datei speichert alle in der Datenbank ausgeführten Schreibvorgänge in geordneter Weise. Diese Schreibvorgänge werden im Format des Redis-Protokolls gespeichert, sodass der Inhalt der AOF-Datei sehr einfach zu lesen und die Datei leicht zu analysieren ist ( analysieren). Das Exportieren (Exportieren) von AOF-Dateien ist ebenfalls sehr einfach: Wenn Sie beispielsweise versehentlich den FLUSHALL-Befehl ausführen, die AOF-Datei jedoch nicht überschrieben wurde, stoppen Sie einfach den Server und entfernen Sie den FLUSHALL-Befehl am Ende der AOF Datei und starten Sie Redis neu. Sie können den Datensatz in den Zustand vor der Ausführung von FLUSHALL zurückversetzen.

Nachteile von AOF?

Die Größe von AOF-Dateien ist normalerweise größer als die von RDB-Dateien und die Wiederherstellungsgeschwindigkeit ist langsam. Für denselben Datensatz kann AOF abhängig von der verwendeten fsync-Strategie langsamer sein als RDB. Unter normalen Umständen ist die Leistung von fsync pro Sekunde immer noch sehr hoch, und durch Deaktivieren von fsync kann AOF so schnell wie RDB werden. Darüber hinaus gab es bei AOF in der Vergangenheit einen solchen Fehler. Aufgrund bestimmter Befehle konnte der Datensatz beim erneuten Laden der AOF-Datei nicht in den ursprünglichen Zustand zurückversetzt werden. Obwohl diese Art von Fehler in AOF-Dateien nicht häufig vorkommt, ist es im Vergleich dazu bei RDB fast unmöglich, einen solchen Fehler zu haben.

RDB und AOF, welches soll ich verwenden?

Zuallererst müssen Sie verstehen, dass das Aktivieren der Persistenz unabhängig davon, ob es sich um RDB oder AOF handelt, mit Leistungseinbußen verbunden ist: Bei der RDB-Persistenz wird einerseits der Redis-Hauptprozess blockiert, wenn bgsave einen Fork-Vorgang ausführt, und andererseits Andererseits führt der untergeordnete Prozess, der Daten auf die Festplatte schreibt, auch zu E/A-Druck. Wenn das Unternehmen jedoch einen Datenverlust von einigen Minuten bis 10 Minuten tolerieren kann (und keine Standby-Datenbank verwendet), ist RDB eine gute Wahl, andernfalls entscheiden Sie sich für AOF.

Für die AOF-Persistenz wird die Häufigkeit des Schreibens von Daten auf die Festplatte erheblich erhöht (zweite Ebene unter der Everysec-Richtlinie) und der E/A-Druck ist größer, was sogar zu Problemen mit der Blockierung von AOF-Anhängen führen kann (diese Blockierung wird später ausführlich beschrieben). ). Darüber hinaus ähnelt das Umschreiben von AOF-Dateien dem bgsave von RDB, und es kommt zu Problemen mit der Blockierung während der Verzweigung und dem E/A-Druck auf den untergeordneten Prozess. Da AOF häufiger Daten auf die Festplatte schreibt, hat dies relativ gesehen einen größeren Einfluss auf die Leistung des Redis-Hauptprozesses.

在实际生产环境中，根据数据量、应用对数据的安全要求、预算限制等不同情况，会有各种各样的持久化策略；如完全不使用任何持久化、使用RDB或AOF的一种，或同时开启RDB和AOF持久化等。此外，持久化的选择必须与Redis的主从策略一起考虑，因为主从复制与持久化同样具有数据备份的功能，而且主机master和从机slave可以独立的选择持久化方案。比如完全关闭master持久化（包括RDB和AOF），这样可以让master的性能达到最好；而slave可以只开启AOF。但这种情况下，如果master服务因为故障宕掉了，如果系统中有自动拉起机制（即检测到服务停止后重启该服务）将master自动重启，由于没有持久化文件，那么master重启后数据是空的，slave同步数据也变成了空的，意味着数据丢失。所以尽量避免这种情况出现。

RDB和AOF之间的相互作用？

在版本号大于等于2.4的Redis中，BGSAVE执行的过程中，不可以执行BGREWRITEAOF。反过来说，在BGREWRITEAOF执行的过程中，也不可以执行BGSAVE。这可以防止两个Redis后台进程同时对磁盘进行大量的I/O操作。

如果BGSAVE正在执行，并且用户显示地调用BGREWRITEAOF命令，那么服务器将向用户回复一个OK状态，并告知用户，BGREWRITEAOF已经被预定执行： 一旦BGSAVE执行完毕，BGREWRITEAOF就会正式开始。当Redis启动时，如果RDB持久化和AOF持久化都被打开了，那么程序会优先使用AOF文件来恢复数据集，因为AOF文件所保存的数据通常是最完整的。

RDB和AOF数据导入

这些持久化的数据有什么用，当然是用于重启后的数据恢复。Redis是一个内存数据库，无论是RDB还是AOF，都只是其保证数据恢复的措施。所以Redis在利用RDB或AOF进行恢复的时候，会读取RDB或AOF文件，重新加载到内存中。相对于MySQL等数据库的启动时间来说，会长很多，因为MySQL本来是不需要将数据加载到内存中的。

但是相对来说，MySQL启动后提供服务时，其被访问的热数据也会慢慢加载到内存中，通常我们称之为预热，而在预热完成前，其性能都不会太高。而Redis的好处是一次性将数据加载到内存中，一次性预热。这样只要Redis启动完成，那么其提供服务的速度都是非常快的。

而在利用RDB和利用AOF启动上，其启动时间有一些差别。RDB的启动时间会更短，原因有两个，一是RDB文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作。在CPU消耗上要远小于AOF日志的加载。

注意：当redis启动时，如果rdb持久化和aof持久化都打开了，那么程序会优先使用aof方式来恢复数据集，因为aof方式所保存的数据通常是最完整的。如果aof文件丢失了，则启动之后数据库内容为空。

注意：如果想把正在运行的redis数据库，从RDB切换到AOF，建议先使用动态切换方式，再修改配置文件，重启数据库。(不能直接修改配置文件，重启数据库，否则数据库中数据就为空了。) 在Redis 2.2或以上版本，可以在不重启的情况下，从RDB切换到AOF ：

为最新的dump.rdb文件创建一个备份，将备份放到一个安全的地方。执行以下两条命令：

127.0.0.1:6379> CONFIG SET dir /apps/redis/data/redis-8836
127.0.0.1:6379> CONFIG SET appendonly yes
127.0.0.1:6379> CONFIG SET save ""

确保命令执行之后，数据库的键的数量没有改变。确保写命令会被正确地追加到 AOF 文件的末尾。

步骤2是开启了AOF功能，Redis会阻塞直到初始AOF文件创建完成为止，之后Redis会继续处理命令请求，并开始将写入命令追加到AOF文件末尾。

步骤3用于关闭RDB功能，这一步是可选的，如果你愿意的话，也可以同时使用RDB和AOF这两种持久化功能。

Das obige ist der detaillierte Inhalt vonSo verwenden Sie die RDB- und AOF-Methoden von Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!