何时使用 - 延迟作业与 RabbitMQ答案

【问题标题】：When to use - Delayed Job vs RabbitMQ何时使用 - 延迟作业与 RabbitMQ
【发布时间】：2019-05-26 04:24:24
【问题描述】：

有人可以告诉我使用 RabbitMQ（消息队列）而不是延迟作业（后台处理）的优势吗？

基本上我想知道什么时候使用后台处理和消息队列？

我的 Web 应用程序有 3 个组件，其中一个主服务器将处理所有用户请求，另一个应用服务器应该运行所有后台作业（如 es reindex、es 记录更新、发送电子邮件、crons）。

我看到文章说数据库作为队列（延迟作业）非常糟糕，因为消费者将轮询数据库以获取新作业并更新将锁定表的作业状态。那么rabbit MQ或者其他消息队列如何存储来避免这个问题。

延迟作业还有其他替代方案，例如 sidekiq，它将通过 redis 而不是 mysql 运行。用sidekiq代替rabbitmq更好吗？

与延迟作业相比，使用 sidekiq 有什么优势吗？

【问题讨论】：

第一个常见问题解答：github.com/mperham/sidekiq/wiki/FAQ
你说得对，数据库会使工作变慢。即使是 sidekiq 也必须为每个作业进行 3 次 Redis 往返。看看这个sneakers.io

标签： rabbitmq message-queue sidekiq delayed-job task-queue

【解决方案1】：

您有 2 个工作人员和 1 个 Web 服务器：我猜您的 Web 应用程序会向您的工作人员分派一些延迟的工作。因此，您需要一种方法来存储与这些后台作业相关的数据。

为此，您可以同时使用数据库（例如 Redis，这就是 Sidekick 正在做的事情）或消息队列（例如 RabbitMQ）。消息队列是一个专门的系统，对于这个用例非常有效（允许更高的吞吐量）。数据库会让你有更好的自省（因为你可以请求工作表来查看你当前的情况），而排队系统会更有效，但也更像是一个黑匣子，需要新的技能。

如果你没有性能问题，越简单越好，一个简单的mysql数据库就足够了。如果您想要一个更强大的系统或需要大量监控，您还可以考虑使用专门的托管服务，例如 zenaton（我是创始人），它将为您完成所有繁重的工作，包括调度或更复杂的编排你的后台工作。

【讨论】：

【解决方案2】：

两者都执行相同的任务，即在后台执行作业，但执行方式不同。

延迟作业使用某种数据库进行存储，然后查询作业然后处理它们。设置简单，但性能和可扩展性不是很好。

RabbitMQ 或其替代品 Redis 等 更难设置，但它们的性能、灵活性和可扩展性非常好，我们正在谈论每秒超过 5000 个作业你倾向于使用更少的代码。

【讨论】：

【解决方案3】：

另一种选择是使用像Cadence Workflow 这样的任务编排系统。它支持延迟执行和排队，但提供了更高级别的编程模型和大量既不排队也不延迟执行框架的功能。

与使用队列进行任务处理相比，Cadence 提供了许多优势。

内置指数重试，无限期间隔
故障处理。例如，如果在配置的时间间隔内两次更新都无法成功，它允许执行通知另一个服务的任务。
支持长时间运行的心跳操作
能够实现复杂的任务依赖。例如，在发生不可恢复的故障时实现调用链或补偿逻辑 (SAGA)
提供对当前更新状态的完整可见性。例如，当使用队列时，您知道队列中是否有一些消息，并且您需要额外的数据库来跟踪整体进度。使用 Cadence 记录每个事件。
能够取消正在进行的更新。
内置分布式 CRON

请参阅 the presentation，了解 Cadence 编程模型。

【讨论】：