Maison > base de données > Redis > Comment implémenter la persistance Redis

Comment implémenter la persistance Redis

WBOY
Libérer: 2023-05-30 09:14:45
avant
754 Les gens l'ont consulté

Redis est une base de données clé-valeur avancée. Il est similaire à Memcached, mais les données peuvent être conservées et prennent en charge un large éventail de types de données. Il existe des chaînes, des listes chaînées, des ensembles et des ensembles triés. Il prend en charge le calcul de l'union, de l'intersection et du complément (différence) des ensembles côté serveur, et prend également en charge diverses fonctions de tri.

Comment implémenter la persistance Redis

Redis prend en charge deux mécanismes de persistance : RDB et AOF. La persistance peut éviter la perte de données causée par une sortie ou un arrêt anormal du processus. Le fichier de persistance précédent peut être utilisé pour récupérer les données au prochain redémarrage.

Persistance RDB

La persistance RDB est une méthode de persistance qui enregistre des données complètes à un moment précis en créant un instantané de fichier binaire compressé. La persistance RDB est la méthode de persistance par défaut de Redis. Le déclenchement de la persistance RDB comprend le déclenchement manuel et le déclenchement automatique.

Déclenchez manuellement

save, exécutez la commande save sur la ligne de commande et le fichier rdb sera créé de manière synchrone pour enregistrer l'instantané, ce qui bloquera le processus principal du serveur. N'utilisez pas bgsave en production. L'exécution de la commande bgsave sur la ligne de commande entraînera un fork. Un sous-processus crée un fichier rdb de manière asynchrone pour enregistrer l'instantané. Sauf en cas de blocage pendant le fork, lorsque le sous-processus crée le fichier rdb, le processus principal peut continuer. pour traiter la demande

Déclencher automatiquement

Configurez save m n dans redis.conf pour qu'il se déclenche régulièrement. Par exemple, save 900 1 signifie que lorsqu'il y a au moins une mise à jour dans les 900 secondes, la réplication maître-esclave est déclenchée si le nœud esclave. effectue une opération de réplication complète, le nœud maître exécute automatiquement bgsave pour générer un fichier RDB et l'envoie au nœud esclave. Il exécute la commande debug reload et exécute l'arrêt lors du rechargement de Redis et la configuration de persistance RDB dans redis.conf de persistance AOF. n'est pas activé

# 只要满足下列条件之一,则会执行bgsave命令save 900 1 # 在900s内存在至少一次写操作save 300 10
save 60 10000# 禁用RBD持久化,可在最后加 save ""# 当备份进程出错时主进程是否停止写入操作stop-writes-on-bgsave-error yes# 是否压缩rdb文件 推荐no 相对于硬盘成本cpu资源更贵rdbcompression no
Copier après la connexion

Persistance AOF

La persistance AOF (Append-Only-File) enregistre toutes les instructions qui modifient l'état de la base de données et les ajoute au fichier AOF sous la forme d'un milieu d'ajout. Une façon de le réécrire est : Lorsque le serveur est redémarré, vous pouvez utiliser les commandes enregistrées dans le fichier AOF pour restaurer l'état de la base de données lors de son arrêt précédent.

La configuration de la persistance AOF dans redis.conf est la suivante

# 默认关闭AOF,若要开启将no改为yesappendonly no# append文件的名字appendfilename "appendonly.aof"# 每隔一秒将缓存区内容写入文件 默认开启的写入方式appendfsync everysec# 当AOF文件大小的增长率大于该配置项时自动开启重写(这里指超过原大小的100%)。auto-aof-rewrite-percentage 100# 当AOF文件大小大于该配置项时自动开启重写auto-aof-rewrite-min-size 64mb
Copier après la connexion

L'implémentation de la persistance AOF comprend 3 étapes :

Command append : ajouter la commande au fichier tampon AOF write : écrire le contenu du tampon dans le fichier AOF file save : La fréquence des deux dernières étapes de sauvegarde du fichier AOF sur le disque est configurée via appendfsync. Les options de appendfsync incluent

