我的用例并非完全缓存。我的场景是一个后台数据分析服务，需要跟踪一些数据组的统计数据，很明显，永远不会有足够的RAM来保存所有组的统计数据，但我们希望保留尽可能多的数据尽可能。因此，对于密钥的每次 n 更新，我都会以表示更频繁数据组的密钥获得更高TTL的方式更新TTL。目的是最频繁的密钥将一直保留，只有不太频繁/不太重要的密钥将被删除。
这就是我现在正在做的事情：
maxmemory设置为安全值（由于快照和碎片，约占RAM的40％）maxmemory-policy volatile-ttl maxmemory-samples 100（我接受一点时滞，以确保我没有丢失一个重要的密钥只是因为只有一小部分重要的密钥碰巧被比较; Redis不是我方案中的瓶颈）现在，对于某些工作负载，这非常合适。我可以看到内存使用量增加到接近或稍微超过我的内存使用量，而不是保持平稳。不太重要的钥匙来来往往，更重要的钥匙将会存在。
现在我有不同的工作负载，关键驱逐策略完全失败。例如。键的数量下降到我们通常看到的1/100，只有10％的最大内存在使用中（使用Redis info进行双重检查，使用top进行双重检查）。新工作负载的不同之处在于密钥往往较少，但每个排序集的更新次数更多。然而，每个有序集合中的最大条目数没有不同，因为我有自己的修剪。平均TTL现在显示为654892235，因此平均大约7.5天，如预期的那样。所以TTL似乎很好。
关于Redis如何在这方面工作，我有什么基本的遗漏？是否有其他相关配置设置？我应该寻找什么Redis统计数据来澄清发生了什么？我是否可以将Redis配置为记录每次驱逐的详细信息，例如： G。原因，哪些密钥被采样等？
答案 0 :(得分：0)
细粒度监控（基本上每30秒卸载一次所有密钥）表明，工作负载导致一些密钥大小出现意外的，巨大的峰值，导致实际的低内存条件。所以关键的驱逐绝对合法。在完善自己的修剪策略后，现在一切正常。
Redis本身没问题！