在一次调用中从Redis缓存中查询百万个密钥

Question

我正在使用Redis作为我的缓存服务器。为了清楚起见，我将存储像'S0007226_2005-07-09': '[15.3462, -1]'这样的键值对。查询是关于特定键的，而不是基于范围的。为了查询，我使用的是pyredis客户端。

我经常不得不从缓存中获取约100万个键。这种查询对于redis来说太重了，最多需要10秒钟。这里的问题是MGET for n keys in query is an O(n) operation（n是查询中的键数）。我已经添加了用于从日志中查询时间的表。

| Keys   | time(ms)|
| 703732 | 6869.66 |
| 26806  | 277.21  |
| 13180  | 137.41  |
| 400    | 5.83    |
| 2589   | 29.04   |
| 180    | 3.6     |
| 98413  | 1009.84 |
| 151994 | 1524.12 |

这似乎很正常，因为键的数量不断增加，时间以O（n）的方式增加。另外，我正在使用redis管道以10K的大块打破密钥列表。

我想将查询时间减少到〜1s或更短。如果不是Redis，我本可以尝试并行请求并合并结果。但是鉴于redis只能在单核上运行，所以在我的理解中，这不是一个可行的选择。可能的出路：

1. 进行一些设计更改，而我不必首先查询一百万个键。
2. 使用其他工具代替Redis来处理负载。
3. 当前设置本身进行了一些优化，以更好地处理它。

假设我必须从2和3中选择一个。我有什么选择。我是否应该尝试其他一些设计用于更高吞吐量的缓存服务器，或者我可以在查询/存储或设置中进行一些优化以获得更好的结果？

Answer 1

“如果不是Redis，我本可以尝试并行请求并合并结果。”

您仍然可以并行请求。创建多主机设置并在多个主机之间分片/分发密钥。然后，您可以从多个主服务器并行请求数据。

我还可以从经验中告诉您，没有什么比Redis更快的了，因为它完全是内存中的单线程进程。所以问题2的可能性很小。

我宁愿更改设计，即＃1。如果没有，请同时进行多主机设置和请求。

Answer 2

我不认为您应该同时查询1Mn键。您应该使用内存缓存和Redis缓存构建缓存。

您应该这样查询：

• 在本地缓存中搜索
• 仅查询Redis以查找不可用的键。

始终使用TTL，TTL将帮助您随时间分布密钥查询，如果您认为许多密钥可能同时失效，则向TTL添加随机增量。

即使在执行此操作后，如果看到单个节点Redis的性能问题也比使用主副本的性能问题大。根据您拥有的密钥数量，您需要拥有10个以上的分片。