【发布时间】：2015-02-18 16:38:02
【问题描述】：
我的用例并不完全是缓存。我的场景是一个后台数据分析服务，它需要跟踪一些数据组的统计信息，很明显永远不会有足够的 RAM 来保存所有组的统计信息，但我们希望尽可能多地保留。因此，对于一个键的每次 n 更新，我都会更新 TTL，以使表示更频繁数据组的键获得更高的 TTL。其目的是始终保留最常用的键，而只删除不常用/不太重要的键。
这是我目前正在做的事情：
-
maxmemory设置为安全值（大约 40% 的 RAM，因为快照和碎片） maxmemory-policy volatile-ttl-
maxmemory-samples 100（我接受了一点时间延迟，以确保我不会仅仅因为碰巧比较了一小部分重要密钥而丢失了重要密钥；Redis 不是我方案中的瓶颈） - 计算的 TTL 设置为 1 周的大偏移量。这个想法是，密钥永远不会因为过期而被驱逐，只有在达到内存限制时才应该删除它们。所以 TTL 变成了偏移 + 频率
- 我的键都是有序集合。
现在，对于某些工作负载，这可以正常工作。我可以看到内存使用量增加接近或略高于我的内存使用量，而不是保持不变。不太重要的钥匙来来去去，更重要的钥匙会留下来。
现在我有不同的工作负载，key eviction 策略完全失败了。例如。键的数量下降到我们通常看到的 1/100，只有 10% 的最大内存在使用（使用 Redis info 和在进程级别使用 top 进行双重检查）。新工作负载的不同之处在于，键往往更少，但每个排序集的更新更多。但是，每个排序集中的最大条目数没有区别，因为我对此有自己的修剪。平均 TTL 现在显示为 654892235，因此与预期的一样，平均约为 7.5 天。所以 TTL 似乎没问题。
关于 Redis 在这方面的工作原理，我是否缺少任何基本信息？还有其他相关的配置设置吗？我应该寻找什么 Redis stats 值来澄清发生了什么？我可以将 Redis 配置为记录有关每次驱逐的详细信息，例如。 G。原因，哪些键被采样等？
【问题讨论】：
标签： redis