Beherrschen Sie die Redis-Persistenz vollständig: RDB und AOF

Dieser Artikel bringt Ihnen relevantes Wissen über Redis, in dem hauptsächlich Fragen im Zusammenhang mit der Persistenz vorgestellt werden, einschließlich der Frage, warum Persistenz erforderlich ist, RDB-Persistenz, AOF-Persistenz usw. Schauen wir uns das gemeinsam an. Ich hoffe, es hilft allen.

Empfohlenes Lernen: Redis-Video-Tutorial

1. Warum ist Beharrlichkeit erforderlich?

Redis verarbeitet Daten basierend auf dem Speicher. Wenn unerwartete Situationen wie Prozessabbrüche und Serverausfälle auftreten und kein Persistenzmechanismus vorhanden ist, gehen die Daten in Redis verloren und können nicht wiederhergestellt werden. Mit dem Persistenzmechanismus kann Redis beim nächsten Neustart zuvor persistente Dateien zur Datenwiederherstellung verwenden. Zwei von Redis unterstützte Persistenzmechanismen:

RDB: Erstellt einen Snapshot der aktuellen Daten und speichert ihn auf der Festplatte.
AOF: Zeichnen Sie jeden Datenvorgang auf der Festplatte auf.

2. RDB-Persistenz

schreibt den Snapshot des Datensatzes im Speicher innerhalb des angegebenen Zeitintervalls auf die Festplatte. Bei der Wiederherstellung wird die Snapshot-Datei direkt in den Speicher eingelesen. Bei der RDB-Persistenz (Redis DataBase) wird ein Snapshot aller aktuellen Daten in Redis erstellt und auf der Festplatte gespeichert. Die RDB-Persistenz kann manuell oder automatisch ausgelöst werden.

1. Wie wird die Sicherung durchgeführt?

redis erstellt (Fork) einen separaten Unterprozess für die Persistenz. Er schreibt die Daten zunächst in eine temporäre Datei. Nach Abschluss des Persistenzprozesses wird diese temporäre Datei verwendet, um die letzte persistente Datei zu ersetzen. Während des gesamten Prozesses führt der Hauptprozess keine IO-Operationen aus, was eine extrem hohe Leistung gewährleistet. Wenn eine groß angelegte Datenwiederherstellung erforderlich ist und die Integrität der Datenwiederherstellung nicht sehr empfindlich ist, ist die RDB-Methode effizienter als die AOF-Methode. Der Nachteil von RDB besteht darin, dass die zuletzt gespeicherten Daten verloren gehen können.

2. RDB-Persistenzprozess

3. Manuelle Auslösung

Sowohl die Befehle save als auch bgsave können die RDB-Persistenz manuell auslösen. save和 bgsave命令都可以手动触发RDB持久化。

1. save
   执行save命令会手动触发RDB持久化，但是save命令会阻塞Redis服务，直到RDB持久化完成。当Redis服务储存大量数据时，会造成较长时间的阻塞，不建议使用。
2. bgsave
   执行bgsave命令也会手动触发RDB持久化，和save命令不同是：Redis服务一般不会阻塞。Redis进程会执行fork操作创建子进程，RDB持久化由子进程负责，不会阻塞Redis服务进程。Redis服务的阻塞只发生在fork阶段，一般情况时间很短。
   bgsave命令的具体流程如下图：
   
   1、执行bgsave命令，Redis进程先判断当前是否存在正在执行的RDB或AOF子线程，如果存在就是直接结束。
   2、Redis进程执行fork操作创建子线程，在fork操作的过程中Redis进程会被阻塞。
   3、Redis进程fork完成后，bgsave命令就结束了，自此Redis进程不会被阻塞，可以响应其他命令。
   4、子进程根据Redis进程的内存生成快照文件，并替换原有的RDB文件。
   5、同时发送信号给主进程，通知主进程rdb持久化完成，主进程更新相关的统计信息（info Persitence下的rdb_*相关选项）。

4、自动触发

除了执行以上命令手动触发以外，Redis内部可以自动触发RDB持久化。自动触发的RDB持久化都是采用bgsave的方式，减少Redis进程的阻塞。那么，在什么场景下会自动触发呢？

