Une brève analyse de la persistance RDB et AOF, quels sont les avantages et les inconvénients ? Comment choisir ?-Redis-php.cn

Cet article vous parlera des principes de persistance RDB et AOF dans redis Quels sont leurs avantages et inconvénients ? Analyser lequel faut-il utiliser ? J'espère que cela aidera tout le monde !

Une brève analyse de la persistance RDB et AOF, quels sont les avantages et les inconvénients ? Comment choisir ?

Redis propose deux solutions de persistance : RDB et AOF :

RDB : génère un instantané des données dans la mémoire Redis dans un intervalle de temps spécifié, qui est un fichier binaire dumpr.rdb
AOF : record Redis écrit toutes les commandes à l'exception des requêtes et restaure les données en réexécutant ces commandes au démarrage du service Redis.

Persistance RDB

Par défaut, Redis conservera les données pendant un certain temps sur le disque dur sous la forme d'instantanés RDB et les enregistrera en tant que fichier binaire dumpr.rdb. [Recommandations associées : dumpr.rdb 二进制文件。【相关推荐：Redis视频教程】

工作原理简单介绍一下：

当 Redis 需要做持久化时，Redis 会 fork 一个子进程，子进程将数据写到磁盘上一个临时 RDB 文件中。当子进程完成写临时文件后，将原来的 RDB 替换掉，这样的好处就是可以 copy-on-write。

当然我们也可以手动执行 save 或者 bgsave（异步）生成 RDB 文件。

redis.conf 默认配置

save 900  1
save 300  10
save 60  10000

Copier après la connexion

900秒之内，如果超过1个key被修改，则发起快照保存；
300秒之内，如果超过10个key被修改，则发起快照保存；
60秒之内，如果1万个key被修改，则发起快照保存；

RDB 快照命令

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。

你可以对 Redis 进行设置，让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时，自动保存一次数据集。

你也可以通过调用 SAVE 或者 BGSAVE ，手动让 Redis 进行数据集保存操作。

比如说，以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时，自动保存一次数据集：

save 60 1000

Copier après la connexion

这种持久化方式被称为快照（snapshot）。

RDB 创建原理

当 Redis 需要保存 dump.rdb 文件时，服务器执行以下操作：

Redis 调用 fork() ，同时拥有父进程和子进程。
子进程将数据集写入到一个临时 RDB 文件中。
当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。

RDB 的优点

RDB 是一个比较紧凑的文件，它保存了 Redis 在某个时间点的数据，这种数据比较适合做备份和用于灾难恢复。

比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

RDB 的缺点

如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。虽然 Redis 允许你设置不同的保存点来控制保存 RDB 文件的频率，但是，因为 RDB 文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。因此你可能会至少 5 分钟才保存一次 RDB 文件。在这种情况下，一旦发生故障停机，你就可能会丢失好几分钟的数据。

AOF 持久化

使用 AOF 做持久化，每一个写命令都通过 write 函数追加到 appendonly.aof 文件中。

AOF 就可以做到全程持久化，只需要在配置文件中开启（默认是 no ），appendfsync yesTutoriel vidéo Redis

]

Une brève introduction au principe de fonctionnement :

Lorsque Redis doit être persistant, Redis créera un processus enfant et le processus enfant écrira les données dans un RDB temporaire. fichier sur le disque. Lorsque le processus enfant a fini d'écrire le fichier temporaire, remplacez le RDB d'origine. L'avantage est qu'il peut copier en écriture.

Bien sûr, nous pouvons également exécuter manuellement save ou bgsave (de manière asynchrone) pour générer des fichiers RDB.

Configuration par défaut de redis.conf

appendfsync yes
appendfsync always     #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec   #每秒钟同步一次，该策略为AOF的缺省策略。

Copier après la connexion

SAVE

BGSAVE

appendonly.aof

write

appendfsync yes

