Redis 使用volatile ttl的奇怪密钥逐出行为_Redis

Redis 使用volatile ttl的奇怪密钥逐出行为

redis

Redis 使用volatile ttl的奇怪密钥逐出行为,redis,Redis,我的用例并不完全是缓存。我的场景是一个后台数据分析服务，它需要跟踪数据组的一些统计信息，很明显，永远不会有足够的RAM来保存所有组的统计信息，但我们希望保存尽可能多的数据。因此，对于每n个键的更新，我都会以一种方式更新TTL，即表示更频繁数据组的键会获得更高的TTL。这样做的目的是一直保留最频繁的密钥，并且只删除不太频繁/不太重要的密钥以下是我目前正在做的事情： maxmemory设置为安全值（~40%的RAM，因为快照和碎片） maxmemory策略易失性ttl maxmemory sam

我的用例并不完全是缓存。我的场景是一个后台数据分析服务，它需要跟踪数据组的一些统计信息，很明显，永远不会有足够的RAM来保存所有组的统计信息，但我们希望保存尽可能多的数据。因此，对于每n个键的更新，我都会以一种方式更新TTL，即表示更频繁数据组的键会获得更高的TTL。这样做的目的是一直保留最频繁的密钥，并且只删除不太频繁/不太重要的密钥

以下是我目前正在做的事情：

```
maxmemory
```
设置为安全值（~40%的RAM，因为快照和碎片）
```
maxmemory策略易失性ttl
```
```
maxmemory samples 100
```
（我接受一点时间延迟，以确保我不会因为只比较了一小部分重要密钥而丢失一个重要密钥；Redis不是我场景中的瓶颈）
计算的TTL设置为1周的大偏移量。其思想是，密钥永远不会因为过期而被逐出，只有在达到内存限制时才应将其删除。所以TTL变成了偏移量+频率
我的钥匙都是分类的

现在，对于一些工作负载来说，这是非常好的。我可以看到内存使用率在接近或略高于我的内存使用率的情况下增加，而不是保持不变。不太重要的钥匙来来去去去，更重要的钥匙会留下来

现在我有了不同的工作负载，关键逐出策略完全失败了。例如，按键数量下降到正常情况下的1/100，使用的最大内存只有10%（使用Redis

info

进行双重检查，并在流程级别使用

top

）。新工作负载的不同之处在于，每个排序集的键往往较少，但更新次数较多。但是，每个排序集中的最大条目数没有差异，因为我有自己的剪枝。目前的平均TTL显示为654892235，因此与预期一样，平均约为7.5天。所以TTL看起来不错

关于Redis在这方面的工作原理，我有什么基本的遗漏吗？是否有其他相关的配置设置？我应该寻找什么Redis统计值来澄清发生了什么？我可以将Redis配置为记录每次逐出的详细信息吗。G原因是，对哪些密钥进行了采样等？

细粒度监视（基本上每30秒转储一次所有密钥）表明，工作负载导致某些密钥的大小出现意外的巨大峰值，导致实际内存不足。所以关键的驱逐是绝对合法的。在改进了我自己的修剪策略之后，现在一切都正常了

所以Redis本身没有问题