Можно и так сказать) кто-то пруфа юзает, кто-то свои велосипеды

тут только на основе принятых веществ можно делать)

просто видел broadway, мало ли серебряную пулю отлили

Мне бродвей не понравился

Можно и так сказать) кто-то пруфа юзает, кто-то свои велосипеды

а разве есть стейбл верися пруфа?

а разве есть стейбл верися пруфа?

Хз

у меня свой велосипед, который устраивает полностью. так что всякие пруфы, бродвеи и т.д. не нужны. Можно посматривать в ожидании светлых идей, но не более

тогда сага по разбору с кастомерами (возможно даже 2), сага по инвойсу и сага по платежу (одна на всех)

ну кароч, я понял - вместо композиции декораторов, композиция саг

страшно как-то звучит)

ну получается как, одна сага может порождать другую?

может

а страшно, это то что у меня сейчас)

не, страшно - это обеспечить консистентность надцати саг

наркомания кароч

ну там не так много кейсов когда их нужно синхронизировать - разве что успешный и крайний не успешный кейсы

когда уже сделали ретрай и уже ничему не помочь

ну, раз всё та просто, дерзай)

@thatside halp

оно само должно

Похоже, у кого-то прилег вебхук

сорян, я удалил(

Привет. Растолкуйте пожалуйста про очереди (RabbitMQ), не могу догнать. Код на РНР является Producer-ом для очереди - добавляет в нее задачи. Сторонний код является Consumer-ом и выполняет эти задачи. В простом варианте, когда это задачи, скажем, на рассылку почты или уменьшение размера изображений, тут всё кажется понятным: мой код на РНР добавил задачу в очередь и забыл про нее. Сторонний код получил задачу из очереди и обработал ее. Но в варианте, в котором нужно получить результат задачи, я что-то не могу разобраться чисто архитектурно. Например, мой код на РНР кидает в очередь задачу, подписчик должен ее выполнить и вернуть результат работы поставщику (моему коду). Каким способом этот возврат результатов реализуется? Есть ли в RabbitMQ какие-то средства для этого или же результат работы должен передаваться используя другую очередь, скажем, для результатов, в которой сторонний код, исполняющий задачу, будет в роли поставщика, а мой код на РНР будет в роли подписчика? Подскажите пожалуйста, а то что-то в этом месте образовался пробел в понимании работы.

pub\sub, command, event Продюсер пишет команду: - сделай заебись - консамер всё сделал, кидает эвент что такая-то задача выполнена. кому нужен результат подписывается на получение этого сообщения (эвента) и ждёт

Привет. Растолкуйте пожалуйста про очереди (RabbitMQ), не могу догнать. Код на РНР является Producer-ом для очереди - добавляет в нее задачи. Сторонний код является Consumer-ом и выполняет эти задачи. В простом варианте, когда это задачи, скажем, на рассылку почты или уменьшение размера изображений, тут всё кажется понятным: мой код на РНР добавил задачу в очередь и забыл про нее. Сторонний код получил задачу из очереди и обработал ее. Но в варианте, в котором нужно получить результат задачи, я что-то не могу разобраться чисто архитектурно. Например, мой код на РНР кидает в очередь задачу, подписчик должен ее выполнить и вернуть результат работы поставщику (моему коду). Каким способом этот возврат результатов реализуется? Есть ли в RabbitMQ какие-то средства для этого или же результат работы должен передаваться используя другую очередь, скажем, для результатов, в которой сторонний код, исполняющий задачу, будет в роли поставщика, а мой код на РНР будет в роли подписчика? Подскажите пожалуйста, а то что-то в этом месте образовался пробел в понимании работы.

И ждёт - Максим имеет ввиду что предположительно у тебя демон, если же нет - то лучше не кидать задачу в очередь а просто вызывать нужные тебе методы сервиса

> Есть ли в RabbitMQ какие-то средства для этого RPC там есть

pub\sub, command, event Продюсер пишет команду: - сделай заебись - консамер всё сделал, кидает эвент что такая-то задача выполнена. кому нужен результат подписывается на получение этого сообщения (эвента) и ждёт

евент через кролика поступает к продюсеру?

И ждёт - Максим имеет ввиду что предположительно у тебя демон, если же нет - то лучше не кидать задачу в очередь а просто вызывать нужные тебе методы сервиса

:( я что-то еще больше запутался. на стороне РНР я могу запустить и демона (yii2-queue). Но этот демон ведь не должен слушать эту очередь, в которую я добавляю сообщение.

Ткните пожалуйста, где почитать. Не хочу напрягать вас своим нубством. Просто этот момент никак не пойму.

:( я что-то еще больше запутался. на стороне РНР я могу запустить и демона (yii2-queue). Но этот демон ведь не должен слушать эту очередь, в которую я добавляю сообщение.

он может слушать другую очередь

то есть ответ через другую очередь?

например, так pub/sub еще через redis любят делать

консумер кончил и кинул сообщение в другую очередь, скажем "очередь результатов работы", которую слушает демон на РНР

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

я тебе уже ответил: у кролика есть rpc

буду гуглить про рпц. спасибо

https://www.rabbitmq.com/tutorials/tutorial-six-php.html

но это больше про реквест-респонс будет

нашел уже. спасибо. хоть как-то разберусь. потом, если что, спрошу.

Чёт я не помню rpc у кролика. Его можно построить, но из коробки такого механизма нет. Может плагин какой?

Чёт я не помню rpc у кролика. Его можно построить, но из коробки такого механизма нет. Может плагин какой?

вон ссылка на доку выше

вон ссылка на доку выше

Если вдруг есть какие-то еще способы (бестпрактикс) передачи результатов работы продюсеру - с удовольствием выслушаю.

Если вдруг есть какие-то еще способы (бестпрактикс) передачи результатов работы продюсеру - с удовольствием выслушаю.

опиши свой кейс, может есть варианты получше

Если вдруг есть какие-то еще способы (бестпрактикс) передачи результатов работы продюсеру - с удовольствием выслушаю.

Обертка yii2 для Рабита кастрированная

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

опиши свой кейс, может есть варианты получше

Специфическое приложение - работает с оборудованием. Пользователь через интерфейс запрашвиает состояние оборудования. Это состояние может определяться отеносительно долгое время. То есть открыл страницу с устройством, через N секунд получил результат. Фактически получением результата занимаюстя консумеры на питоне. Они опрашивают, вычисляют и т.д. делают много работы в общем. Но также нужно опрашивать оборудование периодически для накопления статистики - это делают простые скрипты через cron - они просто добавляют в очередь точно такую же задачу на опрос оборудования. Результаты должны приниматься ядром и помещаться в базу данных. Но если запросил пользователь, а не скрипт из крона, то еще и пользователю надо сообщить результат в браузер.

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

«На кролике можно сделать rpc», а не «в кролике есть rpc »

Так может и не ждать ответа, а периодически спрашивать результат, раз он где то храниться?

от этого как раз и уходим в сторону нормальной асинхронности и вебсокетов

много причин не опрашивать периодически

Ну тогда строй rpc

Две очереди, продюсер шлёт запрос в одну очередь и слушает ответ из другой

Классический вариант

продюсер в очереди ничего не шлёт, так-то)

Ну ок, в rpc продюсер называют клиентом, а консьюмер сервером. Пусть так

суть в том, что сообщеньки улетают в эксчендж, а не в очередь)

«На кролике можно сделать rpc», а не «в кролике есть rpc »

сорри, никогда не приходилось реализовать - просто помню, что есть секция в доке

Чувствую, меня ждут приключения )))

