• redis的超时删除策略


     

    这个问题有三种可能的答案,它们分别代表了三种不同的删除策略:

    ·定时删除:在设置键的过期时间的同时,创建一个定时器(timer),让定时器在键的过期时间来临时,立即执行对键的删除操作。

    ·惰性删除:放任键过期不管,但是每次从键空间中获取键时,都检查取得的键是否过期,如果过期的话,就删除该键;如果没有过期,就返回该键。

    ·定期删除:每隔一段时间,程序就对数据库进行一次检查,删除里面的过期键。至于要删除多少过期键,以及要检查多少个数据库,则由算法决定。

    在这三种策略中,第一种和第三种为主动删除策略,而第二种则为被动删除策略。

     定时删除

    定时删除策略对内存是最友好的:通过使用定时器,定时删除策略可以保证过期键会尽可能快地被删除,并释放过期键所占用的内存。

    另一方面,定时删除策略的缺点是,它对CPU时间是最不友好的:在过期键比较多的情况下,删除过期键这一行为可能会占用相当一部分CPU时间,在内存不紧张但是CPU时间非常紧张的情况下,将CPU时间用在删除和当前任务无关的过期键上,无疑会对服务器的响应时间和吞吐量造成影响。

    例如,如果正有大量的命令请求在等待服务器处理,并且服务器当前不缺少内存,那么服务器应该优先将CPU时间用在处理客户端的命令请求上面,而不是用在删除过期键上面。

    除此之外,创建一个定时器需要用到Redis服务器中的时间事件,而当前时间事件的实现方式——无序链表,查找一个事件的时间复杂度为O(N)——并不能高效地处理大量时间事件。

    因此,要让服务器创建大量的定时器,从而实现定时删除策略,在现阶段来说并不现实。

     惰性删除

    惰性删除策略对CPU时间来说是最友好的:程序只会在取出键时才对键进行过期检查,这可以保证删除过期键的操作只会在非做不可的情况下进行,并且删除的目标仅限于当前处理的键,这个策略不会在删除其他无关的过期键上花费任何CPU时间。

    惰性删除策略的缺点是,它对内存是最不友好的:如果一个键已经过期,而这个键又仍然保留在数据库中,那么只要这个过期键不被删除,它所占用的内存就不会释放。

    在使用惰性删除策略时,如果数据库中有非常多的过期键,而这些过期键又恰好没有被访问到的话,那么它们也许永远也不会被删除(除非用户手动执行FLUSHDB),我们甚至可以将这种情况看作是一种内存泄漏——无用的垃圾数据占用了大量的内存,而服务器却不会自己去释放它们,这对于运行状态非常依赖于内存的Redis服务器来说,肯定不是一个好消息。

    举个例子,对于一些和时间有关的数据,比如日志(log),在某个时间点之后,对它们的访问就会大大减少,甚至不再访问,如果这类过期数据大量地积压在数据库中,用户以为服务器已经自动将它们删除了,但实际上这些键仍然存在,而且键所占用的内存也没有释放,那么造成的后果肯定是非常严重的。

    定期删除

    从上面对定时删除和惰性删除的讨论来看,这两种删除方式在单一使用时都有明显的缺陷:

    ·定时删除占用太多CPU时间,影响服务器的响应时间和吞吐量。

    ·惰性删除浪费太多内存,有内存泄漏的危险。

    定期删除策略是前两种策略的一种整合和折中:

    ·定期删除策略每隔一段时间执行一次删除过期键操作,并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响。

    ·除此之外,通过定期删除过期键,定期删除策略有效地减少了因为过期键而带来的内存浪费。

    定期删除策略的难点是确定删除操作执行的时长和频率:

    ·如果删除操作执行得太频繁,或者执行的时间太长,定期删除策略就会退化成定时删除策略,以至于将CPU时间过多地消耗在删除过期键上面。

    ·如果删除操作执行得太少,或者执行的时间太短,定期删除策略又会和惰性删除策略一样,出现浪费内存的情况。

    因此,如果采用定期删除策略的话,服务器必须根据情况,合理地设置删除操作的执行时长和执行频率。

     

     

     

    过期键的定期删除策略由redis.c/activeExpireCycle函数实现,每当Redis的服务器周期性操作redis.c/serverCron函数执行时,activeExpireCycle函数就会被调用,它在规定的时间内,分多次遍历服务器中的各个数据库,从数据库的expires字典中随机检查一部分键的过期时间,并删除其中的过期键。

    整个过程可以用伪代码描述如下:


    # 
    默认每次检查的数据库数量
    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

    activeExpireCycle函数的工作模式可以总结如下:

    ·函数每次运行时,都从一定数量的数据库中取出一定数量的随机键进行检查,并删除其中的过期键。

    ·全局变量current_db会记录当前activeExpireCycle函数检查的进度,并在下一次activeExpireCycle函数调用时,接着上一次的进度进行处理。比如说,如果当前activeExpireCycle函数在遍历10号数据库时返回了,那么下次activeExpireCycle函数执行时,将从11号数据库开始查找并删除过期键。

    ·随着activeExpireCycle函数的不断执行,服务器中的所有数据库都会被检查一遍,这时函数将current_db变量重置为0,然后再次开始新一轮的检查工作。

  • 相关阅读:
    Appium问题解决方案(2)- AttributeError:module 'appium.webdriver' has no attribute 'Remote'
    Azure Messaging-ServiceBus Messaging消息队列技术系列8-服务总线配额
    Azure Messaging-ServiceBus Messaging消息队列技术系列7-消息事务
    Azure Messaging-ServiceBus Messaging消息队列技术系列6-消息回执
    Azure Messaging-ServiceBus Messaging消息队列技术系列5-重复消息:at-least-once at-most-once
    Azure Messaging-ServiceBus Messaging消息队列技术系列4-复杂对象消息是否需要支持序列化和消息持久化
    Azure Messaging-ServiceBus Messaging消息队列技术系列3-消息顺序保证
    [博客迁移]探索Windows Azure 监控和自动伸缩系列3
    [博客迁移]探索Windows Azure 监控和自动伸缩系列2
    [博客迁移]探索Windows Azure 监控和自动伸缩系列1
  • 原文地址:https://www.cnblogs.com/hexie/p/5011299.html
Copyright © 2020-2023  润新知