我是RabbitMQ之类的消息代理的新手，我们可以使用它来为像Celery这样的调度系统创建任务/消息队列 .
现在，问题是：
-
我可以在PostgreSQL中创建一个表，它可以附加新任务并由消费者程序（如Celery）使用 .
-
为什么我想为RabbitMQ设置一个全新的技术？
现在，我认为扩展不能成为答案，因为像PostgreSQL这样的数据库可以在分布式环境中工作 .
我搜索了数据库为特定问题提出的问题，我发现：
-
轮询使数据库忙碌且性能低下
-
锁定表 - >再次表现不佳
-
数百万行任务 - >再次轮询是低性能的
现在，RabbitMQ或任何其他类似的消息代理如何解决这些问题？
另外，我发现 AMQP 协议就是它所遵循的 . 那有什么好处的？
Redis也可以用作消息代理吗？我发现它更类似于memcache然后是RabbitMQ .
请注意这个！
2 回答
PostgreSQL 9.5
PostgreSQL 9.5包含
SELECT ... FOR UPDATE ... SKIP LOCKED. 这使得实现工作排队系统变得更加简单和容易 . 您可能不再需要外部排队系统，因为它没有其他会话锁定的行，并保持锁定状态，直到您确认工作已完成为止 . 它甚至适用于需要外部协调的两阶段交易 .外部排队系统仍然有用，提供固定功能，经过验证的性能，与其他系统的集成，水平扩展和联合选项等 . 但是，对于简单的情况，您不再需要它们 .
旧版本
您不需要这样的工具，但使用它可以使生活更轻松 . 在数据库中进行排队看起来很简单，但是在实践中你会发现在关系数据库中很难做到高性能，可靠的并发排队 .
这就是为什么像PGQ这样的工具存在的原因 .
您可以使用
LISTEN和NOTIFY摆脱PostgreSQL中的轮询，但在现实世界中赢得了't solve the problem of reliably handing out entries off the top of the queue to exactly one consumer while preserving highly concurrent operation and not blocking inserts. All the simple and obvious solutions you think will solve that problem actually don'，并且倾向于退化为单工作程序队列提取的效率较低的版本 .如果您不需要高度并发的多工作队列提取，那么在PostgreSQL中使用单个队列表是完全合理的 .
Rabbit的队列驻留在内存中，因此比在数据库中实现它要快得多 . （好的）专用消息队列还应提供基本的排队相关功能，例如限制/流量控制，以及选择不同路由算法的能力，以命名一对（兔子提供这些和更多） . 根据项目的大小，您可能还希望将消息传递组件与数据库分开，这样，如果一个组件负载过重，则无需阻碍其他组件的操作 .
至于你提到的问题：
polling keeping the database buzy and low performing ：使用Rabbitmq， 生产环境 者可以将更新推送给消费者，这比投票更有效 . 数据只需在需要时发送给消费者，无需进行浪费的检查 .
locking of the table -> again low performing: 没有要锁定的表：P
millions of rows of task -> again polling is low performing: 如上所述，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/