Comment obtenir la persistance dans Redis

Redis est un service indispensable pour la programmation web actuelle. Ses caractéristiques sont évidentes. Par rapport à memcached, il peut être mis en cache et redémarré sans perdre de données, ce qui est très simple à utiliser. La question est donc : comment fait-il ?

RDB

RDB est un moyen de persistance, qui écrit des données en mémoire sur le disque sous certaines conditions. Alors dans quelles conditions est-il écrit ? Il est impossible d'écrire sans réfléchir. Si vous écrivez un par un, cela affectera les performances. Vous ne pouvez pas attendre longtemps avant d'en écrire un. Si l'ordinateur tombe en panne au milieu et que toutes les données sont perdues. Il est préférable d'utiliser Memcached. Il existe une telle configuration dans la configuration redis :

save 900 1

save 300 10

save 60 10000

Un élément de configuration très critique, qui est au cœur de la persistance RDB. Cela signifie :

1. Si 1 clé change (insertion ou mise à jour) en 900 secondes, je la synchroniserai sur le disque

2. Si dans 300 secondes, il y a Si. 10 changements de clés (insertion ou mise à jour), je le synchroniserai sur le disque

3. S'il y a 10 000 changements de clé (insertion ou mise à jour) en 60 secondes, je le synchroniserai sur le disque

Comment connaître ces points temporels et le nombre de changements ? Il y a deux autres choses extrêmement critiques à ce moment-là, l'une s'appelle le compteur sale et l'autre s'appelle lastsave (l'heure de la dernière sauvegarde). Le compteur enregistre spécifiquement le temps écoulé depuis la dernière sauvegarde. Modifier le nombre de clés. Lastsave enregistre l'heure à laquelle la sauvegarde est exécutée. Par exemple, l'heure initiale est time1 et dirty est 0. À ce moment, 20 clés ont changé, dirty est. 20, puis l'heure actuelle est time2, time2-time1 > ;= 300, si la deuxième condition est remplie, les données dans la mémoire seront enregistrées et sale sera remis à 0, puis attendez que la condition soit déclenchée .

Si j'ai 100 000 clés en 60 secondes, alors le problème surviendra. Un grand nombre d'E/S disque arriveront, le processus principal Redis sera bloqué et toutes les commandes pendant cette période ne seront pas exécutées. Comment cela peut-il être fait ? , c'est pourquoi un sous-processus appelé bgsave est apparu, qui est un sous-processus dérivé du processus Redis principal et est spécialisé dans l'exécution du travail de persistance RDB.

Le format du fichier enregistré est au format binaire. Si la base de données tombe en panne, aucune intervention humaine n'est requise pour la récupération et Redis lira automatiquement le fichier disque.

AOF

Contrairement à RDB, AOF stocke les commandes que vous exécutez Lorsque la fonction aof est activée, la commande de mise à jour exécutée ne sera pas écrite directement dans le fichier aof. . Au lieu d'écrire d'abord sur un buf aof, nous savons que nous ne pouvons pas toujours écrire sur buf, c'est aussi de la mémoire, alors quand peut-il être synchronisé sur le disque ? Il existe également une telle configuration dans Redis

appendfsync Always

appendfsync Everysec

appendfsync no

signifie :

1. comme il y a une mise à jour je synchroniserai la commande

2 Si la dernière heure de synchronisation est dans plus d'une seconde, synchronisez

3 Si elle n'est pas synchronisée, attendez le fonctionnement. système à juger par lui-même (je synchroniserai quand je serai libre) )

Après analyse, le premier type d'io est fréquent et a une pression d'io élevée, mais la probabilité de perdre des données est la plus faible. de io n'est pas très stressant et ne perd qu'environ 1 seconde de données au maximum. Le troisième type d'io est Il y a peu de pression et la probabilité de perdre des données est trop grande. Tout bien considéré, généralement la deuxième option. Mais il y a une autre question. J'ai exécuté INCR num 100 fois. Logiquement, num est 100. Il y a 100 mêmes commandes dans aof. Alors, quelle est la différence entre exécuter INCR num 100 fois et SET num 100 ? Le même résultat. Le premier prend 99 fois plus d'espace, ce qui est un gaspillage considérable, donc la réécriture AOF est apparue. Comment ça se fait ? C'est très simple : lire d'abord la valeur courante dans la base de données, puis la remplacer par un enregistrement. C'est le principe de la réécriture AOF. La réécriture prend du temps, elle est donc gérée par un processus enfant. Pendant le processus de réécriture, que dois-je faire si une nouvelle commande arrive ? L'ancienne méthode consiste à écrire le tampon buf une fois la réécriture terminée, à ajouter les commandes du buf au nouvel aof, puis à remplacer l'ancien aof par le. new aof. Implémentation de la réécriture.

Cet article provient du tutoriel Redis, bienvenue pour apprendre.

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!