Lassen Sie uns über den Persistenzmechanismus von Redis sprechen. Sollten wir RDB oder AOF verwenden?

In diesem Artikel werden Sie den Persistenzmechanismus von Redis (RDB und AOF) verstehen und darüber sprechen, ob RDB oder AOF verwendet werden soll. Hoffe, es hilft allen!

RDB

1. Was ist RDB?

RDB: Von Zeit zu Zeit werden die Daten im Speicher als Snapshot in eine temporäre Datei auf der Festplatte geschrieben und die Snapshot-Datei wird eingelesen den Speicher während der Wiederherstellung. Wenn es abstürzt und neu startet, sind die Daten im Speicher definitiv verschwunden. Nach dem erneuten Starten von Redis werden sie wiederhergestellt. [Verwandte Empfehlungen: Redis-Video-Tutorial

Speichersicherung --> Temporäre Dateien --> RDB-Vorteile und -Nachteile

Vorteile

Ab und zu eine vollständige Sicherung durchführen

Einfache Notfallwiederherstellung, kann aus der Ferne übertragen werden

• • Wenn der untergeordnete Prozess gesichert wird, hat der Hauptprozess keine Io-Vorgänge (Es werden keine Schreibänderungen vorgenommen) oder gelöscht), um die Integrität der Sicherungsdaten sicherzustellen.

  • Im Vergleich zu AOF können Sie größere Dateien schnell neu starten und wiederherstellen Im Falle eines Fehlers kann die letzte Datei verloren gehen. Die Sicherungsdaten Da es sich um einen aufwändigen Vorgang handelt, kann die Echtzeitsicherung nicht verarbeitet werden.

  • 4.

    save 900 1
    save 300 10
    save 60 10000
    save 10 3

    * 如果1个缓存更新，则15分钟后备份
    * 如果10个缓存更新，则5分钟后备份
    * 如果10000个缓存更新，则1分钟后备份

  stop-writes-on-bgsave-error
• ja: Wenn beim Speichervorgang ein Fehler auftritt, stoppen Sie den Schreibvorgang
  • nein: Kann zu Dateninkonsistenzen führen

  • rdbcompression

  • ja: Aktivieren Sie den RDB-Komprimierungsmodus
    Nein: Schließen, es spart CPU-Verbrauch, aber die Datei wird groß sein, derselbe Grund wie bei Nginx

rdbchecksum

Ja: Verwenden Sie die CRC64-Algorithmusüberprüfung, um die Datenüberprüfung für RDB durchzuführen , mit 10 % Leistungsverlust

• nein: Keine Verifizierung

  
  

• Zusammenfassung

RDB ist für die Wiederherstellung großer Datenmengen geeignet, die Integrität und Konsistenz der Daten kann jedoch unzureichend sein.

• AOF
  AOF-Funktionen
  zeichnet von Benutzern angeforderte Schreibvorgänge in Form von Protokollen auf. Lesevorgänge werden nicht protokolliert, da nur Schreibvorgänge gespeichert werden.

• Die Datei wird angehängt und nicht geändert.
  • Redis' Aof-Recovery bedeutet eigentlich, die angehängte Datei vom Anfang bis zum Ende zu lesen und zu schreiben.

• Vorteile

  • AOF ist langlebiger und kann in Sekundenschnelle gesichert werden. Wenn ein Problem auftritt, geht nur die letzte Sekunde der Daten verloren, was die Zuverlässigkeit und Datenintegrität erheblich erhöht. Daher kann AOF mithilfe des Fsync-Vorgangs einmal pro Sekunde gesichert werden.

In Form eines Protokollprotokolls anhängen. Wenn die Festplatte voll ist, wird das Redis-Check-Aof-Tool ausgeführt.

Wenn die Daten zu groß sind, kann Redis das AOF automatisch im Hintergrund neu schreiben. Wenn Redis weiterhin Protokolle an alte Dateien anhängt, ist das Umschreiben ebenfalls sehr sicher und hat keine Auswirkungen auf die Lese- und Schreibvorgänge des Clients.

Alle im AOF-Protokoll enthaltenen Schreibvorgänge erleichtern das Parsen und Wiederherstellen von Redis.

Nachteile
• Die gleichen Daten, die gleichen Daten, AOF ist größer als RDB

• Bei verschiedenen Synchronisationsmechanismen ist AOF langsamer als RDB, da AOF jede Sekunde zum Schreiben gesichert wird Operationen, daher ist es etwas niedriger als RDB. Es ist nichts Falsches daran, fsync jede Sekunde zu sichern, aber wenn der Client jedes Mal, wenn er schreibt, ein Backup von fsync durchführt, verringert sich die Leistung von Redis.

AOF weist Fehler auf, das heißt, die Daten sind während der Datenwiederherstellung unvollständig. Dies macht AOF fragiler und anfälliger für Fehler, da AOF nicht so einfach ist wie RDB, aber um Fehler zu verhindern, wird AOF nicht so einfach sein Basierend auf dem alten Anstatt die Anweisungen basierend auf den zu diesem Zeitpunkt im Cache vorhandenen Datenanweisungen zu rekonstruieren, ist es robuster und zuverlässiger.

AOF-Konfiguration

• `# AOF 默认关闭，yes可以开启
  appendonly no
  
  # AOF 的文件名
  appendfilename "appendonly.aof"
  
  # no：不同步
  # everysec：每秒备份，推荐使用
  # always：每次操作都会备份，安全并且数据完整，但是慢性能差
  appendfsync everysec
  
  # 重写的时候是否要同步，no可以保证数据安全
  no-appendfsync-on-rewrite no
  
  # 重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时旧的aof文件不会被读取使用，类似rdb
  # 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
  auto-aof-rewrite-percentage 100
  auto-aof-rewrite-min-size 64mb`

Sollten wir RDB oder AOF verwenden?
• Wenn Sie einen Cache-Verlust für einen bestimmten Zeitraum akzeptieren können, können Sie RDB verwenden.

• Wenn Sie bei Echtzeitdaten vorsichtiger sind, verwenden Sie AOF

• Verwenden Sie RDB und AOF zusammen für die Persistenz. RDB wird als Kaltsicherung verwendet, die verschiedene Versionen zu unterschiedlichen Zeiten wiederherstellen kann, und AOF wird als Heißsicherung verwendet, um sicherzustellen, dass die Daten nur für 1 Sekunde verloren gehen. Wenn das AOF beschädigt und nicht verfügbar ist, verwenden Sie RDB, um es wiederherzustellen, sodass beides kombiniert wird. Das heißt, die Redis-Wiederherstellung lädt zuerst AOF, und wenn ein Problem mit AOF vorliegt, wird RDB erneut geladen Erreichung des Zwecks der Warm- und Kaltsicherung.

Weitere Kenntnisse zum Thema Programmierung finden Sie unter: Einführung in die Programmierung! !

Das obige ist der detaillierte Inhalt vonLassen Sie uns über den Persistenzmechanismus von Redis sprechen. Sollten wir RDB oder AOF verwenden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!