Redis 对包含 15 个较大 JSON 对象(总共 20MB)的列表的查询时间超过 1 分钟

Question

我使用 Redis 来缓存数据库插入。为此，我创建了一个列表 CACHE，我将序列化的 JSON 列表推送到其中。在伪代码中:

let entries = [{a}, {b}, {c}, ...];
redis.rpush("CACHE", JSON.stringify(entries));

我们的想法是运行这段代码一个小时，然后再做一个

let all = redis.lrange("CACHE", 0, LIMIT);
processAndInsert(all);
redis.ltrim("CACHE", 0, all.length);

现在的问题是，每个 entries 都可能相对较大(但远低于 512MB/我读到的任何 Redis 限制)。 a、b、c 中的每一个都是一个大约 20 字节的对象，而 entries 本身可以轻松拥有 100k+ 个对象/2MB。

我现在的问题是，即使对于只有 15 个条目的非常短的 CACHE 列表，一个简单的 lrange 也可能需要很多分钟(!)，即使来自 redis- cli(我的 node.js 实际上死于 “ fatal error :CALL_AND_RETRY_LAST 分配失败 - 进程内存不足”，但这是旁注)。

列表的调试输出如下所示:

127.0.0.1:6379> debug object "CACHE"
Value at:00007FF202F4E330 refcount:1 encoding:linkedlist serializedlength:18104464 lru:12984004 lru_seconds_idle:1078

发生了什么事？为什么这么慢，我能做些什么呢？这似乎不是正常的缓慢，似乎有根本性的错误。

顺便说一下，我在相对硬核的 Windows 10 游戏机(i5、16GB RAM、840 EVO SSD，...)上使用本地 Redis 2.8.2101 (x64)、ioredis 1.6.1、node.js 0.12 .

Answer 1

Redis 擅长做很多小操作，但不擅长做少量的“非常大”的操作。

我认为您应该重新评估您的算法，并尝试将您的数据分解成更小的 block 。您不仅会节省带宽，而且不会长时间锁定您的 Redis 实例。Redis 提供了许多数据结构，您应该能够使用它们对数据进行更精细的控制。

好吧，在这种情况下，由于您在本地运行 redis，并且假设除了这段代码之外没有运行任何其他东西，我怀疑带宽或 redis 都不是问题。我更想这一行:

JSON.stringify()

是执行缓慢的主要原因。

JSON 序列化 20MB 的字符串并不简单，该过程需要分配许多小字符串，还必须遍历所有数组并单独检查每个项目。对于像这样的大物体，所有这些都需要很长时间。

同样，如果您要拆分数据并使用 Redis 执行较小的操作，则根本不需要 JSON 序列化程序。