为什么我们需要像RabbitMQ这样的消息代理,而不是像PostgreSQL这样的数据库?

我不熟悉RabbitMQ这样的消息代理,我们可以使用它为芹菜这样的调度系统创建任务/消息队列

现在,问题是:

  • 我可以在PostgreSQL中创建一个表,该表可以附加新任务,并被消费程序(如芹菜)使用

  • 我到底为什么要为这个像RabbitMQ一样建立一个全新的技术

现在,我相信扩展并不是答案,因为像PostgreSQL这样的数据库可以在分布式环境中工作

我在谷歌上搜索数据库对特定问题造成的问题,发现:

  • 轮询使数据库繁忙且性能低下
  • 锁定表->再次执行低性能
  • 数百万行任务->同样,轮询性能低下

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

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

Redis也可以用作消息代理吗?我发现它比RabbitMQ更类似于Memcached

请解释一下

Rabbit的队列驻留在内存中,因此比在数据库中实现要快得多。(好的)专用消息队列还应提供与队列相关的基本功能,如节流/流量控制,以及选择不同路由算法的能力(rabbit提供了这些和更多)。根据项目的大小,您可能还希望消息传递组件与数据库分开,这样,如果一个组件负载过大,就不需要妨碍另一个组件的操作

关于你提到的问题:

  • 轮询保持数据库繁忙且性能低下:使用Rabbitmq,生产者可以向消费者推送更新,这比轮询性能好得多。数据只需在需要时发送给消费者,无需进行浪费性检查

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

  • 数百万行任务->轮询的性能同样很低:如上所述,Rabbitmq驻留在RAM中并提供流控制,因此运行速度更快。如果需要,如果内存不足,它还可以使用磁盘临时存储消息。2.0之后,Rabbit的RAM使用率有了显著提高。集群选项也可用

关于AMQP,我想说一个非常酷的特性是;交换;,以及它通往其他交易所的能力。这为您提供了更大的灵活性,并使您能够创建一系列复杂的布线类型,这些类型在扩展时非常方便。有关良好的示例,请参见:

(来源:springsource.com)

以及: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/

发表评论