似乎使用Bull 3.21.1作为默认配置的工作队列将导致Redis在成功操作下无限期保留键，最终耗尽Redis的内存并导致崩溃。下面是一个例子。我也有同样的经历。这是另一个，其中解释了虽然Bull的默认行为不能在不引起现有用户破坏性更改的情况下实现无内存泄漏，但可以更好地记录默认行为将无限期地保留已完成作业的redis键，以及在redis中获得不泄漏内存的操作的配置是什么。在编写这个问题时，Bull的文档仍然没有提到此行为、配置点或解决方案。
由于Bull未记录的默认行为永久保留已完成作业的redis密钥，导致生产(或者更幸运的是，预生产)崩溃，我如何恢复?
- 如果可能的话，增加redis可用的内存来缓解内存压力。我们就是这么做的。
- 一个潜在的快速手动修复方法是在package中指定的NPM脚本中使用以下方法:
Bull.Queue#clean(1000 * 60 * 60 * 24)。Json，并在prod节点实例上运行。(参数是以毫秒为单位的宽限期，已完成的作业将不会被收集，因此该值将是超过24小时的作业。)我们只在下面的操作之后执行了此操作，以清除所有旧的作业，但可以更早地使用它来压缩气球并赢得更多时间。 - 通过向Bull:
defaultJobOptions: { removeOnComplete: true, removeOnFail: true }提供非默认配置来修复内存泄漏。这将结束redis公牛键计数和内存消耗的增加，并提供在默认配置和成功操作下没有内存泄漏的最不令人惊讶的行为。