Parlons du mécanisme de persistance de Redis. Faut-il utiliser RDB ou AOF ?

Cet article vous amènera à comprendre le mécanisme de persistance de Redis (RDB et AOF), et à discuter de l'opportunité d'utiliser RDB ou AOF ? J'espère que cela aidera tout le monde !

RDB

1. Qu'est-ce que RDB

RDB : De temps en temps, les données en mémoire sont écrites dans un fichier temporaire sur le disque sous forme d'instantané, et le fichier d'instantané est lu dans la mémoire pendant la récupération. S'il plante et redémarre, les données de la mémoire disparaîtront définitivement. Elles seront ensuite restaurées après le redémarrage de Redis. [Recommandations associées : Tutoriel vidéo Redis]

2. Sauvegarde et récupération

Sauvegarde de la mémoire--> Fichiers temporaires du disque
Restauration en mémoire

3.

Avantages
• • Sauvegarde de temps en temps, sauvegarde complète

  • Reprise après sinistre simple, peut être transmise à distance

  • Lorsque le processus enfant est sauvegardé, le processus principal n'aura aucune opération io (il n'y aura pas de modifications en écriture) ou suppression) pour garantir l'intégrité des données de sauvegarde

  • Par rapport à AOF, lorsqu'il y a des fichiers plus volumineux, vous pouvez rapidement les redémarrer et les restaurer

Inconvénients
• • Dans en cas d'échec, le dernier fichier peut être perdu. Les données de sauvegarde

  • La mémoire occupée par le processus enfant sera exactement la même que celle du processus parent, ce qui entraînera une charge CPU

  • Puisque la sauvegarde complète planifiée est une opération lourde, la sauvegarde en temps réel ne peut pas être traitée.

4. Configuration RDB

• L'emplacement de sauvegarde peut être personnalisé dans redis.conf :

  /user/local/redis/working/dump.rdb
  

• Mécanisme de sauvegarde :

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

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

• stop-writes-on-bgsave-error
  oui : si une erreur se produit dans le processus de sauvegarde, arrêtez l'opération d'écriture
  • non : peut provoquer une incohérence des données
• rdbcompression
  oui : Activez le mode de compression rdb
  • non : fermez, cela économisera la consommation du processeur, mais le fichier sera volumineux, pour la même raison que nginx
• rdbchecksum
  oui : utilisez la vérification de l'algorithme CRC64 pour effectuer la vérification des données sur rdb , avec une perte de performances de 10 %
  • non : Aucune vérification

Résumé

RDB convient à la récupération de grandes quantités de données, mais l'intégrité et la cohérence des données peuvent être insuffisantes.

AOF

Fonctionnalités AOF

• enregistre les opérations d'écriture demandées par les utilisateurs sous forme de journaux. Les opérations de lecture ne sont pas enregistrées, car seules les opérations d'écriture sont stockées.

• Le fichier est ajouté plutôt que modifié.

• La récupération de Redis signifie en fait lire et écrire le fichier ajouté du début à la fin.

Avantages

• AOF est plus durable et peut être sauvegardé en quelques secondes si un problème survient, seule la dernière seconde des données sera perdue, ce qui augmente considérablement la fiabilité et l'intégrité des données. Ainsi, AOF peut être sauvegardé une fois par seconde, en utilisant l'opération fsync.

• Ajouter sous forme de journal de bord. Si le disque est plein, l'outil redis-check-aof sera exécuté

• Lorsque les données sont trop volumineuses, redis peut automatiquement réécrire l'aof en arrière-plan. Lorsque Redis continue d'ajouter des journaux aux anciens fichiers, la réécriture est également très sûre et n'affectera pas les opérations de lecture et d'écriture du client.

• Toutes les opérations d'écriture incluses dans le journal AOF faciliteront l'analyse et la récupération de Redis.

Inconvénients

• Les mêmes données, les mêmes données, AOF est plus grand que RDB

• Pour différents mécanismes de synchronisation, AOF sera plus lent que RDB, car AOF sera sauvegardé chaque seconde pour l'écriture opérations, il est donc légèrement inférieur à RDB. Il n'y a rien de mal à sauvegarder fsync chaque seconde, mais si le client effectue une sauvegarde fsync à chaque fois qu'il écrit, les performances de Redis diminueront.

• AOF a eu des bugs, c'est-à-dire que les données sont incomplètes lors de la récupération des données. Cela rend AOF plus fragile et sujet aux bugs, car AOF n'est pas aussi simple que RDB, mais afin d'éviter les bugs, AOF ne le sera pas. basé sur l'ancien Au lieu de reconstruire les instructions selon les instructions de données existant dans le cache à ce moment-là, il est plus robuste et fiable.

Configuration AOF

`# 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`

Faut-il utiliser RDB ou AOF ?

• Si vous pouvez accepter la perte de cache pendant un certain temps, vous pouvez utiliser RDB

• Si vous faites plus attention aux données en temps réel, utilisez AOF

• Utilisez RDB et AOF ensemble pour la persistance. RDB est utilisé comme sauvegarde à froid, qui peut restaurer différentes versions à différents moments, et AOF est utilisé comme sauvegarde à chaud, garantissant que les données ne sont perdues que pendant 1 seconde. Lorsque l'AOF est endommagé et indisponible, utilisez RDB pour le restaurer, afin que les deux soient combinés, c'est-à-dire que la récupération Redis chargera d'abord AOF, et s'il y a un problème avec AOF, elle chargera à nouveau RDB, ainsi. atteindre l'objectif de sauvegarde chaude et froide.

Pour plus de connaissances liées à la programmation, veuillez visiter : Introduction à la programmation ! !

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!