Redis a-t-il une fonction de suppression programmée ?

Il existe trois réponses possibles à la suppression du délai d'attente Redis, qui représentent trois stratégies de suppression différentes :

Suppression planifiée : lors de la définition du délai d'expiration de la clé, créez un minuteur (minuterie) et laissez la minuterie effectuer immédiatement la suppression de la clé lorsque l'heure d'expiration de la clé arrive.

Suppression paresseuse : laissez la clé expirer, mais chaque fois que vous récupérez la clé de l'espace clé, vérifiez si la clé obtenue a expiré, supprimez la clé si elle n'a pas expiré, retournez-la. la clé.

Suppression régulière : de temps en temps, le programme vérifie la base de données et supprime les clés expirées. C'est à l'algorithme de décider combien de clés expirées supprimer et combien de bases de données vérifier.

Parmi ces trois stratégies, la première et la troisième sont des stratégies de suppression active, tandis que la seconde est une stratégie de suppression passive.

Suppression programmée :

La stratégie de suppression programmée est la plus respectueuse de la mémoire : en utilisant une minuterie, la stratégie de suppression programmée peut garantir que les clés expirées seront supprimées le plus rapidement possible et libéreront la mémoire occupée par les clés expirées.

En revanche, l'inconvénient de la stratégie de suppression programmée est qu'elle est la moins conviviale pour le temps CPU : lorsqu'il y a de nombreuses clés expirées, la suppression des clés expirées peut prendre une partie considérable du temps CPU. Lorsque la mémoire n'est pas limitée mais que le temps CPU est très limité, l'utilisation du temps CPU pour supprimer des clés expirées qui ne sont pas pertinentes pour la tâche en cours affectera sans aucun doute le temps de réponse et le débit du serveur.

Par exemple, s'il y a un grand nombre de requêtes de commande en attente de traitement par le serveur et que le serveur ne manque actuellement pas de mémoire, le serveur doit donner la priorité à l'utilisation du temps CPU pour traiter les requêtes de commande du client au lieu de suppression des clés expirées ci-dessus.

De plus, la création d'un minuteur nécessite l'utilisation d'événements temporels dans le serveur Redis. L'événement temporel actuel est implémenté sous forme de liste chaînée non ordonnée. La complexité temporelle de la recherche d'un événement est O(N). Ne peut pas gérer efficacement de grandes quantités d’événements temporels.

Par conséquent, il n'est pas réaliste à ce stade que le serveur crée un grand nombre de timers pour mettre en œuvre une stratégie de suppression planifiée.

Suppression paresseuse :

La stratégie de suppression paresseuse est la plus conviviale en termes de temps CPU : le programme ne supprimera la clé que lorsqu'elle sera supprimée. Une vérification de l'expiration est effectuée, ce qui garantit que la suppression des clés expirées ne sera effectuée que lorsque cela est nécessaire, et que la cible de suppression est limitée aux clés actuellement traitées. Cette stratégie ne consacrera aucun temps CPU à la suppression d'autres clés expirées non pertinentes.

L'inconvénient de la stratégie de suppression paresseuse est qu'elle est la moins conviviale pour la mémoire : si une clé a expiré et que la clé est toujours conservée dans la base de données, alors tant que la clé expirée n'est pas supprimée, il occupera La mémoire ne sera pas libérée.

Lors de l'utilisation de la stratégie de suppression paresseuse, s'il y a beaucoup de clés expirées dans la base de données et que ces clés expirées ne sont pas accessibles, elles risquent de ne jamais être supprimées (à moins que l'utilisateur n'exécute manuellement FLUSHDB ), nous pouvons même considérer cette situation comme une fuite de mémoire - les données inutiles occupent une grande quantité de mémoire, mais le serveur ne les libérera pas tout seul. C'est un problème pour le serveur Redis dont l'état de fonctionnement dépend fortement de la mémoire. pas une bonne nouvelle.

Par exemple, pour certaines données liées au temps, comme les journaux, après un certain temps, l'accès à celles-ci sera considérablement réduit, voire plus accessible si ces données ont expiré un grand nombre de clés. sont en retard dans la base de données. Les utilisateurs pensent que le serveur les a automatiquement supprimés, mais en fait ces clés existent toujours, et la mémoire occupée par les clés n'a pas été libérée. Les conséquences doivent être très graves.

Suppression régulière :

D'après la discussion ci-dessus sur la suppression planifiée et la suppression différée, ces deux méthodes de suppression peuvent être utilisées individuellement. Toutes ont des défauts évidents :

