C RabbitMQ не работал, поэтому задаю, может быть, дурацкий вопрос.
Схема такая:
Есть frontend на PHP, на котором чисто "бизнес".
Есть ODATA сервис (на JAVA), который является единым интерфейсом для работы с различными базами данных и кэшами. По сути "логика". При изменении, внесении или удалении данных, сервис генерирует сообщение, которое должно прийти к одному или нескольким консьюмерам. По сути триггерная работа.
Есть backend на JAVA, у которого много разных консьюмеров. Каждый консьюмер делает определенные вещи, как то: один генерирует PDF, другой считает биллинг, третий рассылает почту, четвертый заливает файлы в облако, и т.д.
Стоят задачи:
1. Все сообщения должны быть обработаны и отправлен ACK.
2. Все сообщения должны быть DURABLE.
3. При отправке сообщения двум или более консьюмерам, ото всех должен быть получен ACK. (вот тут я вот не понимаю как работает или как реализовать правильно)
1. Правильно ли я понимаю, что для каждого консьюмера логично определить свою очередь, например:
billing
mailing
cloud
pdf
и т.д.
?
2. Сообщения удобней отправлять через шаблоны? Как их лучше именовать?
0. Одно и то же сообщение не может быть доставлено одновременно двум консьюмерам. Это могут быть сообщения с одинаковым содержимым, но для системы это будут разные сообщения.
1. Да это логично. Отдельная очередь под отдельную задачу позволит изменять количество обработчиков в зависимости от загрузки по каждой задаче в отдельности.
2. Вот тут не понял. Имеется ввиду routing_key ?
3. Есть 3 встроенных типа обменника. Лучше выбрать тот, который больше подходит по задаче, но надо учитывать что у них разная пропускная способность (вот, нашел статью - https://habrahabr.ru/company/oleg-bunin/blog/310418/)
0. То есть 1 задача - 1 сообщение. Я думал через обменник можно раскидать по нескольким очередям и с каждой очереди ждать ACK.
1. В моем случае к очереди будет подключен только 1 консьюмер. Пока.
2. Тут я сам понять не могу. Везде в статьях и мануалах разные наименования и не понятно имеется в виду одно и тоже или же это разные вещи. Я про эту картинку и
3. Я точно знаю, что не нужен FANOUT, но пока не могу определиться для моего случая это будет TOPIC или DIRECT. Про пропускную способность в курсе. Но для данной задача она не первоочередная задача.
при коннекте консьюмера вижу что на MQ создалась очередь для этого консьюмера.
также при коннекте консьюмер не получает старые отправленные сообщения, а начинает получать только когда приходят новые.
1. Через обменник можно раскидать одно сообщение на много очередей - либо используя fanout тип обменника - тогда сообщение попадет во все очереди одновременно, либо по шаблону routing key (тип - topic) - тогда сообщение попадет во все очереди, где шаблон подписки (routing key) соответствует routing key сообщения. Direct обменник - сообщение попадет только в ту очередь, название которой соответствует routing key.
2. На картинке как раз показано, что одна очередь привязана к обменнику 2 раза по разным routing key
3. ИМХО, если пропускная способность не важна - рекомендую взять сразу topic - он может работать как fanout и direct в зависимости от настройки подписки.
Отправляю в очередь сообщения. Консьюмеров нет.
Включаю консьюмера, он не видит старые сообщения, и получает только новые.
А есть ли очередь? И сообщение точно отправилось? Даже если нет обработчиков, все-равно сообщения в очереди должны накапливаться...
Если отправить сообщение в обменник и он не будет знать куда деть это сообщение (не привязано никакой очереди) то сообщение пропадет.
Обменник не может накапливать сообщения.
Простой
Простой
Средний