1. Exécutez fsync chaque fois qu'une nouvelle commande est ajoutée au fichier AOF : très lent et très sûr.
2, fsync une fois par seconde : assez rapide (à peu près la même chose que l'utilisation de la persistance RDB), et ne perd qu'1 seconde de données en cas de panne.
3, Jamais fsync : laissez les données au système d'exploitation pour traitement. Option plus rapide et moins sécurisée.

La mesure recommandée (et par défaut) est de fsync une fois par seconde. Cette stratégie fsync peut équilibrer vitesse et sécurité.

Principe de création AOF

La réécriture AOF est la même que la création d'instantanés RDB, qui utilisent toutes deux intelligemment le mécanisme de copie sur écriture.

Voici les étapes d'exécution de la réécriture AOF :

Redis exécute fork() et dispose désormais de processus parent et enfant.

Le processus enfant commence à écrire le contenu du nouveau fichier AOF dans le fichier temporaire.

Pour toutes les commandes d'écriture nouvellement exécutées, le processus parent les accumule dans un cache mémoire et ajoute ces modifications à la fin du fichier AOF existant : De cette façon, même si un arrêt se produit au milieu de la réécriture, l'AOF existant Les fichiers sont toujours en sécurité.

Lorsque le processus enfant termine le travail de réécriture, il envoie un signal au processus parent. Après avoir reçu le signal, le processus parent ajoute toutes les données du cache mémoire à la fin du nouveau fichier AOF.

Fait ! Redis remplace désormais atomiquement l'ancien fichier par le nouveau, et toutes les commandes suivantes sont ajoutées directement à la fin du nouveau fichier AOF.

Avantages d'AOF

1. En utilisant AOF pour la persistance, vous pouvez définir différentes stratégies fsync, telles que pas de fsync, fsync une fois par seconde ou fsync à chaque fois qu'une commande d'écriture est exécutée.

La politique par défaut d'AOF est de fsync une fois par seconde. Dans cette configuration, Redis peut toujours maintenir de bonnes performances, et même en cas de panne, une seule seconde de données sera perdue au maximum.

fsync sera exécuté sur un thread d'arrière-plan, afin que le thread principal puisse continuer à travailler dur pour traiter les demandes de commandes.

2. Le fichier AOF est un fichier journal qui effectue uniquement des opérations d'ajout. Ce n'est pas un fichier journal qui est remplacé après en avoir généré un nouveau, même si le journal contient des commandes incomplètes pour certaines raisons (par exemple, le disque est plein). lors de l'écriture, l'outil redis-check-aof peut également facilement résoudre ce problème.

3. Redis peut réécrire automatiquement l'AOF en arrière-plan lorsque la taille du fichier AOF devient trop grande : le nouveau fichier AOF après réécriture contient l'ensemble minimum de commandes requis pour restaurer l'ensemble de données actuel.

L'ensemble de l'opération de réécriture est absolument sûr, car la réécriture Redis crée un nouveau fichier AOF Pendant le processus de réécriture, les commandes continueront à être ajoutées à l'ancien fichier AOF existant, même en cas d'arrêt pendant le processus de réécriture. Les anciens fichiers AOF ne seront pas non plus perdus. Une fois le nouveau fichier AOF créé, Redis passera de l'ancien fichier AOF au nouveau fichier AOF et commencera à l'ajouter au nouveau fichier AOF.

4. Le fichier AOF enregistre toutes les opérations d'écriture effectuées sur la base de données de manière ordonnée. Ces opérations d'écriture sont enregistrées au format du protocole Redis, le contenu du fichier AOF est donc très facile à lire et à analyser ( analyser). C'est aussi très relaxant. L'exportation (exportation) de fichiers AOF est également très simple : par exemple, si vous exécutez accidentellement la commande _FLUSH ALL_ (effacer les données de l'intégralité du serveur Redis (supprimer toutes les clés de toutes les bases de données).), mais tant que le fichier AOF a n'a pas été écrasé, alors tant que vous arrêtez le serveur, supprimez la commande FLUSHALL à la fin du fichier AOF et redémarrez Redis, vous pouvez restaurer l'ensemble de données à l'état avant l'exécution de FLUSHALL.

Inconvénients de l'AOF

Pour le même ensemble de données, la taille des fichiers AOF est généralement plus grande que celle des fichiers RDB.

Selon la stratégie fsync utilisée, AOF peut être plus lent que RDB. Dans des circonstances normales, les performances de fsync par seconde sont toujours très élevées, et la désactivation de fsync peut rendre AOF aussi rapide que RDB, même sous une charge importante.

Cependant, lors de la gestion d'énormes charges d'écriture, RDB peut fournir une latence maximale plus garantie.

La différence entre RDB et AOF

La persistance RDB fait référence à l'écriture d'un instantané de l'ensemble de données en mémoire sur le disque dans un intervalle de temps spécifié. Le processus opérationnel réel consiste à créer un processus enfant et à écrire d'abord l'ensemble de données après. le fichier temporaire est écrit avec succès, le fichier précédent est remplacé et stocké par compression binaire.

La persistance AOF enregistre chaque opération d'écriture et de suppression traitée par le serveur sous la forme d'un journal. Les opérations de requête ne seront pas enregistrées. Les enregistrements sont ajoutés sous forme de texte. Vous pouvez ouvrir le fichier pour voir les enregistrements détaillés des opérations.

RDB ou AOF, lequel dois-je utiliser ?

Si vous vous souciez beaucoup de vos données mais que vous pouvez toujours vous permettre une perte de données en quelques minutes, vous pouvez simplement utiliser la persistance RDB.

AOF ajoute chaque commande exécutée par Redis au disque. Le traitement d'écritures volumineuses réduira les performances de Redis. Je ne sais pas si vous pouvez l'accepter.

Sauvegarde de base de données et récupération après sinistre :

La génération régulière d'instantanés RDB est très pratique pour la sauvegarde de bases de données, et RDB restaure les ensembles de données plus rapidement qu'AOF.

Redis prend en charge l'ouverture de RDB et AOF en même temps. Après le redémarrage du système, Redis donnera la priorité à l'utilisation d'AOF pour récupérer les données, afin que les données perdues soient minimes.

Réécriture AOF BGREWRITEAOF

Parce qu'AOF fonctionne en ajoutant continuellement des commandes à la fin du fichier, de sorte qu'à mesure que le nombre de commandes d'écriture continue d'augmenter, la taille du fichier AOF deviendra de plus en plus grande.

Par exemple

Si vous appelez INCR 100 fois sur un compteur, alors juste pour enregistrer la valeur actuelle du compteur, le fichier AOF doit utiliser 100 enregistrements (entrée).

Cependant, en fait, l'utilisation d'une seule commande SET suffit pour enregistrer la valeur actuelle du compteur, et les 99 enregistrements restants sont en fait redondants.

Afin de gérer cette situation, Redis prend en charge une fonctionnalité intéressante : les fichiers AOF peuvent être reconstruits sans interrompre le service client.

Exécutez la commande BG REWRITE AOF, Redis générera un nouveau fichier AOF, qui contient les commandes minimales requises pour reconstruire l'ensemble de données actuel. BG REWRITE AOF 命令， Redis 将生成一个新的 AOF 文件，这个文件包含重建当前数据集所需的最少命令。

Redis 2.2 需要自己手动执行 BGREWRITEAOF

BGREWRITEAOF