我们即将推出一个大型项目，其中包含大量媒体处理（图像、视频）以及电子邮件输出等，通常我们会将这些内容放入名为“email_queue”的表中，然后使用 cron 运行脚本处理表中的队列。
我已经阅读了很多有关 beanstalkd 等消息队列系统的内容，甚至还进行了设置。它使用起来既简单又好用，问题是我不确定我是否遗漏了一些东西。
有人可以详细说明使用队列系统而不是表和 CRON 的好处吗？因为我真的看不到它们是什么。
谢谢
问问题
6791 次
4 回答
22
差异：
一旦消息被放入队列，它就可以立即被传递。因此，如果您的 cron 通常每 5 分钟运行一次，您可以通过排队更快地处理。
如果您的排队系统支持事务，那么如果处理失败，它将自动重新发送消息。
查询队列中的内容可能更难。数据库表有一种很好的搜索方式（sql）。
如果您有多个服务器/进程/线程处理消息，队列系统将确保消息仅传递给其中一个。使用数据库表，您需要通过应用程序代码（锁定、标志等......）来处理这个问题
于 2009-12-03T15:38:02.980 回答
6
消息队列（至少是分布式的，例如RabbitMQ）使您能够跨物理节点分配工作。您仍然需要在每个节点上都有一个进程来使工作出列并处理它。
我猜它最终会满足您的要求。您可以使用消息队列大规模实现更易于管理的解决方案：您可以更轻松地解耦节点。
当然，有一个学习曲线……所以它又回到了你的目标。
请注意，在每个节点上，您仍然可以重用您的 cron/db 表，直到（如果）您希望更改实现。 如果可以的话，这就是解耦的好处。
于 2009-12-03T15:36:20.283 回答
4
首先，队列通常由实际的数据库表支持，并且可以保持消息的持久性。除此之外，队列是一种自然的方式来推开需要异步完成的工作，如果你从一开始就按照该原则进行设计，那么它非常强大。
除了表（实体）具有一组硬列（属性）这一事实之外，该表由一组记录组成以及一个队列组成，只不过是您正在使用队列的东西列表-a-table 作为正式队列，只是您定期（cron）轮询它。
MQ 添加了另一个漂亮的特性，尽管通常同步对消息本身的访问（您可能会或可能不会在 SQL 中执行此操作以获取下一件事）。
我喜欢将 cron/table 机制视为基于 POLL，将 MQ 视为基于 EVENT。
在我看来，队列的好处是它负责同步、状态更新。MQ 可以设置为“广播”（主题）或将消息提供给一组消费者或侦听器。
尽管异步的 MQ 可能会在您的 cron 窗口之间运行。你怎么知道你在表中处理的消息数量可以在下一个 cron 作业运行并尝试踩到前一个作业之前完成？
MQ 的多个使用者允许您按您认为合适的方式扩展工作。在上面的示例中，如果您看到您的load average（在操作系统的进程队列中相同）大于您喜欢的，您可以配置另一个消费者来处理所述负载，根据指标需求将其打开和离线。
MQ 可以设置为具有不同的操作参数，例如消息优先级和性能（一些队列可以保留在内存中，其他队列可以保留在磁盘中）。
Downside is that (as already mentioned) that the queue can sometimes be hard to query and for which to obtain metrics. I always find MQ systems that have a DB backing store so that I can myself watch the queue with SQL.
于 2009-12-15T05:56:52.920 回答
1
This gets asked fairly frequently, and there's usually not a compelling reason to go MQ if you're comfortable with databases. Here's one example thread.
My take is that you might want to avoid the learning curve unless your data requirements include exceptionally high volumes, which is unlikely if you're thing cron rather than a process with a timer (much less multiple processes with timers.)
于 2009-12-15T06:04:44.340 回答