在 node.js 应用程序中，我使用的是由 redis 支持的 kue 队列库。作业完成后，我将其从队列中删除。一夜之间运行了大约 70,000 个作业后，redis 内存使用量约为 30MB。数据库中仍有 18 个失败的作业，队列长度目前为零 - 作业的处理速度比排队的速度快。 Redis 没有以任何其他方式使用。
任何想法为什么即使我正在删除已完成的作业，redis 内存使用量也会不断增加？咖啡脚本代码：
gaemodel.update = (params) ->
job = jobs.create "gaemodel-update", params
job.attempts 2
job.save()
job.on "complete", ->
job.remove (err) ->
throw err if err
console.log 'completed job #%d', job.id
【问题讨论】：
如果排队系统存在内存消耗问题，并且您 100% 肯定所有排队的项目都已从存储中删除并且没有进入异常/错误队列，那么最可能的原因是事实上排队率远高于出队率。
Redis 使用通用内存分配器（jemalloc、ptmalloc、tcmalloc 等...）。这些分配器不一定将内存归还给系统。当一些内存被释放时，分配器倾向于保留它（为了将来的分配重用它）。当许多小对象被随机分配时尤其如此，这通常是 Redis 的情况。
结果是在给定时间点的内存消耗峰值会导致 Redis 积累内存并保留它。该内存不会丢失，如果再次出现内存消耗高峰，它将被重新使用。但是从系统的角度来看，内存仍然是分配给 Redis 的。对于排队系统，如果您将项目排队的速度比您能够将它们出队的速度快，那么您的内存消耗就会达到峰值。
我的建议是检测您的应用程序以定期获取和记录队列长度，以检查队列中项目数量的演变（并确定峰值）。
更新：
我用 kue 测试了一些东西，以了解它在 Redis 中存储的内容。实际上，数据结构相当复杂（字符串、集合、zset 和散列的混合）。如果您查看 Redis，您会发现以下内容：
q:job:nnn (hash, job definition and properties)
q:search:object:nnn (set, metaphone tokens associated to job nnn)
q:search:word:XXXXX (set, reverse index to support job full-text indexing)
q:jobs:inactive (zset, all the unprocessed jobs)
q:jobs:X:inactive (zset, all the unprocessed jobs of job type X)
q:jobs:active (zset, all the on-going jobs)
q:jobs:X:active (zset, all the on-going jobs of job type X)
q:jobs:complete (zset, all the completed jobs)
q:jobs:X:complete (zset, all the completed jobs of job type X)
q:jobs:failed (zset, all the failed jobs)
q:jobs:X:failed (zset, all the failed jobs of job type X)
q:jobs:delayed (zset, all the delayed jobs)
q:jobs:X:delayed (zset, all the delayed jobs of job type X)
q:job:types (set, all the job types)
q:jobs (zset, all the jobs)
q:stats:work-time (string, work time statistic)
q:ids (string, job id sequence)
我根本不知道 Coffeescript，所以我尝试使用普通的旧 Javascript 重现该问题：
var kue = require('kue'),
jobs = kue.createQueue();
jobs.process( 'email', function(job,done) {
console.log('Processing email '+JSON.stringify(job) )
done();
});
function create_email(i) {
var j = jobs.create('email', {
title: 'This is email '+i
, to: 'didier'
, template: 'Bla bla bla'
});
j.on('complete', function() {
console.log('complete email job #%d', j.id);
j.remove(function(err){
if (err) throw err;
console.log('removed completed job #%d', j.id);
});
});
j.save();
}
for ( i=0; i<5; ++i )
{
create_email(i);
}
kue.app.listen(8080);
我运行了这段代码，检查了处理后 Redis 中剩余的内容：
redis 127.0.0.1:6379> keys *
1) "q:ids"
2) "q:jobs:complete"
3) "q:jobs:email:complete"
4) "q:stats:work-time"
5) "q:job:types"
redis 127.0.0.1:6379> zrange q:jobs:complete 0 -1
1) "1"
2) "2"
3) "3"
4) "4"
5) "5"
因此，尽管已删除作业，但似乎已完成的作业仍保留在 q:jobs:complete 和 q:jobs:X:complete 中。我建议您在自己的 Redis 实例中检查这些 zset 的基数。
我的解释是这些 zset 的管理发生在“完成”事件发出之后。因此，作业被正确删除，但它们的 id 被插入到这些 zset 中。
一种解决方法是避免依赖每个作业的事件，而是使用每个队列的事件来删除作业。例如，可以进行以下修改：
// added this
jobs.on('job complete', function(id) {
console.log('Job complete '+id )
kue.Job.get(id, function(err, job) {
if (err) return;
job.remove(function(err){
if (err) throw err;
console.log('removed completed job #%d', job.id);
});
});
});
// updated that
function create_email(i) {
var j = jobs.create('email', {
title: 'This is email '+i
, to: 'didier'
, template: 'Bla bla bla'
});
j.save();
}
修复程序后，Redis中的内容好多了：
redis 127.0.0.1:6379> keys *
1) "q:stats:work-time"
2) "q:ids"
3) "q:job:types"
您可能可以使用来自 Coffescript 的类似策略。
【讨论】：
很高兴看到您解决了问题。无论如何，下次你遇到 Redis 的内存问题时，你的第一个调用端口应该是“INFO”redis 命令。这个命令会告诉你有价值的信息，比如
used_memory:3223928 used_memory_human：3.07M used_memory_rss:1916928 used_memory_peak:3512536 used_memory_peak_human：3.35M used_memory_lua:37888 mem_fragmentation_ratio:0.59
或者
db0:keys=282,expires=27,avg_ttl=11335089640
这对于在任何给定时刻了解您的内存和键空间的状态非常方便。
【讨论】：
事实上，问题出在旧版本的节点上。升级到 0.6.x 链解决了内存消耗问题。
【讨论】：