我们即将推出一个大型项目，其中包含大量媒体处理（图像、视频）以及电子邮件输出等，通常我们会将这些内容放入名为“email_queue”的表中，并且我们使用 cron运行脚本处理表中的队列。
我已经阅读了很多有关 beanstalkd 等消息队列系统的信息，甚至已经设置了它。它使用起来既简单又好用，问题是我不确定我是否遗漏了什么。
有人能详细说明使用队列系统而不是表和 CRON 的好处吗？因为我真的看不到它们是什么。
谢谢
【问题讨论】：
标签： message-queue beanstalkd starling-server
消息队列（至少是分布式的，例如RabbitMQ）使您能够跨物理节点分配工作。您仍然需要在每个节点上都有一个进程来使工作出队并进行处理。
我猜它最终会满足您的要求。您可以使用消息队列大规模实现更易于管理的解决方案：您可以更轻松地解耦节点。
当然，有一个学习曲线……所以它又回到了你的目标目标。
请注意，在每个节点上，您仍然可以重用您的 cron/db 表，直到（如果）您希望更改实现。 这就是在可能的情况下解耦的好处。
【讨论】：
区别：
一旦将消息放入队列，就可以立即传递。因此，如果您的 cron 通常每 5 分钟运行一次，您可以通过排队更快地处理。
如果您的排队系统支持事务，那么如果处理失败，它将自动重新发送消息。
查询队列中的内容可能会更加困难。数据库表有一种很好的搜索方式（sql）。
如果您有多个服务器/进程/线程处理消息，队列系统将确保仅将消息传递给其中一个。使用数据库表，您需要通过应用程序代码（锁定、标志等）处理此问题
【讨论】：
首先，队列通常由实际的数据库表支持，并且可以保持消息的持久性。除此之外，队列是一种自然的方式来推动需要异步完成的工作，如果您从一开始就按照该原则进行设计，那么它非常强大。
除了一个表（实体）有一组硬列（属性）之外，这个表由一组记录组成以及一个队列都只不过是你正在使用的东西列表queue-as-a-table 作为正式队列，只是您定期（cron）轮询它。
MQ 添加了另一个漂亮的特性，尽管通常同步对消息本身的访问（您可能会或可能不会在 SQL 中执行此操作以获取下一件事）。
我喜欢将 cron/table 机制视为基于 POLL，将 MQ 视为基于 EVENT。
我认为队列的好处是它负责同步、状态更新。 MQ 可以设置为“广播”（主题）或将消息提供给一组消费者或侦听器。
虽然异步可能会在您的 cron 窗口之间运行 MQ。你怎么知道你在表中处理的消息数量可以在下一个 cron 作业运行并尝试踩到上一个作业之前完成？
MQ 的多个使用者允许您根据需要扩展工作。在上面的示例中，如果您看到您的load average（与操作系统的进程队列中的相同）大于您的喜好，您可以配置另一个消费者来处理所述负载，根据指标需求将其打开和离线。
MQ 可以设置为具有不同的操作参数，例如消息优先级和性能（一些队列可以保留在内存中，其他队列可以保留在磁盘中）。
缺点是（如前所述）队列有时难以查询和获取指标。我总能找到具有 DB 后备存储的 MQ 系统，这样我就可以自己使用 SQL 观察队列。
【讨论】：
这个问题经常被问到，如果您对数据库感到满意，通常没有令人信服的理由去使用 MQ。 Here's one example thread.
我的看法是，您可能希望避免学习曲线，除非您的数据需求包括异常大量的数据，如果您是 cron 而不是带有计时器的进程（更不用说带有计时器的多个进程），这不太可能。
【讨论】：