标签：依赖 现在 响应时间 出现 redis 链表 保存 方式 访问
redis设计与实现(第二版)
? 我们知道数据库的过期时间都保存在过期字典中，又知道了如何根据过期时间去判断一个键是否过期，现在的问题是：如果一个键过期了，那么它什么时候会被删除呢？
? 这个问题有三种可能的答案，它们分别代表三种不同的 删除策略：
在这三种策略中，第一种和第三种为主动删除策略，而第二种则为被动策略
? 定时删除策略对内存是最友好的，通过使用定时器，定时删除策略可以保证过期键会尽可能地删除，并释放过期键所占用地内存。
? 另一方面，定时删除策略地确定是，它对cpu时间是不友好地；在过期键比较多地情况下，删除过期键这一行为可能会占用相当一部分cpu时间，在内存不紧张但是cpu时间非常紧张地i情况下，将cpu时间用在删除和当前无关地过期键上，无疑会对服务器地响应时间和吞吐量造成影响。
? 例如，如果正有大量地命令请求在等待服务器处理，并且服务器当前不缺少内存，那么服务器应该优先将cpu时间用在处理客户端地命令请求上面，而不是用在删除过期键上面。
? 除此之外，创建一个定时器需要用到redis服务器中地时间事件内，而当前时间事件地实现方式——无序链表，查找一个事件地时间复杂度为O（n）——并不能高效地处理大量时间事件。
? 因此，要让服务器创建大量地定时器，从而实现定时删除策略，在现阶段来说并不是现实。
? 惰性删除策略对cpu时间来说是最友好的：程序只会在取出键时才对键进行过期检查，这可以保证删除过期的操作只会在非做不可的情况下进行，并且删除的目标仅限于当前处理的键，这个策略不会在删除其它无关的过期键花费任何cpu时间。
? 惰性删除策略的缺点是，它对内存是最不友好的；如果一个键已经过期，而这个键又仍然保留在数据库中，那么只要这个过期键不被删除，它所占用的内存就不会释放。
? 在使用惰性删除策略时，如果数据库中有非常多的过期键，而这些过期键又恰好没有被访问到的话，那么它们也许永远也不会被删除（除非手动执行FLUSHDB），我们甚至可以将这种情况看作是一种内存泄漏——无用的垃圾占用了大量的内存，而服务器却不会自己去释放它们，这对于运行状态非常依赖于内存的redis服务器来说，肯定不是一个好消息。
? 举个例子，对于一些和时间有关的数据，比如日志，在某个时间点之后，对它们的访问就会大大减少，甚至不再访问，如果这类过期数据大量地积压在数据库中，用户以为服务器已经自动将它们删除了，但实际这些键仍然存在，而且所占用的内存也没有释放，那么造成的后果肯定是非常严重的。
? 从上面对定时删除和惰性删除地讨论来看，这两种方式在单一使用时都有明显地缺陷：
定期删除策略是前两种策略地一种整合和折中：
定期删除策略地难点是确定删除操作执行时长和频率：
因此，如果采用定期删除策略地话，服务器必须根据情况，合理地设置删除操作地执行时长和执行频率。
标签：依赖 现在 响应时间 出现 redis 链表 保存 方式 访问
原文地址：https://www.cnblogs.com/sm1128/p/12034334.html