· La suppression programmée prend trop de temps CPU, affectant le temps de réponse et le débit du serveur.

·La suppression paresseuse gaspille trop de mémoire et risque de provoquer des fuites de mémoire.

La stratégie de suppression périodique est une intégration et un compromis des deux premières stratégies :

·La stratégie de suppression périodique effectue la suppression des clés expirées de temps en temps et l'effectue en limitant la suppression Durée et fréquence pour réduire l’impact des opérations de suppression sur le temps CPU.

·De plus, en supprimant régulièrement les clés expirées, la stratégie de suppression régulière réduit efficacement le gaspillage de mémoire causé par les clés expirées.

La difficulté de la stratégie de suppression périodique est de déterminer la durée et la fréquence de l'opération de suppression :

·Si l'opération de suppression est effectuée trop fréquemment ou prend trop de temps, la stratégie de suppression périodique dégénérer en La stratégie de suppression planifiée consomme trop de temps CPU lors de la suppression des clés expirées.

·Si l'opération de suppression est exécutée trop rarement ou si le temps d'exécution est trop court, la stratégie de suppression régulière sera la même que la stratégie de suppression paresseuse, entraînant un gaspillage de mémoire.

La stratégie de suppression périodique des clés expirées est implémentée par la fonction redis.c/activeExpireCycle. Chaque fois que la fonction redis.c/serverCron de l'opération périodique du serveur Redis est exécutée, la fonction activeExpireCycle sera appelée. à l'heure spécifiée, chaque base de données du serveur est parcourue plusieurs fois, le délai d'expiration de certaines clés est vérifié de manière aléatoire à partir du dictionnaire d'expiration de la base de données et les clés expirées sont supprimées.

L'ensemble du processus peut être décrit en pseudo-code comme suit :

#
默认每次检查的数据库数量
DEFAULT_DB_NUMBERS = 16
#
默认每个数据库检查的键数量
DEFAULT_KEY_NUMBERS = 20
#
全局变量，记录检查进度
current_db = 0
def activeExpireCycle():
    #
初始化要检查的数据库数量
    #
如果服务器的数据库数量比 DEFAULT_DB_NUMBERS
要小
    #
那么以服务器的数据库数量为准
    if server.dbnum < DEFAULT_DB_NUMBERS:
        db_numbers = server.dbnum
    else:
        db_numbers = DEFAULT_DB_NUMBERS
    #
遍历各个数据库
    for i in range(db_numbers):
        #
如果current_db
的值等于服务器的数据库数量
        #
这表示检查程序已经遍历了服务器的所有数据库一次
        #
将current_db
重置为0
，开始新的一轮遍历
        if current_db == server.dbnum:
            current_db = 0
        #
获取当前要处理的数据库
        redisDb = server.db[current_db]
        #
将数据库索引增1
，指向下一个要处理的数据库
        current_db += 1
        #
检查数据库键
        for j in range(DEFAULT_KEY_NUMBERS):
            #
如果数据库中没有一个键带有过期时间，那么跳过这个数据库
            if redisDb.expires.size() == 0: break
            #
随机获取一个带有过期时间的键
            key_with_ttl = redisDb.expires.get_random_key()
            #
检查键是否过期，如果过期就删除它
            if is_expired(key_with_ttl):
                delete_key(key_with_ttl)
            #
已达到时间上限，停止处理
            if reach_time_limit(): return

Le mode de fonctionnement de la fonction activeExpireCycle peut être résumé comme suit :

·Chaque fois que la fonction s'exécute , cela part d'un certain nombre de bases de données. Un certain nombre de clés aléatoires sont extraites pour inspection et les clés expirées sont supprimées.

·La variable globale current_db enregistrera la progression de la vérification actuelle de la fonction activeExpireCycle, et la prochaine fois que la fonction activeExpireCycle sera appelée, la progression précédente sera traitée. Par exemple, si la fonction activeExpireCycle actuelle revient lors du parcours de la base de données n° 10, la prochaine fois que la fonction activeExpireCycle sera exécutée, elle recherchera et supprimera les clés expirées à partir de la base de données n° 11.

·Alors que la fonction activeExpireCycle continue de s'exécuter, toutes les bases de données du serveur seront vérifiées. À ce moment, la fonction réinitialise la variable current_db à 0, puis recommence une nouvelle série de travaux de vérification.

Pour plus de connaissances sur Redis, veuillez visiter la colonne Tutoriel d'utilisation de Redis !

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!