1. 在配置文件中设置了save的相关配置，如sava m n，它表示在m秒内数据被修改过n次时，自动触发bgsave操作。
2. 当从节点做全量复制时，主节点会自动执行bgsave操作，并且把生成的RDB文件发送给从节点。
3. 执行debug reload命令时，也会自动触发bgsave操作。
4. 执行shutdown命令时，如果没有开启AOF持久化也会自动触发bgsave

1. save

   Durch Ausführen des Befehls save wird die RDB-Persistenz manuell ausgelöst, aber der Befehl save blockiert Redis Serve, bis die RDB-Persistenz abgeschlossen ist. Wenn der Redis-Dienst große Datenmengen speichert, führt dies zu einer langfristigen Überlastung und wird nicht empfohlen.

2. 🎜bgsave🎜🎜 Das Ausführen des Befehls bgsave löst auch manuell die RDB-Persistenz aus. Anders als beim Befehl save: der Redis-Dienst im Allgemeinen wird nicht blockiert. Der Redis-Prozess führt einen Fork-Vorgang aus, um einen untergeordneten Prozess zu erstellen. Der untergeordnete Prozess ist für die RDB-Persistenz verantwortlich und blockiert den Redis-Dienstprozess nicht. Die Blockierung des Redis-Dienstes erfolgt nur in der Fork-Phase und die Zeit ist im Allgemeinen sehr kurz. 🎜🎜bgsaveDer spezifische Prozess des Befehls ist wie folgt: 🎜🎜🎜 1. Führen Sie den Befehl bgsave aus. Der Redis-Prozess ermittelt zunächst, ob derzeit ein ausgeführter RDB- oder AOF-Sub-Thread vorhanden ist. Falls vorhanden, es wird direkt enden. 🎜 2. Der Redis-Prozess führt einen Fork-Vorgang durch, um einen untergeordneten Thread zu erstellen. Der Redis-Prozess wird während des Fork-Vorgangs blockiert. 🎜 3. Nachdem der Redis-Prozesszweig abgeschlossen ist, wird der Befehl bgsave beendet. Von da an wird der Redis-Prozess nicht blockiert und kann auf andere Befehle reagieren. 🎜 4. Der untergeordnete Prozess generiert eine Snapshot-Datei basierend auf dem Speicher des Redis-Prozesses und ersetzt die ursprüngliche RDB-Datei. 🎜 5. Senden Sie gleichzeitig ein Signal an den Hauptprozess, um den Hauptprozess darüber zu informieren, dass die RDB-Persistenz abgeschlossen ist, und der Hauptprozess aktualisiert relevante statistische Informationen (rdb_*-bezogene Optionen unter Info Persistenz). 🎜🎜🎜4. Automatische Auslösung🎜🎜Zusätzlich zur manuellen Auslösung durch Ausführen des oben genannten Befehls kann die RDB-Persistenz automatisch in Redis ausgelöst werden. Die automatisch ausgelöste RDB-Persistenz verwendet die Methode bgsave, um die Blockierung des Redis-Prozesses zu reduzieren. Unter welchen Umständen wird es also automatisch ausgelöst? 🎜
   1. Die zugehörige Konfiguration von save wird in der Konfigurationsdatei festgelegt, z. B. sava m n, was bedeutet, dass die Daten innerhalb von m n-mal geändert werden Sekunden, löst automatisch den bgsave-Vorgang aus. 🎜
   2. Wenn der Slave-Knoten eine vollständige Replikation durchführt, führt der Master-Knoten automatisch den bgsave-Vorgang aus und sendet die generierte RDB-Datei an den Slave-Knoten. 🎜
   3. Beim Ausführen des Befehls debug reload wird auch der Vorgang bgsave automatisch ausgelöst. 🎜
   4. Wenn beim Ausführen des Befehls shutdown die AOF-Persistenz nicht aktiviert ist, wird der Vorgang bgsave automatisch ausgelöst. 🎜🎜🎜5. RDB-Vorteile🎜🎜RDB-Datei ist eine kompakte binäre komprimierte Datei, die eine Momentaufnahme aller Redis-Daten zu einem bestimmten Zeitpunkt darstellt. Daher ist die Geschwindigkeit der Datenwiederherstellung mit RDB viel schneller als mit AOF, was sich sehr gut für Szenarien wie Sicherung, vollständige Replikation und Notfallwiederherstellung eignet. 🎜

      6. Nachteile von RDB

      Jedes Mal, wenn Sie einen bgsave-Vorgang ausführen, müssen Sie einen Fork-Vorgang durchführen, um einen untergeordneten Vorgang zu erstellen Echtzeit-Persistenz kann nicht erreicht werden, oder auf der zweiten Ebene Persistenz. bgsave操作都要执行fork操作创建子经常，属于重量级操作，频繁执行成本过高，所以无法做到实时持久化，或者秒级持久化。

      另外，由于Redis版本的不断迭代，存在不同格式的RDB版本，有可能出现低版本的RDB格式无法兼容高版本RDB文件的问题。

      7、dump.rdb中配置RDB

      快照周期：内存快照虽然可以通过技术人员手动执行SAVE或BGSAVE

      Darüber hinaus gibt es aufgrund der kontinuierlichen Iteration von Redis-Versionen RDB-Versionen in unterschiedlichen Formaten, und es kann ein Problem auftreten, dass RDB-Formate niedrigerer Versionen nicht mit RDB-Dateien höherer Versionen kompatibel sind. 7. Konfigurieren Sie RDB in dump.rdb In den meisten Fällen werden periodische Ausführungsbedingungen festgelegt.
      • Neue Standardzykluseinstellungen in Redis

      # 周期性执行条件的设置格式为
      save <seconds> <changes>
      
      # 默认的设置为：
      save 900 1
      save 300 10
      save 60 10000
      
      # 以下设置方式为关闭RDB快照功能
      save ""</changes></seconds>

      Die Bedeutung der oben genannten drei Standardinformationseinstellungen ist:🎜
      • 如果900秒内有1条Key信息发生变化，则进行快照；
      • 如果300秒内有10条Key信息发生变化，则进行快照；
      • 如果60秒内有10000条Key信息发生变化，则进行快照。读者可以按照这个规则，根据自己的实际请求压力进行设置调整。
      • 其它相关配置

      # 文件名称
      dbfilename dump.rdb
      
      # 文件保存路径
      dir ./
      
      # 如果持久化出错，主进程是否停止写入
      stop-writes-on-bgsave-error yes
      
      # 是否压缩
      rdbcompression yes
      
      # 导入时是否检查
      rdbchecksum yes

      • dbfilename：RDB文件在磁盘上的名称。
      • dir：RDB文件的存储路径。默认设置为“./”，也就是Redis服务的主目录。
      • stop-writes-on-bgsave-error：上文提到的在快照进行过程中，主进程照样可以接受客户端的任何写操作的特性，是指在快照操作正常的情况下。如果快照操作出现异常（例如操作系统用户权限不够、磁盘空间写满等等）时，Redis就会禁止写操作。这个特性的主要目的是使运维人员在第一时间就发现Redis的运行错误，并进行解决。一些特定的场景下，您可能需要对这个特性进行配置，这时就可以调整这个参数项。该参数项默认情况下值为yes，如果要关闭这个特性，指定即使出现快照错误Redis一样允许写操作，则可以将该值更改为no。
      • rdbcompression：该属性将在字符串类型的数据被快照到磁盘文件时，启用LZF压缩算法。Redis官方的建议是请保持该选项设置为yes，因为“it’s almost always a win”。
      • rdbchecksum：从RDB快照功能的version 5 版本开始，一个64位的CRC冗余校验编码会被放置在RDB文件的末尾，以便对整个RDB文件的完整性进行验证。这个功能大概会多损失10%左右的性能，但获得了更高的数据可靠性。所以如果您的Redis服务需要追求极致的性能，就可以将这个选项设置为no。

      8、 RDB 更深入理解

      • 由于生产环境中我们为Redis开辟的内存区域都比较大（例如6GB），那么将内存中的数据同步到硬盘的过程可能就会持续比较长的时间，而实际情况是这段时间Redis服务一般都会收到数据写操作请求。那么如何保证数据一致性呢？
        RDB中的核心思路是Copy-on-Write，来保证在进行快照操作的这段时间，需要压缩写入磁盘上的数据在内存中不会发生变化。在正常的快照操作中，一方面Redis主进程会fork一个新的快照进程专门来做这个事情，这样保证了Redis服务不会停止对客户端包括写请求在内的任何响应。另一方面这段时间发生的数据变化会以副本的方式存放在另一个新的内存区域，待快照操作结束后才会同步到原来的内存区域。
        举个例子：如果主线程对这些数据也都是读操作（例如图中的键值对 A），那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据（例如图中的键值对 C），那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。
        
      • 在进行快照操作的这段时间，如果发生服务崩溃怎么办？
        很简单，在没有将数据全部写入到磁盘前，这次快照操作都不算成功。如果出现了服务崩溃的情况，将以上一次完整的RDB快照文件作为恢复内存数据的参考。也就是说，在快照操作过程中不能影响上一次的备份数据。Redis服务会在磁盘上创建一个临时文件进行数据操作，待操作成功后才会用这个临时文件替换掉上一次的备份。
      • 可以每秒做一次快照吗？
        对于快照来说，所谓“连拍”就是指连续地做快照。这样一来，快照的间隔时间变得很短，即使某一时刻发生宕机了，因为上一时刻快照刚执行，丢失的数据也不会太多。但是，这其中的快照间隔时间就很关键了。
        如下图所示，我们先在 T0 时刻做了一次快照，然后又在 T0+t 时刻做了一次快照，在这期间，数据块 5 和 9 被修改了。如果在 t 这段时间内，机器宕机了，那么，只能按照 T0 时刻的快照进行恢复。此时，数据块 5 和 9 的修改值因为没有快照记录，就无法恢复了。
        

      针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决

      三、AOF持久化

      AOF（Append Only File）持久化是把每次写命令追加写入日志中，当需要恢复数据时重新执行AOF文件中的命令就可以了。AOF解决了数据持久化的实时性，也是目前主流的Redis持久化方式。

      Redis是“写后”日志，Redis先执行命令，把数据写入内存，然后才记录日志。日志里记录的是Redis收到的每一条命令，这些命令是以文本形式保存。PS: 大多数的数据库采用的是写前日志（WAL），例如MySQL，通过写前日志和两阶段提交，实现数据和逻辑的一致性。

      而AOF日志采用写后日志，即先写内存，后写日志。
      
      为什么采用写后日志？
      Redis要求高性能，采用写日志有两方面好处：

      • 避免额外的检查开销：Redis 在向 AOF 里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志再执行命令的话，日志中就有可能记录了错误的命令，Redis 在使用日志恢复数据时，就可能会出错。
      • 不会阻塞当前的写操作

      但这种方式存在潜在风险：

      • 如果命令执行完成，写日志之前宕机了，会丢失数据。
      • 主线程写磁盘压力大，导致写盘慢，阻塞后续操作。

      1、如何实现AOF？

      AOF日志记录Redis的每个写命令，步骤分为：命令追加（append）、文件写入（write）和文件同步（sync）。

      • 命令追加 当AOF持久化功能打开了，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器的 aof_buf 缓冲区。
      • 文件写入和同步 关于何时将 aof_buf 缓冲区的内容写入AOF文件中，Redis提供了三种写回策略：
        
      • Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
      • Everysec，每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
      • No，操作系统控制的写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

      2、redis.conf中配置AOF

      默认情况下，Redis是没有开启AOF的，可以通过配置redis.conf文件来开启AOF持久化，关于AOF的配置如下：

      # appendonly参数开启AOF持久化
      appendonly no
      
      # AOF持久化的文件名，默认是appendonly.aof
      appendfilename "appendonly.aof"
      
      # AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的
      dir ./
      
      # 同步策略
      # appendfsync always
      appendfsync everysec
      # appendfsync no
      
      # aof重写期间是否同步
      no-appendfsync-on-rewrite no
      
      # 重写触发配置
      auto-aof-rewrite-percentage 100
      auto-aof-rewrite-min-size 64mb
      
      # 加载aof出错如何处理
      aof-load-truncated yes
      
      # 文件重写策略
      aof-rewrite-incremental-fsync yes

      以下是Redis中关于AOF的主要配置信息：
      appendfsync：这个参数项是AOF功能最重要的设置项之一，主要用于设置“真正执行”操作命令向AOF文件中同步的策略。

      什么叫“真正执行”呢？还记得Linux操作系统对磁盘设备的操作方式吗？ 为了保证操作系统中I/O队列的操作效率，应用程序提交的I/O操作请求一般是被放置在linux Page Cache中的，然后再由Linux操作系统中的策略自行决定正在写到磁盘上的时机。而Redis中有一个fsync()函数，可以将Page Cache中待写的数据真正写入到物理设备上，而缺点是频繁调用这个fsync()函数干预操作系统的既定策略，可能导致I/O卡顿的现象频繁 。

      与上节对应，appendfsync参数项可以设置三个值，分别是：always、everysec、no，默认的值为everysec。

      no-appendfsync-on-rewrite：always和everysec的设置会使真正的I/O操作高频度的出现，甚至会出现长时间的卡顿情况，这个问题出现在操作系统层面上，所有靠工作在操作系统之上的Redis是没法解决的。为了尽量缓解这个情况，Redis提供了这个设置项，保证在完成fsync函数调用时，不会将这段时间内发生的命令操作放入操作系统的Page Cache（这段时间Redis还在接受客户端的各种写操作命令）。

      Auto-aof-rewrite-percentage: Wie oben erwähnt, ist es in einer Produktionsumgebung für Techniker unmöglich, den Befehl „BGREWRITEAOF“ zu verwenden, um AOF-Dateien jederzeit und überall neu zu schreiben. Daher müssen wir uns häufiger auf die automatische Umschreibungsstrategie von AOF-Dateien in Redis verlassen. Redis bietet zwei Einstellungen zum Auslösen des automatischen Neuschreibens von AOF-Dateien: BGREWRITEAOF”命令去重写AOF文件。所以更多时候我们需要依靠Redis中对AOF文件的自动重写策略。Redis中对触发自动重写AOF文件的操作提供了两个设置：
      auto-aof-rewrite-percentage表示如果当前AOF文件的大小超过了上次重写后AOF文件的百分之多少后，就再次开始重写AOF文件。例如该参数值的默认设置值为100，意思就是如果AOF文件的大小超过上次AOF文件重写后的1倍，就启动重写操作。
      auto-aof-rewrite-min-size：设置项表示启动AOF文件重写操作的AOF文件最小大小。如果AOF文件大小低于这个值，则不会触发重写操作。注意，auto-aof-rewrite-percentage和auto-aof-rewrite-min-size只是用来控制Redis中自动对AOF文件进行重写的情况，如果是技术人员手动调用“BGREWRITEAOF

      auto-aof-rewrite-percentage

      gibt an, ob die Größe der aktuellen AOF-Datei den Prozentsatz der AOF-Datei nach dem letzten Neuschreiben überschreitet. Danach wird mit dem Neuschreiben begonnen AOF-Datei erneut. Der Standardeinstellungswert dieses Parameterwerts ist beispielsweise 100, was bedeutet, dass der Neuschreibvorgang gestartet wird, wenn die Größe der AOF-Datei das 1-fache der Größe des letzten Neuschreibens der AOF-Datei überschreitet.

      auto-aof-rewrite-min-size

      : Das Einstellungselement gibt die Mindestgröße der AOF-Datei an, um den Vorgang zum Umschreiben der AOF-Datei zu starten. Wenn die AOF-Dateigröße unter diesem Wert liegt, wird der Neuschreibvorgang nicht ausgelöst. Beachten Sie, dass auto-aof-rewrite-percentage und auto-aof-rewrite-min-size nur zur Steuerung des automatischen Neuschreibens von AOF-Dateien in Redis verwendet werden, wenn ein Techniker den Befehl „BGREWRITEAOF“ manuell aufruft unterliegen diesen beiden Einschränkungen nicht. 3. Detailliertes Verständnis des AOF-Umschreibens
      AOF zeichnet jeden Schreibbefehl in der AOF-Datei auf. Mit der Zeit wird die AOF-Datei immer größer. Wenn es nicht kontrolliert wird, wirkt es sich auf den Redis-Server und sogar auf das Betriebssystem aus. Darüber hinaus ist die Datenwiederherstellung umso langsamer, je größer die AOF-Datei ist. Um das Problem der Erweiterung der AOF-Dateigröße zu lösen, bietet Redis einen Mechanismus zum Umschreiben von AOF-Dateien, um AOF-Dateien zu „verkleinern“.
      Illustration zur Erläuterung der AOF-Umschreibung
      

      Wird die AOF-Umschreibung blockiert?
      
      Der AOF-Umschreibprozess wird durch den Hintergrundprozess bgrewriteaof abgeschlossen. Der Hauptthread verzweigt sich im Hintergrund aus dem untergeordneten Prozess bgrewriteaof. Der Zweig kopiert den Speicher des Hauptthreads in den untergeordneten Prozess bgrewriteaof, der die neuesten Daten der Datenbank enthält. Anschließend kann der Unterprozess bgrewriteaof die kopierten Daten einzeln in Vorgänge schreiben und im Umschreibeprotokoll aufzeichnen, ohne den Hauptthread zu beeinträchtigen. Wenn aof neu geschrieben wird, blockiert es daher den Hauptthread, wenn der Prozess gegabelt wird.
      Wann wird das AOF-Protokoll neu geschrieben?

      Es gibt zwei Konfigurationselemente, um das Auslösen des AOF-Rewrites zu steuern: auto-aof-rewrite-min-size: Gibt die Mindestgröße der Datei an, wenn AOF-Rewrite ausgeführt wird. Der Standardwert ist 64 MB.
      

      Auto-Aof-Rewrite-Prozentsatz

      : Dieser Wert wird als Differenz zwischen der aktuellen AOF-Dateigröße und der AOF-Dateigröße nach dem letzten Umschreiben, geteilt durch die AOF-Dateigröße nach dem letzten Umschreiben, berechnet. Das heißt, die inkrementelle Größe der aktuellen AOF-Datei im Vergleich zur AOF-Datei nach dem letzten Umschreiben und das Verhältnis der AOF-Dateigröße nach dem letzten Umschreiben.

      Was passiert, wenn beim Umschreiben des Protokolls neue Daten geschrieben werden? Der Umschreibungsprozess lässt sich wie folgt zusammenfassen: „Eine Kopie, zwei Protokolle“. Wenn beim Verzweigen aus dem untergeordneten Prozess und beim Neuschreiben neue Daten geschrieben werden, zeichnet der Hauptthread den Befehl in zwei Protokollspeicherpuffern auf. Wenn die AOF-Rückschreibrichtlinie auf „Immer“ konfiguriert ist, wird der Befehl direkt in die alte Protokolldatei zurückgeschrieben und eine Kopie des Befehls im AOF-Rewrite-Puffer gespeichert. Diese Vorgänge haben keine Auswirkungen auf die neue Protokolldatei. (Alte Protokolldatei: die vom Hauptthread verwendete Protokolldatei, neue Protokolldatei: die vom bgrewriteaof-Prozess verwendete Protokolldatei)

      Nachdem der bgrewriteaof-Unterprozess den Umschreibvorgang der Protokolldatei abgeschlossen hat, wird er aufgefordert, den Hauptthread zu verwenden Wenn der Thread den Umschreibevorgang abgeschlossen hat, hängt der Hauptthread die Befehle im AOF-Umschreibepuffer an die Rückseite der neuen Protokolldatei an. Zu diesem Zeitpunkt kann die Ansammlung des AOF-Rewrite-Puffers bei hoher Parallelität sehr groß sein, was zu einer Blockierung führt. Später verwendete Redis die Linux-Pipeline-Technologie, um die gleichzeitige Wiedergabe während des AOF-Rewrites zu ermöglichen, sodass nach Abschluss des AOF-Rewrites Es muss nur noch eine kleine Menge der verbleibenden Daten wiedergegeben werden. Schließlich wird durch Ändern des Dateinamens die Atomizität des Dateiwechsels sichergestellt.
      • Wenn beim AOF-Neuschreiben des Protokolls eine Ausfallzeit auftritt, weil die Protokolldatei nicht gewechselt wurde, wird die alte Protokolldatei beim Wiederherstellen von Daten weiterhin verwendet.
      • Zusammenfassender Vorgang:

      Der Hauptthread verzweigt den untergeordneten Prozess, um das AOF-Protokoll neu zu schreiben

      Nachdem der untergeordnete Prozess das Protokoll neu geschrieben hat, hängt der Hauptthread den AOF-Protokollpuffer an

      Ersetzen Sie die Protokolldatei🎜 🎜🎜🎜Warme Erinnerung🎜 🎜🎜🎜Die Konzepte von Prozessen und Threads sind hier etwas verwirrend. Da im Hintergrundprozess bgreweiteaof nur ein Thread ausgeführt wird und der Hauptthread der Redis-Betriebsprozess ist, der ebenfalls ein einzelner Thread ist. Was ich hier zum Ausdruck bringen möchte, ist, dass die Vorgänge des Hintergrundprozesses keine Verbindung zum Hauptprozess haben und den Hauptthread nicht blockieren, nachdem der Redis-Hauptprozess einen Hintergrundprozess gegabelt hat🎜

      
      Wie teilt der Hauptthread den untergeordneten Prozess aus und kopiert die Speicherdaten?
      Fork nutzt den vom Betriebssystem bereitgestellten Copy-on-Write-Mechanismus, um zu vermeiden, dass eine große Menge an Speicherdaten auf einmal kopiert und der untergeordnete Prozess blockiert wird. Beim Forken eines untergeordneten Prozesses kopiert der untergeordnete Prozess die Seitentabelle des übergeordneten Prozesses, dh die virtuelle und reale Zuordnungsbeziehung (die Zuordnungsindextabelle zwischen virtuellem Speicher und physischem Speicher), jedoch nicht den physischen Speicher. Diese Kopie verbraucht viele CPU-Ressourcen und der Hauptthread wird blockiert, bevor die Kopie abgeschlossen ist. Die Blockierungszeit hängt von der Datenmenge im Speicher ab. Je größer die Datenmenge, desto größer die Speicherseitentabelle. Nach Abschluss des Kopiervorgangs verwenden der übergeordnete und der untergeordnete Prozess denselben Speicheradressraum.

      Aber der Hauptprozess kann Daten schreiben, und zu diesem Zeitpunkt werden die Daten im physischen Speicher kopiert. Wie unten gezeigt (Prozess 1 wird als Hauptprozess betrachtet, Prozess 2 wird als untergeordneter Prozess betrachtet):
      
      Wenn der Hauptprozess Daten geschrieben hat und diese Daten sich zufällig auf Seite c befinden, erstellt das Betriebssystem einen Kopie dieser Seite ( Eine Kopie von Seite c), dh die physischen Daten der aktuellen Seite werden kopiert und dem Hauptprozess zugeordnet, während der untergeordnete Prozess weiterhin die Originalseite c verwendet.

      Während des gesamten Prozesses des Umschreibens des Protokolls, wo wird der Hauptthread blockiert?

      • Beim Forken eines untergeordneten Prozesses muss die virtuelle Seitentabelle kopiert werden, wodurch der Hauptthread blockiert wird.
      • Wenn der Hauptprozess Bigkey schreibt, erstellt das Betriebssystem eine Kopie der Seite und kopiert die Originaldaten, wodurch der Hauptthread blockiert wird.
      • Nachdem das Umschreibeprotokoll des Unterprozesses abgeschlossen ist, kann der Hauptthread blockiert werden, wenn der Hauptprozess den AOF-Umschreibepuffer anhängt.

      Warum wird beim AOF-Umschreiben das ursprüngliche AOF-Protokoll nicht wiederverwendet?

      • Das Schreiben derselben Datei zwischen übergeordneten und untergeordneten Prozessen führt zu Wettbewerbsproblemen und beeinträchtigt die Leistung des übergeordneten Prozesses.
      • Wenn der AOF-Umschreibvorgang fehlschlägt, kommt dies einer Kontamination der ursprünglichen AOF-Datei gleich und kann nicht zur Datenwiederherstellung verwendet werden.

      3. RDB- und AOF-Hybridmethode (Version 4.0)

      Redis 4.0 schlägt eine Methode zur gemischten Verwendung von AOF-Protokollen und Speicher-Snapshots vor. Einfach ausgedrückt werden Speicher-Snapshots mit einer bestimmten Häufigkeit ausgeführt und zwischen zwei Snapshots werden AOF-Protokolle verwendet, um alle Befehlsvorgänge während dieses Zeitraums aufzuzeichnen.

      Auf diese Weise müssen Snapshots nicht sehr häufig ausgeführt werden, wodurch die Auswirkungen häufiger Verzweigungen auf den Hauptthread vermieden werden. Darüber hinaus zeichnet das AOF-Protokoll nur Vorgänge zwischen zwei Snapshots auf, was bedeutet, dass nicht alle Vorgänge aufgezeichnet werden müssen. Daher wird die Datei nicht zu groß und ein Überschreiben kann vermieden werden.

      Wie in der Abbildung unten gezeigt, werden die Änderungen bei T1 und T2 im AOF-Protokoll aufgezeichnet. Wenn der vollständige Schnappschuss zum zweiten Mal erstellt wird, kann das AOF-Protokoll gelöscht werden, da die Änderungen zu diesem Zeitpunkt aufgezeichnet wurden der Snapshot, und sie werden während der Wiederherstellung gelöscht. Keine Protokolle mehr.
      
      Diese Methode bietet nicht nur die Vorteile einer schnellen Wiederherstellung von RDB-Dateien, sondern auch den einfachen Vorteil, dass AOF nur Betriebsbefehle aufzeichnet. Sie wird in tatsächlichen Umgebungen häufig verwendet.

      4. Daten aus der Persistenz wiederherstellen

      Wie stellen wir Daten aus diesen persistenten Dateien wieder her, nachdem die Datensicherung und die Persistenz abgeschlossen sind? Wenn auf einem Server sowohl RDB-Dateien als auch AOF-Dateien vorhanden sind, welche sollten geladen werden?

      Tatsächlich müssen Sie Redis nur neu starten, wenn Sie Daten aus diesen Dateien wiederherstellen möchten. Wir verstehen diesen Prozess immer noch anhand des Diagramms:
      

      • Beim Neustart von Redis wird beurteilt, ob aof aktiviert ist, dann wird die aof-Datei zuerst geladen.
      • Wenn aof vorhanden ist, dann wird die aof-Datei aktiviert Wenn das Laden erfolgreich ist, wird Redis neu gestartet. Wenn das Laden fehlschlägt, wird ein Protokoll gedruckt, das anzeigt, dass der Start fehlgeschlagen ist Wenn die AOF-Datei nicht vorhanden ist, lädt Redis stattdessen die RDB-Datei. Wenn die RDB-Datei nicht vorhanden ist, wird sie geladen, um die Daten wiederherzustellen Wenn der Ladevorgang fehlschlägt, wird ein Protokoll gedruckt, das anzeigt, dass der Startvorgang erfolgreich war. Anschließend wird Redis erfolgreich neu gestartet und die RDB-Datei wird zum Wiederherstellen der Daten verwendet. Warum wird AOF zuerst geladen? Da die von AOF gespeicherten Daten vollständiger sind, wissen wir aus der obigen Analyse, dass AOF grundsätzlich bis zu 1 Sekunde an Daten verliert.
      • Empfohlenes Lernen:
      Redis-Video-Tutorial

Das obige ist der detaillierte Inhalt vonBeherrschen Sie die Redis-Persistenz vollständig: RDB und AOF. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!