Никогда не понимал зачем нужны обои. Если я сижу за компом, то я чем-то занят, а не тупо пялюсь в рабочий стол. Поэтому черная заливка меня полностью устраевает.
Для большей гибкости и большей производительности можно из сервиса вычленить что-то типа summary_validator в котором останется логика по результатам валидаторов. И котороый при фейле будет слать киленту сразу феил в очередь replay_queue123, а если ок то — сервису, передавая очередь replay_queue123. Сервис, тогда будет всегда получать положительныей запросы и ничего ждать не будет.
Значит есть
Клиент — который хочет результат сервиса
Валидаторы — независимые раз-|| шматки кода
Сервис — который делает, что-то после валидаторов
В рамках ребита я б сделал так:
Сервисов много они слушают все 1 очередь service_queue(раунд робин)
Валидоторов много они слушают каждый свой тип очереди validator_typeN_queue(раундробин)
Клиент пораждает 2 временных очереди replay_queue123 и validates_queue123.
Кажому валидатору в котором он заинтересован шлет validates_queue123 и запрос в соотвествующую validator_typeN_queue.
Сервису через service_queue отсылает список валидаторов, которые были запущены, и обе временных очереди replay_queue123 и validates_queue123.
Начинает ожидать результат в replay_queue123
Валидатор сделав свое дело отсылает результат во временную очередь validates_queue123.
Сервис получив список валидаторов и очередь validates_queue123 подписывается на нее и ждет резалты. В нем реализуется вся логика. Получили 2 фейла стриаем очередь validates_queue123 шлем в replay_queue123 провал.
А ты хитрец.
Данные передются только средствами рэбита или можно хранить промежуточные значения в редисе например?
Почему имеено 2 НЕуспеха? Вроде бы любой отказ должен фейлить всю операцию.
Радость от rabbitmq, как раз в том, что можно писать разные части на разных языках. Зачем вы пишете на PHP?
Если у вас столь сложная бизнес логика, которая выходит за рамки rabbitmq, но вы очень любите PHP, велкам к zeromq. Будете разруливать любую ситуацию как вам угодно. В противном случае у вас будет огород из воркеров, часть из которых будут разруливать только потоки данных и будут узким местом.
То что вы описали это абстрактная проблема, возможно ее можно решить изменив потоки данных, например сваливать все во временные очереди и ждать из них.
как сделать, когда надо чтобы оба консумера получили мессадж
— Паб/саб реадихуется через fanout exchange
как сделать, когда надо чтобы строго один консумер из N возможных
— Для direct exchange это дефолтное поведение реализовано через round robin
как сделать, чтобы консумер выполнял действие, только получив сообщения из двух и более очередей
— Из коробки можно подписываться на сколько угодно очередей, выставив ручное подверждение и отправлять ack опираясь уже на вашу бизнес логику
Спрошу у вас.
Как мне перенести виртуальную машину с одного аккаунта на другой? При попытке скачать ее из контейнера закачка обрывается после того, как скачался 1Гб.
Хехе
Клиент — который хочет результат сервиса
Валидаторы — независимые раз-|| шматки кода
Сервис — который делает, что-то после валидаторов
В рамках ребита я б сделал так:
Сервисов много они слушают все 1 очередь service_queue(раунд робин)
Валидоторов много они слушают каждый свой тип очереди validator_typeN_queue(раундробин)
Клиент пораждает 2 временных очереди replay_queue123 и validates_queue123.
Кажому валидатору в котором он заинтересован шлет validates_queue123 и запрос в соотвествующую validator_typeN_queue.
Сервису через service_queue отсылает список валидаторов, которые были запущены, и обе временных очереди replay_queue123 и validates_queue123.
Начинает ожидать результат в replay_queue123
Валидатор сделав свое дело отсылает результат во временную очередь validates_queue123.
Сервис получив список валидаторов и очередь validates_queue123 подписывается на нее и ждет резалты. В нем реализуется вся логика. Получили 2 фейла стриаем очередь validates_queue123 шлем в replay_queue123 провал.
Данные передются только средствами рэбита или можно хранить промежуточные значения в редисе например?
Почему имеено 2 НЕуспеха? Вроде бы любой отказ должен фейлить всю операцию.
Если у вас столь сложная бизнес логика, которая выходит за рамки rabbitmq, но вы очень любите PHP, велкам к zeromq. Будете разруливать любую ситуацию как вам угодно. В противном случае у вас будет огород из воркеров, часть из которых будут разруливать только потоки данных и будут узким местом.
То что вы описали это абстрактная проблема, возможно ее можно решить изменив потоки данных, например сваливать все во временные очереди и ждать из них.
Давайте конкретные примеры решать?
Ну как же? fanout exchange как раз для ситуации 1 очередь получают все.
— Паб/саб реадихуется через fanout exchange
как сделать, когда надо чтобы строго один консумер из N возможных
— Для direct exchange это дефолтное поведение реализовано через round robin
как сделать, чтобы консумер выполнял действие, только получив сообщения из двух и более очередей
— Из коробки можно подписываться на сколько угодно очередей, выставив ручное подверждение и отправлять ack опираясь уже на вашу бизнес логику
Как мне перенести виртуальную машину с одного аккаунта на другой? При попытке скачать ее из контейнера закачка обрывается после того, как скачался 1Гб.