问题标签 [pika]

我一直试图弄清楚在使用 pika 时应该使用哪种连接形式，据我所知，我有两种选择。

无论是BlockingConnection还是SelectConnection，但我不太确定这两者之间的区别（即 BlockingConnection 阻塞是什么？等等）

的文档pika说这SelectConnection是连接到 rabbit 的首选方式，因为它提供了“多种事件通知方法，包括 select、epoll、kqueue 和 poll。”

所以我想知道这两种不同类型的连接有什么含义？

PS：我知道我不应该在标题中添加标签，但在这种情况下，我认为它确实有助于澄清问题。

当您生成消息并在未声明队列或在 basic_publish 中提及它的情况下发送消息时，消息存储在哪里（在 rabbit 中）？我必须使用的代码如下所示：

我已经通过网络查看了我的能力，但还没有找到答案。我有一种预感，只要这条消息没有被消费，兔子就会创建一个队列，我担心如果兔子必须声明这个队列然后销毁它几个（数千！？）每分钟/小时的次数。

我浏览了有关rabbitmq的教程，发现它很有用。

但我找不到说明如何使用 pika 通过 rabbitmq 发送文件的文档。

代码示例是首选，pika 以外的其他库也可以接受。

鉴于 rabbitmq 实现了流控制，这可能会减慢一些消息发布速度，如何使用超时。另外，由于 pika 也没有实现发布者确认，所以推荐使用哪种语言和库来发布代码

我正在编写一个 python 客户端来接受来自 RabbitMQ 代理的作业消息并处理作业，将结果返回到另一台服务器。我的向 RabbitMQ 代理发送消息的脚本启动良好，但我的工作人员在运行 channel.declare_queue(queue='task_queue') 时抛出以下错误

pika.exceptions.AMQPChannelError：（406，“PRECONDITION_FAILED - vhost '/' 中队列 'task_queue' 的参数不等效”）

客户：

与 RabbitMQ 交互的服务器方法：

非常感谢任何帮助或见解。

编辑：我发现了上面列出的代码出现错误的原因。我在发布消息时指定了 delivery_mode=2，但是当我声明队列时，我忘记添加 Durable=True 参数。

我一直在做一个使用 rabbitmq 进行交流的项目。最近我们发现，如果我们使用兔子路由功能，它将具有很大的可扩展性。所以基本上我们将队列绑定到几个路由键并使用带有类型的交换direct。

它的工作方式类似于发布/订阅。因此可以将队列绑定和取消绑定到不同的事件，以便消费者/订阅者只接收他们感兴趣的消息。

当然，生产者/发布者现在使用绑定键（事件名称）将routing_key其传递给 pika 实现。但是，当它为不存在的绑定发布某些内容时，消息会丢失，即当没有人为 event 绑定队列时foo，但一些发布者调用了pika.basic_publish(..., routing_key='foo')。

所以我的问题是：

是否可以知道消息是否实际发布在队列中？

我试过的：

• 检查 pika.basic_publish 的返回值。它总是返回None。

• 检查当我们尝试为不存在的绑定发布时是否有异常。空无一人。

• 有一个额外的队列来进行带外控制（因为所有订阅者都由同一个进程运行）。这种方法对我来说并不理想。

附加信息

• 由于我正在使用此路由功能，因此队列名称是由 rabbit 生成的。如果新方法必须命名队列本身，我没有任何问题。

• 如果提出了一种需要绑定到交换而不是队列的新方法，我想听听它们，但我更愿意避免它们，因为它们实际上不是 AMQP，而是由 rabbitmq 实现的扩展。

• 鼠兔版本是 0.9.5

• rabbitmq 版本是 2.8

非常感谢

我有一个监听消息的消费者，如果消息流超过消费者可以处理的范围，我想启动这个消费者的另一个实例。

但我也希望能够从消费者那里轮询信息，我的想法是我可以使用 RPC 通过使用扇出交换从生产者那里请求这些信息，这样所有生产者都会得到 RPC 调用。

我的问题首先是这是否可能，其次是否合理？

我有一个 python 工作程序客户端，它启动了 10 个工作程序，每个工作程序连接到一个 RabbitMQ 队列。有点像这样：

我遇到的问题是，尽管在通道上设置了 basic_qos，但第一个启动的工作人员接受了队列外的所有消息，而其他工作人员则坐在那里闲置。我可以在 rabbitmq 界面中看到这一点，即使我设置worker_count为 1 并将 50 条消息转储到队列中，所有 50 条消息都进入“未确认”存储桶，而我希望 1 变为未确认，而其他 49 条消息准备好。

为什么这不起作用？

我遇到了 Pika 出现超时错误的问题。相同的代码（如下）在其他环境中工作正常，但在这个环境中失败。

rabbitmqctl状态

以前有人打过这个吗？我假设这是一个rabbitmq配置问题

我有一堆 celery 任务，它们获取结果并将它们发布到 RabbitMQ 消息队列。发布的结果可能会变得非常大（最多几兆）。关于在 RabbitMQ 消息中放入大量数据是否是一个好主意的观点参差不齐，但我在其他情况下看到了这种方法，只要控制内存，它似乎就可以工作。

但是，对于我当前的一组任务，rabbit 似乎只是在丢弃似乎太大的消息。我已将其简化为一个相当简单的测试用例：

我有一个 3 节点的 RabbitMQ 集群，以及mq.example.com每个节点的循环。客户端在 Ubuntu 12.04 上使用 Pika 0.9.5，RabbitMQ 集群在 Erlang R14B04 上运行 RabbitMQ 2.8.7。

执行此脚本会打印 print 语句并退出，不会引发任何异常。该消息永远不会出现在 RabbitMQ 中。

更改N为10000使其按预期工作。

为什么？