redis - 使用 volatile-ttl 的奇怪 key 逐出行为

Question

我的用例不完全是缓存。我的场景是一个后台数据分析服务，需要跟踪一些数据组的统计信息，很明显，RAM 永远不会足够保存所有组的统计信息，但我们希望保留尽可能多的数据。因此，随着 key 的每次 n 更新，我更新 TTL 的方式使代表更频繁数据组的 key 获得更高的 TTL。目的是始终保留最频繁出现的键，只有不那么频繁/不太重要的键才会被删除。

这是我目前正在做的事情:

• maxmemory 设置为安全值(约 40% 的 RAM，因为快照和碎片)
• maxmemory-policy volatile-ttl
• maxmemory-samples 100(我接受一点时间延迟，以确保我不会丢失一个重要的 key ，因为碰巧只比较了一小部分重要 key 的样本；Redis 是不是我场景中的瓶颈)
• 计算的 TTL 设置有 1 周的较大偏移量。这个想法是 key 永远不会因为它们已经过期而被驱逐，它们应该只在达到内存限制时被删除。所以 TTL 变成了偏移量 + 频率之类的东西
• 我的键都是有序集合。

现在，对于某些工作负载，这完全可以正常工作。我可以看到内存使用量增加接近或略高于我的内存使用量，而不是保持平稳。不太重要的 key 来来去去，更重要的 key 会留下来。

现在我有不同的工作负载， key 驱逐策略完全失败。例如。键的数量下降到我们通常看到的 1/100，只有 10% 的最大内存在使用(用 Redis info 和进程级 top 双重检查)。新工作负载的不同之处在于，键往往更少，但每个排序集的更新更多。但是，每个排序集中的最大条目数没有区别，因为我对此有自己的修剪。平均 TTL 现在显示为 654892235，因此平均约为 7.5 天，正如预期的那样。所以 TTL 似乎没问题。

关于 Redis 在这方面的工作原理，我是否缺少任何基本信息？还有其他相关的配置设置吗？我应该寻找哪些 Redis 统计值来阐明发生了什么？我可以将 Redis 配置为记录有关每次驱逐的详细信息吗？ G。原因，哪些键被采样等？

Answer 1

细粒度监控(基本上每 30 秒转储所有 key )表明，工作负载导致某些 key 的大小出现意外的巨大峰值，从而导致实际内存不足的情况。所以 key 驱逐是绝对合法的。在改进我自己的修剪策略后，现在一切正常。

所以 Redis 本身没有问题!