为什么我们需要像PostMSQL这样的数据库上的RabbitMQ等消息代理？

Question

我是RabbitMQ之类的消息代理的新手，我们可以使用它来为Celery等调度系统创建任务/消息队列。

现在，问题是：

• 我可以在PostgreSQL中创建一个表，该表可以附加新任务并由消费者程序（如Celery）使用。

• 为什么我要为RabbitMQ设置一个全新的技术？

现在，我认为扩展不能成为答案，因为像PostgreSQL这样的数据库可以在分布式环境中工作。

我搜索了数据库为特定问题提出的问题，我发现：

• 轮询使数据库忙碌且性能低下
• 锁定桌子 - ＆gt;再次表现不佳
• 数百万行任务 - ＆gt;再次，民意调查表现不佳

现在，RabbitMQ或其他任何类似的消息代理如何解决这些问题？

另外，我发现AMQP协议就是它所遵循的。那有什么好处？

Redis也可以用作消息代理吗？我觉得它比Memcached更像是RabbitMQ。

请对此有所了解！

Answer 1

Rabbit的队列驻留在内存中，因此比在数据库中实现它要快得多。 （好的）专用消息队列还应提供基本的排队相关功能，例如限制/流量控制，以及选择不同路由算法的能力，以命名一对（兔子提供这些和更多）。根据项目的大小，您可能还希望将消息传递组件与数据库分开，这样，如果一个组件负载过重，则无需阻碍其他组件的操作。

至于你提到的问题：

• 轮询使数据库保持忙碌且性能低下：使用Rabbitmq，生产者可以向消费者推送更新，这比消息更有效。数据只需在需要时发送给消费者，无需进行浪费的检查。

• 锁定表格 - ＆gt;再次表现不佳：没有要锁定的表：P

• 数百万行任务 - ＆gt;再次轮询是低性能的：如上所述，Rabbitmq在驻留RAM时运行速度更快，并提供流量控制。如果需要，它还可以使用磁盘临时存储消息（如果RAM用完）。在2.0之后，Rabbit的RAM使用率显着提高。聚类选项也可用。

关于AMQP，我会说一个非常酷的功能是“交换”，以及它能够路由到其他交易所。这为您提供了更大的灵活性，使您能够创建各种精心设计的路由类型，这些类型在扩展时非常方便。有一个很好的例子，请参阅：

http://blog.springsource.com/wp-content/uploads/2011/04/routing-topology.png

和：http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

最后，关于redis，是的，它可以用作消息代理，并且可以做得很好。但是，Rabbitmq具有比redis更多的消息队列功能，因为rabbitmq是从头开始构建的，是一个功能齐全的企业级专用消息队列。另一方面，Redis主要是为了成为一个内存中的键值存储（尽管它现在做得比现在多得多;它甚至被称为瑞士军刀）。尽管如此，我已经阅读/听过很多人用Redis为小型项目取得了不错的成绩，但在大型应用程序中却没有听到太多关于它的信息。

以下是在长轮询聊天实现中使用redis的示例：http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/

Answer 2

PostgreSQL 9.5

PostgreSQL 9.5包含SELECT ... FOR UPDATE ... SKIP LOCKED。这使得实现工作排队系统 lot 更简单，更容易。您可能不再需要外部排队系统，因为现在可以轻松获取其他会话未锁定的“n”行，并保持锁定直到您确认工作已完成为止。它甚至适用于需要外部协调的两阶段交易。

外部排队系统仍然有用，提供固定功能，经验证的性能，与其他系统的集成，水平扩展和联合选项等。但是，对于简单的情况，您不再需要它们了。

旧版本

你不需要这样的工具，但使用它可以让生活更轻松。在数据库中进行排队看起来很简单，但是在实践中你会发现，在关系数据库中，高性能，可靠的并发排队是非常难的。

这就是PGQ之类的工具存在的原因。

您可以使用LISTEN和NOTIFY摆脱PostgreSQL中的轮询，但这无法解决在保留时将条目顶部的条目可靠地分发给一个消费者的问题高度并发操作而不是阻塞插入。您认为解决该问题的所有简单明了的解决方案在现实世界中实际上并不存在，并且倾向于退化为单工作者队列提取的低效版本。

如果您不需要高度并发的多工作队列提取，那么在PostgreSQL中使用单个队列表是完全合理的。