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

作者: 天线宝宝
发布时间: 2023-12-17 12:36:28 (7月前)
转自：

3 条回复

0#
回复此人
google你他吗 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> Rabbit的队列驻留在内存中，因此比在数据库中实现它要快得多。（好的）专用消息队列还应提供基本的排队相关功能，例如限制/流量控制，以及选择不同路由算法的能力，以命名一对（兔子提供这些和更多）。根据项目的大小，您可能还希望将消息传递组件与数据库分开，这样，如果一个组件负载过重，则无需阻碍其他组件的操作。 至于你提到的问题： <UL> <LI> 的 轮询保持数据库buzy和低性能 </强> ：使用Rabbitmq，生产者可以 推 消费者的更新，其性能远远高于民意调查。数据只需在需要时发送给消费者，无需进行浪费的检查。 </LI> <LI> 的 锁定桌子 - ＆gt;再次低绩效： </强> 没有桌子可以锁定：P </LI> <LI> 的 数百万行任务 - ＆gt;再次轮询表现不佳： </强> 如上所述，Rabbitmq在驻留RAM时运行速度更快，并提供流量控制。如果需要，它还可以使用磁盘临时存储消息（如果RAM用完）。在2.0之后，Rabbit的RAM使用率显着提高。群集选项也可用。 </LI> </UL> 关于AMQP，我想说一个非常酷的功能是“交换”，以及它能够路由到其他交易所。这为您提供了更大的灵活性，使您能够创建各种精心设计的路由类型，这些类型在扩展时非常方便。举个好例子，请看： <a href="http://blog.springsource.com/wp-content/uploads/2011/04/routing-topology.png"> http://blog.springsource.com/wp-content/uploads/2011/04/routing-topology.png </A> 和： <a href="http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/"> http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/ </A> 最后，关于redis，是的，它可以用作消息代理，并且可以做得很好。但是，Rabbitmq具有比redis更多的消息队列功能，因为rabbitmq是从头开始构建的，是一个功能齐全的企业级专用消息队列。另一方面，Redis主要是为了成为一个内存中的键值存储（尽管它现在做得比现在多得多;它甚至被称为瑞士军刀）。尽管如此，我已经阅读/听过很多人用Redis为小型项目取得了不错的成绩，但在较大的应用程序中却没有听到太多关于它的信息。 以下是在长轮询聊天实现中使用redis的示例： <a href="http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/"> http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/ </A> </DIV>

编辑
1#
回复此人
啊这回彻底死了 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <H2> PostgreSQL 9.5 </H2> PostgreSQL 9.5合并 <code> SELECT ... FOR UPDATE ... SKIP LOCKED </code> 。这使得实现工作排队系统成为可能 批量 更简单，更容易。您可能不再需要外部排队系统，因为现在可以轻松获取其他会话未锁定的“n”行，并保持锁定直到您确认工作已完成为止。它甚至适用于需要外部协调的两阶段交易。 外部排队系统仍然有用，提供固定功能，经验证的性能，与其他系统的集成，水平扩展和联合选项等。但是，对于简单的情况，您不再需要它们。 <H2> 旧版本 </H2> 你没有 需要 这样的工具，但使用一个可以使生活更轻松。在数据库中进行排队看起来很简单，但在实践中你会发现高性能，可靠的并发排队 真的很难 在关系数据库中做正确的事。 这就是为什么这样的工具 <a href="http://wiki.postgresql.org/wiki/PGQ_Tutorial"> PGQ </A> 存在。 您可以使用在PostgreSQL中删除轮询 <code> LISTEN </code> 和 <code> NOTIFY </code> ，但这不能解决将队列顶部的条目可靠地分发给一个消费者同时保留高度并发操作而不是阻塞插入的问题。您认为解决该问题的所有简单明了的解决方案实际上并不是在现实世界中，而是倾向于退化为单工作者队列提取的低效版本。 如果您不需要高度并发的多工作队列提取，那么在PostgreSQL中使用单个队列表是完全合理的。 </DIV>

编辑

登录后才能参与评论