问题描述
我是消息代理之类的新手，例如 RabbitMQ ，我们可以使用它来创建任务/消息队列以进行调度这样的系统，如芹菜.
I am new to message brokers like RabbitMQ which we can use to create tasks / message queues for a scheduling system like Celery.
现在，这是一个问题:
-
我可以在 PostgreSQL 中创建一个表，该表可以附加新任务并由消费者程序，例如Celery.
I can create a table in PostgreSQL which can be appended with new tasks and consumed by the consumer program like Celery.
为什么我要为此设置像RabbitMQ这样的全新技术?
Why on earth would I want to setup a whole new tech for this like RabbitMQ?
现在，我认为扩展无法解决问题，因为我们的数据库(如PostgreSQL)可以在分布式环境中工作.
Now, I believe scaling cannot be the answer since our database like PostgreSQL can work in a distributed environment.
我搜索了数据库针对特定问题带来的问题，然后发现:
I googled for what problems does the database poses for the particular problem, and I found:
- 轮询使数据库忙碌且性能低下
- 锁定表->再次表现不佳
- 数以百万计的任务行->再次，轮询的效果不佳
现在，RabbitMQ或类似的其他任何消息代理如何解决这些问题?
Now, how does RabbitMQ or any other message broker like that solves these problems?
此外，我发现遵循的是AMQP协议.这样做有什么好处?
Also, I found out that AMQP protocol is what it follows. What's great in that?
Redis 也可以用作消息代理吗?我发现它比RabbitMQ更类似于Memcached.
Can Redis also be used as a message broker? I find it more analogous to Memcached than RabbitMQ.
请对此有所说明！
推荐答案
兔子的队列驻留在内存中，因此比在数据库中实现它要快得多.一个(好的)专用消息队列还应该提供与队列相关的基本功能，例如节流/流控制，以及选择不同路由算法的能力，以成对命名(兔子提供了这些以及更多功能).根据项目的大小，您可能还希望将消息传递组件与数据库分开，这样，如果一个组件承受沉重的负担，就不必阻碍另一个组件的操作.
Rabbit's queues reside in memory and will therefore be much faster than implementing this in a database. A (good)dedicated message queue should also provide essential queueing related features such as throttling/flow control, and the ability to choose different routing algorithms, to name a couple(rabbit provides these and more). Depending on the size of your project, you may also want the message passing component separate from your database, so that if one component experiences heavy load, it need not hinder the other's operation.
关于您提到的问题:
-
轮询，使数据库忙碌且性能低下:使用Rabbitmq，生产者可以 push 向消费者更新，这比轮询性能要好得多.只需在需要时将数据发送给消费者，从而无需进行浪费的检查.
polling keeping the database buzy and low performing: Using Rabbitmq, producers can push updates to consumers which is far more performant than polling. Data is simply sent to the consumer when it needs to be, eliminating the need for wasteful checks.
锁定表->再次表现不佳:没有要锁定的表:P
locking of the table -> again low performing: There is no table to lock :P
数百万行任务->轮询仍然表现不佳:如上所述，Rabbitmq驻留在RAM上将运行得更快，并提供流控制.如果需要，它还可以使用磁盘临时存储消息(如果RAM不足).在2.0之后，Rabbit的RAM使用率有了显着提高.群集选项也可用.
millions of rows of task -> again polling is low performing: As mentioned above, Rabbitmq will operate faster as it resides RAM, and provides flow control. If needed, it can also use the disk to temporarily store messages if it runs out of RAM. After 2.0, Rabbit has significantly improved on its RAM usage. Clustering options are also available.
关于AMQP，我想说一个非常酷的功能是交换"，以及它路由到其他交易所的能力.这为您提供了更大的灵活性，并使您能够创建各种精心设计的路由类型，这些扩展类型在扩展时非常有用.举一个很好的例子，请参见:
In regards to AMQP, I would say a really cool feature is the "exchange", and the ability for it to route to other exchanges. This gives you more flexibility and enables you to create a wide array of elaborate routing typologies which can come in very handy when scaling. For a good example, see:
最后，关于redis，是的，它可以用作消息代理，并且可以做得很好.但是，Rabbitmq比redis具有更多的消息排队功能，因为Rabbitmq是从头开始构建的，是功能全面的企业级专用消息队列.另一方面，Redis最初主要是创建为内存中的键值存储(尽管它的功能远不止现在；它甚至被称为瑞士军刀).尽管如此，我已经阅读/听说过很多人使用Redis在较小的项目中取得了良好的效果，但是在大型应用程序中却没有听到太多的信息.
Finally, in regards to redis, yes, it can be used as a message broker, and can do well. However, Rabbitmq has more message queuing features than redis, as rabbitmq was built from the ground up to be a full-featured enterprise-level dedicated message queue. Redis on the other hand was primarily created to be an in-memory key-value store(though it does much more than that now; its even referred to as a swiss army knife). Still, I've read/heard many people achieving good results with Redis for smaller sized projects, but haven't heard much about it in larger applications.
以下是在长时间轮询的聊天实现中使用redis的示例: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/
Here is an example of redis being used in a long-polling chat implementation: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/
这篇关于为什么我们需要像PostgreSQL这样的数据库就需要像RabbitMQ这样的消息代理?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！