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

Question

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

现在,问题是:

• 我可以在PostgreSQL中创建一个表,它可以附加新任务并由Celery等消费者程序使用.

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

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

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

• 轮询使数据库忙碌且性能低下
• 锁定表 - >再次表现不佳
• 数百万行任务 - >再次轮询是低性能的

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

此外,我发现AMQP协议是它所遵循的.那有什么好处的？

可以Redis的也可以用作消息代理？我发现它更类似于memcache然后是RabbitMQ.

请注意这个!

Answer 1

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

至于你提到的问题:

• 轮询保持数据库的buzy和低性能:使用Rabbitmq,生产者可以向消费者推送更新,这比轮询更高效.数据只需在需要时发送给消费者,无需进行浪费的检查.

• 锁定表 - >再次表现不佳:没有要锁定的表:P

• 数百万行任务 - >再次轮询效果不佳:如上所述,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.这使得执行工作的排队系统中很多简单和容易.您可能不再需要外部排队系统,因为现在可以轻松获取其他会话未锁定的"n"行,并保持锁定直到您确认工作已完成为止.它甚至适用于需要外部协调的两阶段交易.

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

旧版本

您不需要这样的工具,但使用它可以使生活更轻松.在数据库中进行排队看起来很容易,但是在实践中你会发现在关系数据库中很难做到高性能,可靠的并发排队.

这就是PGQ这样的工具存在的原因.

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

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