我们有一个很大的项目即将推出，其中很多媒体处理（图像，视频）以及电子邮件输出等，通常我们会把这些东西放到一个叫做“email_queue”，我们使用cron来运行脚本处理表中的队列。消息队列与数据库表队列通过CRON
我一直在阅读很多Message Queue系统，比如beanstalkd，甚至已经设置了它。使用起来很简单而且很好用，问题是我不确定我是否缺少一些东西。
有人可以详细说明使用队列系统而不是表和CRON的好处吗？因为我真的看不到他们是什么。
由于
消息队列（至少一个分布式之一，例如RabbitMQ）给出您跨物理节点分发工作的能力。您仍然需要在每个节点上拥有一个进程，以使工作出列和处理。
它最终得到您的要求，我猜。您可以使用消息队列大规模地实现更易于管理的解决方案：您可以更轻松地解耦您的节点。
当然，有一条学习曲线......所以它再次回到你的目标。
注意，每个节点上你仍然可以重用的cron/db表，直到（如果）你想改变的执行情况。 当你可以时，这就是解耦的好方法。
差异：
一旦消息被放在可以立即传送队列中。因此，如果您的cron通常每5分钟运行一次，您可以通过排队更快地处理。
如果您的排队系统支持交易，那么如果处理失败，它将自动重新发送消息。
查询队列中的内容可能比较困难。数据库表有很好的搜索方式（sql）。
如果您有多个处理消息的服务器/进程/线程，队列系统将确保消息仅传递给其中一个消息。随着数据库的表，你需要通过应用程序代码来处理这个（锁定，标志等）
伟大的观点，在我看来更好的答案。 – 2013-03-26 18:03:42
首先，队列往往是由实际的数据库表支持，并能保持消息的耐用性。除此之外，队列是推动需要异步完成的工作的一种自然方式，如果您从一开始就对该主体进行设计的话非常强大。
除了表（实体）具有一组硬盘（属性）的事实以外，该表由一组记录组成以及一个队列组成，只不过是您正在使用的东西列表队列作为一个正式的队列，只是你正在按常规（cron）轮询它。
MQ通过一般同步对消息本身的访问（您可能会或可能不会在您的SQL中执行此操作来获取下一个内容）来添加另一个漂亮功能。
我喜欢将cron/table机制视为基于POLL的，而将MQ视为基于EVENT的机制。
好处在我看来是一个队列，它负责同步，状态更新。 MQ可以设置为“广播”（主题）或将消息提供给一组消费者或听众。
尽管异步MQ可能会在您的cron窗口之间运行。您如何知道在您的表中处理的消息数量可以在下一个cron作业运行之前完成并尝试执行之前的作业？
MQ的多个消费者允许您根据需要调整工作。在上面的示例中，如果您看到load average（与操作系统的进程队列中的值相同）超出您的喜好，您可以配置其他使用者来处理所述负载，并根据指标的需求将其加载和离线。
MQ可以设置为具有不同的操作参数，例如消息优先级和性能（某些队列可以保留在内存中，其他队列可以保留到磁盘）。
缺点是（如前所述）队列有时可能很难查询和获取度量。我总是发现拥有数据库后备存储的MQ系统，这样我就可以使用SQL监视队列。
这会得到相当频繁的询问，而且如果您对数据库感到满意，通常不会有令人信服的理由。 Here's one example thread。
我的意思是，你可能想要避免学习曲线，除非你的数据需求包括特别高的数量，如果你是cron而不是一个具有计时器的进程，这是不太可能的（更不用说带定时器的多进程）。
嗨，我有点理解，但不能用table/cron做同样的事情，远程连接数据库并在另一台机器上运行cron？ – Bowen 2009-12-03 15:37:37
你当然可以，但这似乎是一个更“耦合的解决方案”。采用消息队列方法，对于节点实现而言，您更加脱钩。这可能是一件好事。 – jldupont 2009-12-03 15:38:59
耦合使用它使用格式为y的数据库x，或者因为它使用格式为b的队列a？很好的问题@bowen。 – graffic 2010-10-09 20:50:18