Демон для обработки очереди

[grigori]

@AnrDaemon, ты как первый раз замужем: "почему вы мне пишите не то, что я хочу" )))
это ж "теория", я и теоретизировал, все, спасибо, как реализую - напишу, что получилось

@fixxxer, спасибо за диалог, я не жду ответов, опробую одновременно две очереди на постгресе и на редисе, демон на reactphp и golang

 

[AnrDaemon]

Извините, замужем бывать не приходилось…

 

[alekciy]

@fixxxer,и про асинк в июне подробно Бартенева слушал

Вживую или есть видео? Если второе, то можно линк?

 

[Adelf]

Вживую или есть видео? Если второе, то можно линк?

https://www.youtube.com/watch?v=llOSqj2Mzso

 

[alekciy]

@AnrDaemonопробую одновременно две очереди на постгресе и на редисе

На redis очередь вообще огонь выходит. Не нужно морочиться конкурентным доступом и блокировками.

там не написано, а почему не могут? кто помешает двум процессам поймать одну задачу?

Не важно, что в php коде. Важно, что сам redis сервер однопоточный. При построении очереди на LPUSH/RPOP ни когда не будет дублей задач в воркерах. Работает сильно быстрее, чем очередь в posgres на базе UPDATE ... SET ... FOR UPDATE SKIP LOCKED.

да полно таких тулз. тот же supervisord.

"Кто будет следить за полицейским, который следит за полицейским?"
supervisord сволоч, имеет свойство падать. Приходится поднимать руками. Мы в своих проектах в итоге перешли на pm2.

 

[Adelf]

@alekciy, давай ты крепко подумаешь и все мысли одним постом сформулируешь?

 

[alekciy]

@alekciy, давай ты крепко подумаешь и все мысли одним постом сформулируешь?

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

 

[grigori]

Не важно, что в php коде. Важно, что сам redis сервер однопоточный. При построении очереди на LPUSH/RPOP ни когда не будет дублей задач в воркерах. Работает сильно быстрее, чем очередь в posgres на базе UPDATE ... SET ... FOR UPDATE SKIP LOCKED.

1. то, что воркеры получат уникальные задачи - недостаточно, потому что появляется вопрос консистентности.
Когда воркер забрал задачу продления подписки пользователя через RPOP и не смог завершить из-за сбоя, в очереди задачи не останется, но ее должен выполнить другой воркер. Как это реализовать на стеках - непонятно.
Поэтому в 5м редисе сделали streams, он релизнулся осеньюhttps://redis.io/topics/streams-intro
2. Скорость часто не имеет значения. Через сколько часов уйдет письмо по рассылке - неважно.
3. в Postgres, как и в редисе, есть важная штука - notify

supervisord сволоч, имеет свойство падать. Приходится поднимать руками. Мы в своих проектах в итоге перешли на pm2.

что говорит про отсутсвие в команде админа, архитектора, cto, или кого угодно, кто знает слово operations

 

[alekciy]

Как это реализовать на стеках - непонятно.

Когда требовалось задачи не терять, то юзал RPOPLPUSH.

2. Скорость часто не имеет значения. Через сколько часов уйдет письмо по рассылке - неважно.

С письмами да. Но есть много и других кейсов где скорость нужна и важна. Парсинг. Или запросы в некий сервис с лимитами (делал для Яндекс.XML).

3. в Postgres, как и в редисе, есть важная штука - notify

Для очередей заходит плохо. Если нет клиента с активным LISTEN, то сообщения теряются. NOTIFY/LISTEN хорошо заходит для отслеживания изменений в базе без завязки на какое-то конкретное ПО снаружи . NOTIFY вообще хорошо заходит внутри транзакций.
Для очереди же на уровне PG как раз UPDATE ... SET ... FOR UPDATE SKIP LOCKED ложится прямо в тему. Блокировок нет, дублей нет, можно отследить статус завершения задачи.

или кого угодно, кто знает слово operations

Не уловил контекста. Subprocesses? В общем прошу пояснить, не уловил мысли.