always, qui enregistre le fichier à chaque fois qu'une commande est exécutée. Elle a la plus haute sécurité et ne perd que les données. d'une commande au maximum, mais les performances sont également les plus faibles (E/S disque fréquentes) toutes les secondes, enregistrées une fois par seconde, recommandées, un compromis entre sécurité et performances, aucune perte de données pendant une seconde au maximum, dépend du système d'exploitation pour l'exécution (généralement environ une fois toutes les 30 secondes), la sécurité la plus faible, les performances les plus élevées et la perte des données après la dernière fois que le système d'exploitation a déclenché l'opération SAVE sur le fichier AOF est conservée via la commande de sauvegarde au fil du temps. par, le fichier AOF deviendra de plus en plus gros. Redis résout le fichier AOF en réécrivant le fichier AOF. Le problème des problèmes croissants (ce qui peut réduire l'occupation du disque du fichier et accélérer la récupération des données), le principe est le suivant :

Call fork pour créer un processus enfant

Le processus enfant lit l'état de la base de données actuelle pour en "réécrire" un nouveau. Fichier AOF (bien que cela soit appelé ici "réécriture", l'ancien fichier n'est pas du tout lu, mais le les instructions sont formées en fonction de l'état actuel de la base de données)

Le processus principal continue d'écrire de nouvelles modifications dans la réécriture AOF en même temps Tampon et tampon AOF d'origine

Le processus principal reçoit le signal indiquant que le sous-processus est terminé réécrire l'AOF, appelle la fonction de traitement du signal pour écrire le contenu du tampon de réécriture AOF dans le nouveau fichier AOF, et renomme le nouveau fichier, écrase atomiquement le fichier AOF d'origine et termine le remplacement des anciens et des nouveaux fichiers

Réécriture AOF. est également divisé en déclenchement manuel et déclenchement automatique
手动触发: 直接调用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
Copier après la connexion
RDB vs AOF

RDB et AOF ont leurs propres avantages et inconvénients.

Avantages de RDB : Par rapport à AOF, les fichiers RDB sont relativement plus petits et la récupération des données est plus rapide (voir la section récupération de données pour les raisons) Inconvénients de RDB : Lorsque le serveur est en panne, la méthode RBD perdra les données après le dernier RDB persistance ; la mémoire est consommée lors de l'utilisation de bgsave pour créer des processus enfants. Avantages d'AOF : AOF ajoute uniquement des fichiers, a moins d'impact sur les performances du serveur, est plus rapide que RDB, consomme moins de mémoire et offre une lisibilité élevée. L'utilisation d'AOF entraînera deux inconvénients : le fichier généré est relativement volumineux, même s'il est réécrit par AOF, il sera toujours relativement volumineux en même temps, la vitesse de récupération des données est également plus lente que RDB ; Récupération de base de données

Si la fonction de persistance AOF n'est pas activée, au démarrage du serveur, le processus principal sera bloqué pendant que le fichier RDB est automatiquement chargé. Si la fonction de persistance AOF est activée, le serveur donnera la priorité à l'utilisation des fichiers AOF pour restaurer l'état de la base de données, car la fréquence de mise à jour des fichiers AOF est généralement supérieure à celle des fichiers RDB et les données enregistrées sont plus complètes.

Le flux de traitement de la récupération de la base de données Redis est le suivant :

En termes de récupération de données, le temps de démarrage de RDB sera plus court pour deux raisons :

Dans le fichier RDB, il n'y a qu'un seul enregistrement pour chaque élément de données, contrairement au journal AOF, il peut y avoir plusieurs enregistrements d'opérations pour un élément de données. Ainsi, chaque élément de données ne doit être écrit qu’une seule fois et le fichier est relativement petit.

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
Copier après la connexion

数据恢复加载过程就是先按照RDB进行加载,然后把AOF命令追加写入。

持久化方案的建议 如果Redis只是用来做缓存服务器,比如数据库查询数据后缓存,那可以不用考虑持久化,因为缓存服务失效还能再从数据库获取恢复。建议同时采用两种持久化方式,以提高数据的安全性。如果你可以容忍在灾难发生时数据丢失几分钟,那么可以仅使用RDB。一般的设计方法是 使用主从复制机制以解决持久化时所带来的性能影响。即Master上RDB、AOF都不做,保证Master的读写性能,而Slave上则同时开启RDB和AOF(或4.0以上版本的混合持久化方式)来进行持久化,保证数据的安全性。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Étiquettes associées:
source:yisu.com
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal