Доступ к сообщениям обмена, отправленным до того, как очередь связана

Question

У меня есть вопрос относительно third RabbitMQ tutorial. Я пытаюсь реализовать что-то подобное, за исключением того, что нет гарантии, что потребитель (ы) будет работать в то время, когда производитель отправляет сообщение на биржу.

Итак, у меня есть продюсер, который публикует сообщения в обмен разветвления:

$channel->exchange_declare('my_exchange', 'fanout', false, false, false); 
$channel->basic_publish('my_message', 'my_exchange'); 

В моих издателей, я объявляю очереди, которые я затем связываются с обменом:

list($queueName,,) = $channel->queue_declare("", false, false, true, false); 
$channel->queue_bind($queueName, 'my_exchange'); 

И это то, где моя проблема имеет корень. В учебнике говорится:

Сообщения будут потеряны, если нет очереди не связан с обменом еще, , но это нормально для нас; если потребитель не слушает, мы можем безопасно отказаться от сообщения.

Есть ли способ как-то сохранить эти сообщения, поэтому при запуске потребителя он будет обращаться к ранее отправленным сообщениям? Единственный способ выяснить, как это сделать, - объявить ту же очередь у моего продюсера и моего издателя, но это как бы поражает цель обмена и отдельных очередей для разных потребителей.

Answer 1

Очереди должны существовать, не имеет значения, действительно ли кто их создает: он может быть производителем (althoug я бы сильно отговаривал это), потребитель, третье приложение администратора, которое просто создает queus через rest api, rabbitmqctl. .. Если вы хотите позже использовать очереди, просто убедитесь, что они долговечны и что TTL для сообщений достаточно длинный (также, если необходимо, длительные сообщения). Но будьте осторожны, чтобы ваша очередь не попала в состояние потока.

Единственный способ, которым я понял, как сделать это, чтобы объявить ту же очередь в моем продюсера и моего издателя, но это своего рода поражения цели , имеющий обмен и отдельные очереди для различных потребителей.

Во-первых - я думаю, что ты хотел сказать in my producer and my subscriber :)
Во-вторых, отдельные очереди для потребителей (или очередь на потребителя) только в этом примере. Загадайте, что это для обмена разветвлением, и каждый потребитель декалирует эксклюзивную очередь - когда потребитель отключается, очередь исчезает. И вот почему that's okay for us, потому что мы просто вещаем и хотим, чтобы трансляция (сообщения) должна была ее получить. Обмен Fanout просто помещает сообщения во все очереди, привязанные к нему, вот и все.
Вполне нормально, что несколько потребителей потребляют одну и ту же очередь (look at tutorial 2).

Таким образом, вам просто нужно рассмотреть ваш прецедент. Конечно, нет смысла создавать обмен разветвления и предварительно настроить очередь для потребителей ...Возможно, вам нужны только некоторые клавиши маршрутизации или что-то еще.

В этом примере (так, учебник 3) говорится, что есть брод-рассылка сообщений, и если никто их не получает, это не большая (или маленькая) сделка. Если кто-то хочет их, им нужно их получить. Это похоже на телевизионный канал - независимо от того, смотрит кто-то или нет, сигнал продолжается.

Answer 2

Потребители должны присоединяться к очередям, они не должны объявлять свои очереди. Подумайте о очередях в качестве ведра работы. В зависимости от рабочей нагрузки вы можете добавить N потребителей в эти очереди для выполнения работы.

Когда вы создаете обмен, у вас должна быть одна или несколько очередей (ведра работы), которые привязаны к этому обмену. Если вы это сделаете, сообщения перейдут в очереди и начнут стоять в очереди (прошу прощения за каламбур). Затем ваши потребители могут прикрепляться, когда они готовы, и начать выполнять работу.