Redis缓存-何时可能触发大规模驱逐？

Question

我们在Azure上使用了一个Redis缓存，规格为Standard 2.5gb。我们观察到以下行为：。不时地，我们会观察到内存使用量大幅下降的情况。这似乎是因为许多资源被驱逐出去了。

需要注意以下几点：

- 驱逐策略是LRU - 可用缓存大小为2.5GB - 没有应用程序代码会驱逐如此大量的内存（最大对象大小约为80KB，大多数对象要小得多） - 观察到的内存下降代表成千上万个键 - 我们很少在缓存对象上使用显式过期日期，即使使用也始终小于1小时。

我的问题是，除了应用程序逻辑明确删除键之外，Redis是否会因其他情况而驱逐大量键？

- Tom Gullen

---

从未使用过Redis Azure，但是这个文档提供了有关清除的技巧：https://learn.microsoft.com/en-us/azure/redis-cache/cache-configure#memory-policies - Niloct

你的清除操作是否恰好与 Azure Redis 维护间隔重合？如果某个分片离线并允许数据丢失，那可能是一个解释。 - No Refunds No Returns

Answer 1

内存清理可能并不代表驱逐。

您说“似乎”有很多资源被驱逐，但如果您只是依靠回收的内存来判断，那么您可能在追逐幽灵。您是否检查了此图形与Azure门户中可用的总键数指标的重叠情况？将这两个系列重叠可以让您看到内存回收是否真正是由于驱逐，还是由于其他进程，例如Azure定期在缓存实例上调用MEMORY PURGE来清除脏页？

- Dusty

---

你说得对，总键数不断增长（正如我所预期的），并且那里没有任何下降。我似乎找不到其他与内存使用下降相关的图表。 - Tom Gullen

我已经认真考虑过这个问题——我们使用Redlock.net进行分布式锁定，它在Redis缓存中创建了许多轻量级对象。如果这些内存正在被清除，那么这是否可能是导致内存下降的原因？ - Tom Gullen

@TomGullen - 我对Redlock.net并不熟悉，但我见过的几个redis D-locking实现确实会产生大量的键值变化，因此创建和随后删除分布式锁跟踪键将导致大量内存的分配和释放，这些内存应该可以通过MEMORY PURGE被回收。 - Dusty

谢谢您的帮助，这似乎是一个合理的解释，我会将其标记为正确答案。我想这可以通过将锁定移动到另一个Redis缓存来轻松测试。 - Tom Gullen

Answer 2

你能否将 Redis 的清理策略更改为 noeviction 并查看是否解决了你的问题？这样做意味着你需要自己管理所有内容。https://redis.io/topics/lru-cache 上有更多详细信息。

- No Refunds No Returns

---

不舒服在生产环境下这样做，我认为这不是一个选项。 - Tom Gullen