Quels sont les problèmes avec les performances de Redis ?

Voici les problèmes de performances courants de Redis ?

Master écrit un instantané de mémoire et la commande save planifie la fonction rdbSave, ce qui bloquera le travail du thread principal et affectera performances lorsque l'instantané est relativement volumineux. Il est très volumineux et suspendra les services par intermittence, il est donc préférable que le maître n'écrive pas d'instantanés de mémoire. (Apprentissage recommandé : Tutoriel vidéo Redis)

Maîtrisez la persistance AOF Si le fichier AOF n'est pas réécrit, cette méthode de persistance a le plus petit impact sur les performances. le fichier AOF continuera à croître. Si le fichier AOF est trop volumineux, cela affectera la vitesse de récupération du redémarrage du maître.

Le maître appelle BGREWRITEAOF pour réécrire le fichier AOF. AOF occupera une grande quantité de ressources CPU et mémoire pendant la réécriture, ce qui entraînera une charge de service excessive et une suspension du service à court terme.

Voici la situation d'un de mes projets actuels. La situation générale est la suivante :

Un maître, 4 esclaves, pas de mécanisme de fragmentation, juste la lecture et l'écriture sont séparées. Le maître est responsable des opérations d'écriture et de la sauvegarde du journal AOF. Le fichier AOF est d'environ 5 Go, et l'esclave est responsable des opérations de lecture. Lorsque le maître appelle BGREWRITEAOF, la charge sur le maître et l'esclave. augmente soudainement et les demandes d'écriture du maître ne répondent pratiquement pas. Cela a duré environ 5 minutes et l'esclave n'a pas pu répondre à temps à plus de la moitié des demandes de lecture. La situation ci-dessus ne se produirait pas et ne devrait pas se produire, car. La machine du maître était autrefois une machine esclave, et il y avait une tâche shell programmée dessus tous les matins. À 10 heures, BGREWRITEAOF a été appelé pour réécrire le fichier AOF. Plus tard, parce que la machine maître était en panne, l'esclave de sauvegarde a été modifié. au Maître. Cependant, cette tâche planifiée a été oubliée et a conduit à la situation tragique ci-dessus. Il a fallu plusieurs jours pour en trouver la raison.

Définissez la configuration no-appendfsync-on-rewrite sur yes pour atténuer ce problème. Le définir sur yes signifie que les nouvelles opérations d'écriture ne seront pas fsyncd pendant la réécriture et seront temporairement stockées dans la mémoire jusqu'à ce que la réécriture soit terminée. avant d'écrire. Il est préférable de ne pas activer la fonction de sauvegarde AOF du Maître.

Problèmes de performances de la réplication maître-esclave Redis, la première synchronisation entre l'esclave et le maître est la suivante : l'esclave envoie une demande de synchronisation au maître, le maître vide d'abord le fichier rdb, puis vide l'intégralité fichier rdb Transmettez à l'esclave, puis le maître transmet la commande mise en cache à l'esclave et la synchronisation initiale est terminée. La deuxième implémentation de synchronisation et les suivantes sont les suivantes : le maître envoie des instantanés de variables directement à chaque esclave en temps réel. Quelle que soit la raison pour laquelle l'esclave et le maître se déconnectent et se reconnectent, le processus ci-dessus sera répété. La réplication maître-esclave de Redis est basée sur la persistance des instantanés de mémoire. Tant qu'il y aura un esclave, il y aura un instantané de mémoire. Bien que Redis affirme que la réplication maître-esclave n'est pas bloquante, en raison des limitations d'E/S du disque, si le fichier d'instantané maître est relativement volumineux, le vidage prendra beaucoup de temps. Au cours de ce processus, le maître peut ne pas être en mesure de répondre au message. demande, ce qui signifie que le service sera interrompu pour le service critique, les conséquences sont également terribles.

Les raisons des problèmes fondamentaux 1.2.3.4 ci-dessus sont toutes indissociables du problème de goulot d'étranglement du système, c'est-à-dire que la vitesse de lecture et d'écriture du disque dur n'est pas assez rapide et que le processus principal fsync()/write () l’opération est bloquée.

Problème de point de défaillance unique Étant donné que la réplication maître-esclave actuelle de Redis n'est pas suffisamment mature, il existe actuellement un problème de point de défaillance unique évident, nous ne pouvons résoudre ce problème qu'en. nous-mêmes, tels que : la réplication active, le proxy implémente le remplacement du maître par l'esclave, etc. C'est également l'une des tâches prioritaires actuelles de l'auteur Redis.

Pour plus d'articles techniques liés à Redis, veuillez visiter la colonne Introduction au didacticiel d'utilisation de la base de données Redis 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!