Redis ist eine erweiterte Schlüsselwertdatenbank. Es ähnelt Memcached, die Daten können jedoch beibehalten werden und unterstützen eine Vielzahl von Datentypen. Es gibt Zeichenfolgen, verknüpfte Listen, Mengen und sortierte Mengen. Es unterstützt die Berechnung der Vereinigung, Schnittmenge und Ergänzung (Differenz) von Mengen auf der Serverseite und unterstützt außerdem eine Vielzahl von Sortierfunktionen.
Redis unterstützt zwei Persistenzmechanismen: RDB und AOF können Datenverluste durch abnormales Beenden oder Herunterfahren des Prozesses vermeiden. Die vorherige Persistenzdatei kann verwendet werden, um beim nächsten Neustart eine Datenwiederherstellung zu erreichen.
RDB-Persistenz ist eine Persistenzmethode, die vollständige Daten zu einem bestimmten Zeitpunkt speichert, indem sie einen komprimierten Binärdatei-Snapshot erstellt. RDB-Persistenz ist die Standardpersistenzmethode von Redis. Das Auslösen der RDB-Persistenz umfasst manuelles Auslösen und automatisches Auslösen.
Speichern, um eine RDB-Datei synchron zu erstellen. Dadurch wird der Hauptprozess des Servers blockiert Der Befehl bgsave in der Befehlszeile führt einen Fork durch. Ein Unterprozess erstellt eine RDB-Datei, um den Snapshot asynchron zu speichern. Mit Ausnahme der Blockierung während des Forks kann der Hauptprozess die Verarbeitung fortsetzen, wenn der Unterprozess die RDB-Datei erstellt Die Anforderung
Konfigurieren Sie „save m n“ in redis.conf so, dass es regelmäßig ausgelöst wird. Wenn beispielsweise mindestens eine Aktualisierung innerhalb von 900 Sekunden erfolgt, wird die Master-Slave-Replikation ausgelöst Beim vollständigen Replikationsvorgang führt der Masterknoten automatisch bgsave aus, um eine RDB-Datei zu generieren, und sendet sie an den Slave-Knoten. Er führt den Debug-Reload-Befehl aus und führt das Herunterfahren aus, wenn Redis neu geladen wird. Die RDB-Persistenzkonfiguration in redis.conf ist nicht vorhanden aktiviert
# 只要满足下列条件之一,则会执行bgsave命令save 900 1 # 在900s内存在至少一次写操作save 300 10 save 60 10000# 禁用RBD持久化,可在最后加 save ""# 当备份进程出错时主进程是否停止写入操作stop-writes-on-bgsave-error yes# 是否压缩rdb文件 推荐no 相对于硬盘成本cpu资源更贵rdbcompression no
Die AOF-Persistenz (Append-Only-File) zeichnet alle Anweisungen auf, die den Datenbankstatus ändern, und hängt sie in Form von Append Middle an die AOF-Datei an. Eine Möglichkeit, es umzuschreiben, ist: Wenn der Server neu gestartet wird, können Sie die in der AOF-Datei aufgezeichneten Befehle verwenden, um den Datenbankstatus wiederherzustellen, als er zuvor heruntergefahren wurde.
Die AOF-Persistenzkonfiguration in redis.conf lautet wie folgt
# 默认关闭AOF,若要开启将no改为yesappendonly no# append文件的名字appendfilename "appendonly.aof"# 每隔一秒将缓存区内容写入文件 默认开启的写入方式appendfsync everysec# 当AOF文件大小的增长率大于该配置项时自动开启重写(这里指超过原大小的100%)。auto-aof-rewrite-percentage 100# 当AOF文件大小大于该配置项时自动开启重写auto-aof-rewrite-min-size 64mb
Die Implementierung der AOF-Persistenz umfasst 3 Schritte:
Befehl anhängen: Befehl an die AOF-Pufferdatei anhängen schreiben: Pufferinhalt in die AOF-Datei schreiben Datei speichern : Die Häufigkeit der letzten beiden Schritte zum Speichern der AOF-Datei auf der Festplatte wird über appendfsync konfiguriert. Zu den Optionen von appendfsync gehört
always, wodurch die Datei bei jeder Ausführung eines Befehls gespeichert wird und nur die Daten verloren gehen von höchstens einem Befehl, aber auch die Leistung ist am geringsten (häufig) Disk IO) jede Sekunde, einmal pro Sekunde gespeichert, empfohlen, ein Kompromiss zwischen Sicherheit und Leistung, kein Datenverlust für höchstens eine Sekunde, abhängig vom Betriebssystem Für die Ausführung (im Allgemeinen etwa alle 30 Sekunden) ist die Sicherheit am niedrigsten, die Leistung ist am höchsten, und die Daten bleiben nach Ablauf der Zeit erhalten, nachdem das Betriebssystem den SAVE-Vorgang für die AOF-Datei ausgelöst hat Dadurch wird die AOF-Datei immer größer, indem Redis das Problem wachsender Probleme (die die Festplattenbelegung der Datei verringern und die Datenwiederherstellung beschleunigen können) wie folgt löst:
Rufen Sie fork auf, um einen untergeordneten Prozess zu erstellen
Der untergeordnete Prozess liest den Status der aktuellen Datenbank, um eine neue AOF-Datei „umzuschreiben“ (obwohl dies hier als „Umschreiben“ bezeichnet wird, wird die alte Datei eigentlich überhaupt nicht gelesen, sondern die Anweisungen werden basierend auf dem aktuellen Status der Datenbank gebildet)
Der Hauptprozess schreibt weiterhin neue Änderungen in den AOF-Rewrite-Puffer und den ursprünglichen AOF-Puffer
Der Hauptprozess erhält das Signal, dass der Unterprozess abgeschlossen ist Schreiben Sie die AOF neu, rufen Sie die Signalverarbeitungsfunktion auf, um den Inhalt des AOF-Neuschreibpuffers in die neue AOF-Datei zu schreiben, benennen Sie die neue Datei um, überschreiben Sie die ursprüngliche AOF-Datei atomar und schließen Sie den Austausch der alten und neuen Dateien ab
手动触发: 直接调用bgrewriteaof命令 自动触发: 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。其中auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积,默认为64MB。auto-aof-rewrite-percentage表示当前AOF文件大小(aof_current_size)和上一次重写后AOF文件大小(aof_base_size)的比值。自动触发时机为 aof_current_size > auto-aof-rewrite-min-size &&(aof_current_size - aof_base_size)/aof_base_size> = auto-aof-rewrite-percentage
RDB und AOF haben ihre eigenen Vor- und Nachteile.
Vorteile von RDB: Im Vergleich zu AOF sind RDB-Dateien relativ kleiner und die Datenwiederherstellung erfolgt schneller (Gründe finden Sie im Abschnitt zur Datenwiederherstellung). Nachteile von RDB: Wenn der Server ausfällt, verliert die RBD-Methode die Daten nach der letzten RDB Persistenz; Speicher wird verbraucht, wenn bgsave zum Verzweigen untergeordneter Prozesse verwendet wird. Vorteile von AOF: AOF hängt nur Dateien an, hat weniger Auswirkungen auf die Serverleistung, ist schneller als RDB, verbraucht weniger Speicher und ist gut lesbar. Die Verwendung von AOF bringt zwei Nachteile mit sich: Die generierte Datei ist relativ groß, selbst wenn sie von AOF neu geschrieben wird, ist sie gleichzeitig immer noch relativ groß, und die Geschwindigkeit der Datenwiederherstellung ist auch langsamer als bei RDB. Datenbankwiederherstellung
Wenn die AOF-Persistenzfunktion nicht aktiviert ist, wird beim Serverstart der Hauptprozess blockiert, während die RDB-Datei automatisch geladen wird. Wenn die AOF-Persistenzfunktion aktiviert ist, gibt der Server der Verwendung von AOF-Dateien zur Wiederherstellung des Datenbankstatus Vorrang, da die Aktualisierungshäufigkeit von AOF-Dateien normalerweise höher ist als die von RDB-Dateien und die gespeicherten Daten vollständiger sind.
Der Verarbeitungsablauf der Redis-Datenbankwiederherstellung ist wie folgt:
In Bezug auf die Datenwiederherstellung wird die Startzeit von RDB aus zwei Gründen kürzer sein:
In der RDB-Datei gibt es nur einen Datensatz für jedes Datenelement. Im Gegensatz zum AOF-Protokoll können für ein Datenelement mehrere Vorgangsdatensätze vorhanden sein. Daher muss jedes Datenelement nur einmal geschrieben werden und die Datei ist relativ klein.
RDB 文件的存储格式和Redis数据在内存中的编码格式是一致的,不需要再进行数据编码工作,所以在CPU消耗上要远小于AOF日志的加载。
但是在进行RDB持久化时,fork出来进行dump操作的子进程会占用与父进程一样的内存,采用的copy-on-write机制,对性能的影响和内存的消耗都是比较大的。比如16G内存,Redis已经使用了10G,这时save的话会再生成10G,变成20G,大于系统的16G。这时候会发生交换,要是虚拟内存不够则会崩溃,导致数据丢失。所以在用redis的时候一定对系统内存做好容量规划。
RDB、AOF混合持久化
Redis从4.0版开始支持RDB与AOF的混合持久化方案。首先由RDB定期完成内存快照的备份,然后再由AOF完成两次RDB之间的数据备份,由这两部分共同构成持久化文件。这个方案的优势在于其充分利用了RDB加载速度快、备份体积小以及AOF记录数据丢失几率尽可能低的特点。缺点是兼容性差,一旦开启了混合持久化,在4.0之前的版本都不识别该持久化文件,同时由于前部分是RDB格式,阅读性较低。
开启混合持久化
aof-use-rdb-preamble yes
数据恢复加载过程就是先按照RDB进行加载,然后把AOF命令追加写入。
持久化方案的建议 如果Redis只是用来做缓存服务器,比如数据库查询数据后缓存,那可以不用考虑持久化,因为缓存服务失效还能再从数据库获取恢复。建议同时采用两种持久化方式,以提高数据的安全性。如果你可以容忍在灾难发生时数据丢失几分钟,那么可以仅使用RDB。一般的设计方法是 使用主从复制机制以解决持久化时所带来的性能影响。即Master上RDB、AOF都不做,保证Master的读写性能,而Slave上则同时开启RDB和AOF(或4.0以上版本的混合持久化方式)来进行持久化,保证数据的安全性。
Das obige ist der detaillierte Inhalt vonSo implementieren Sie die Redis-Persistenz. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!