Ок. Спасибо! :) Уже интересно

убиваем браконьеров

паблишер -> exchange -> routing key -> queue (1?) сабскрайбер -> queue паблишер к очереди отношения не имеет) он про неё тупо не знает.

ию2 в чатике? беги...

ERROR: S client not available

ию2 в чатике? беги...

где?

нима

где?

красавчик)

показалось

ию2 в чатике? беги...

да я бегу уже от йии давно ))) никак не убегу

я его не забанил, но спам отметил

Ну документация кролика не делает разницы публикует ли продюсер в очередь или в эксченьж

это не спам.

Ну документация кролика не делает разницы публикует ли продюсер в очередь или в эксченьж

а ему не должно быть разницы по хорошему

Парни мне php-ник нужен)

это спам до тех пор, пока рассылка не согласована с администрацией чата

Парни мне php-ник нужен)

а ты нам не нужен

иди на апворки всякие с такими штуками

Парни мне php-ник нужен)

@php_jobs

Ну документация кролика не делает разницы публикует ли продюсер в очередь или в эксченьж

channel.basic_publish(exchange='', routing_key='hello', body=message) угу)

паблишер -> exchange -> routing key -> queue (1?) сабскрайбер -> queue паблишер к очереди отношения не имеет) он про неё тупо не знает.

Ок, каюсь: не уточнил особенность кролика - разделение эксченьжа и собственно очереди. Под очередью имел в виду совокупность кью и эксченжа

да это не для кролика сделано, а в принципе) что бы можно было отсылать не 1к1, а 1 ко многим)

Это всего лишь один из способов этого добиться

В zmq например нет эксченжа, только очереди

В zmq например нет эксченжа, только очереди

нету там и очередей

Но ведёт оно себя как очередь :)

В zmq например нет эксченжа, только очереди

zmq это не брокер сообщений, это либка на которой удобно делать inter process communication. "очереди" там на уровне сокетов, больше на буфер сообщений похоже

Но ведёт оно себя как очередь :)

нет

zmq это не брокер сообщений, это либка на которой удобно делать inter process communication. "очереди" там на уровне сокетов, больше на буфер сообщений похоже

+++

и буфер этот можно переполнить кстати:)

zmq это не брокер сообщений, это либка на которой удобно делать inter process communication. "очереди" там на уровне сокетов, больше на буфер сообщений похоже

Я в курсе, приходилось пользоваться

суть эксченджа - как раз отвязать отправителя от конкретного назначения) так что отправитель про очередь знает, что она, наверное, суещтвует) и только

Всем привет. Как при записи в цикле строк в файле, записывать их в начало файла и смещать остальное вниз?

Всем привет. Как при записи в цикле строк в файле, записывать их в начало файла и смещать остальное вниз?

привет, это очень "дорогая" операция получится