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