我在一个Node.js应用中使用BullMQ和 Redis。

我有一个用于同步任务的主队列：

const syncQueue = new Queue("sync", { connection: redis });

const syncWorker = new Worker("sync", async (job) => {
  // process sync job
}, { connection: redis });

现在我想在任务失败时支持重试。

我在两种方案之间感到困惑。

方案1：将失败的作业带延迟重新加入到同一个队列：

await syncQueue.add("inventory.sync", job.data, {
  delay: 5000,
});

方案2：创建一个单独的重试队列：

const retryQueue = new Queue("retry", { connection: redis });

await retryQueue.add("inventory.sync", job.data, {
  delay: 5000,
});

但如果我使用一个单独的重试队列，我还需要一个单独的工作进程来处理它：

new Worker("retry", async (job) => {
  // retry sync job
}, { connection: redis });

我的目标是：

• 重试失败的作业
• 通过管理员界面后续手动重试
• 将永久失败的作业移到死信队列
• 设计保持简单

对于BullMQ，是在同一个队列中使用延迟/退避来重试，还是创建一个单独的重试队列更好？

解决方案

对于BullMQ，我不会把创建单独的重试队列作为默认解决方案。

BullMQ已经在同一个队列中内置了重试支持，通过 attempts 和 backoff，因此我会把它建模为处理 sync 作业的一个逻辑队列，并让BullMQ来处理失败的尝试。

示例：

const syncQueue = new Queue("sync", {
  connection: redis,
  defaultJobOptions: {
    attempts: 5,
    backoff: {
      type: "exponential",
      delay: 5000,
    },
    removeOnComplete: true,
    removeOnFail: false,
  },
});

const syncWorker = new Worker(
  "sync",
  async (job) => {
    // process sync job
  },
  { connection: redis }
);

之所以设计更简单，是因为：

• 作业仍然停留在相同的逻辑队列中，
• BullMQ会保留尝试历史，
• 在所有尝试用尽后，失败的作业会进入失败状态，
• 延迟重试由BullMQ处理，而不是手动重新添加作业，
• 你不需要一个复制相同处理逻辑的第二个工作进程。

对于普通重试，我会避免使用这种模式：

await syncQueue.add("inventory.sync", job.data, {
  delay: 5000,
});

那样会创建一个新作业。在简单场景下它可能可行，但除非你手动保留元数据，如原始作业ID、尝试次数、错误原因等，否则你会丢失原作业的干净重试语义。

单独的重试队列只有在重试确实是一个不同的工作流时才有意义，例如：

• 重试必须由不同的工作进程处理，
• 重试需要更低的并发，
• 重试应与新作业隔离，
• 重试处理使用不同的基础设施，
• 你希望为重试作业建立一个单独的运营流水线。

就你提出的目标而言，我会使用：

1. 主要 sync 队列，配合 attempts 和 backoff，
2. 通过不立即移除来将耗尽的作业保留在失败状态，
3. 使用你的管理界面查看失败的作业并手动重试，
4. 如需专门的死信队列视图或保留策略，可以将永久失败的作业复制到单独的死信队列。

因此，实际答案是：

对普通重试，使用同一个队列并结合BullMQ的重试/退避机制。
只有当重试处理在运维上与普通处理不同的时候，才使用单独的重试队列。
只有那些已用尽重试且不应再自动处理的作业才使用死信队列。