Вот TS мне нравится

Кстати да, если бы e-loop набросать на TS было бы круто

может просто глюк а по факту все работает

я уже попробовал конвертировать картинку через ПО magick. Сработало. Осталось тока это сделать через php либу imagick.

а вот задачка, есть редиска и есть консьюмер делающий sub на изменение ключей или какой-то структуры. Получив некий id он консьюмер что то делает.

когда этот id удаляют из редиски - перестает делать

ну id может быть много, вот как этот консьюмер масштабировать...

или все же слушать кролика, а редис только для персиста оставить

ну id может быть много, вот как этот консьюмер масштабировать...

в лоб просто реплики создаешь и Sentinel как LB а дальше на каждую реплику свой консьюмер.

реплики чего и где у редиски LB?

если будут реплики редиса, то все консьюмеры получат одно и тоже, где ж тут балансировка

это я с утра так хорошо выражаю мысли) под репликами я понимал в данном случае просто инстансы, с разным состоянием конечно (ну т.е. не реплики совсем:)), а LB, как раз sentinel вместо него https://redis.io/topics/sentinel

там логику LB все равно свою придется писать но он свои боксы добавляет и там конфиги настраиваемые + мониторинг, т.е. почти все уже есть с коробки. Как оно на самом деле я не очень знаю, поскольку не пользовался, он просто у меня в списке попробовать стоит и хочу куда -то прикрутить) Но это вроде как родное решение для редиски и должно быть самым простым

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

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

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

да проблема не в этом... пробоема в том, как дистрибутить id... ибо никто не знает число нод... ну ладно, дистрибутить могу кроликом, хрен с подпиской у редиски, в редиску складываю стейт... но как потом этот стейт разгребать то после перезапуска нод

ну так sentinel умеет паралельно все обрабатывать и хранит состояние после рестарта

хотя не факт, он точно из конфига состояние востанавливает, а вот текущее состояние вернуть будет сложно

ну лежит у меня там 10к idшников, я стартую 5 консьюмеров, им нужно взять каждому свой стейт...

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

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

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

sentinel кстати тут как минимум поможет тем, что он мониторит же операции все, и можно просто логи парсить и куда то id шники бекапить. А уменьшать тебе и не нужно, если kubernetes он же сам по ограничениям будет смотреть и либо поднимать либо убивать инстансы. Но придется отдельно логику описывать, если данные где -то остались, но идет простой -перекидывать в другой инстанс

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

у меня один сервис который нужно балансить

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

ну наверное само приложение должно уметь восстанавливать стейт свой... вот как раз вопрос в том, что считать своим...

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

т.е. хотя бекапы все равно нужны, но переложишь логику востановления состояния куда -то отдельно

я и так знаю какие у них состояния :) это список id

тебе просто нужно какой -то сервис держать между редисом и консьюмером, который будет кеш хранить и как то бекапить/востанавливать данные

а редис на что

он и хранит данные

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

просто если у каждого консьюмера стейт свой - теряем возможность менять число консьюмеров... вернее уменьшать

если стейт общий, то вопоос в том, как делить данные

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

а так как хочешь хоть по проценту загрузки хоть по len() )))

да просто ограничения на клиента можно поставить или адрес машины/образа с консьюмером

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

и лучше отдельный, чтобы всегда можно было его на что -то заменить

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

ну иначе тебе придется логику в консьюмеров добавлять. а она им не нужна совершенно, они же должны только получать id, а кто -то должен решать сколько id им дать и когда.

по хорошему тебе нужно посмотреть что -то вроде terraform, он довольно сложные конфиги поддерживает и вполне возможно что логику этого менеджера можно туда переложить.

о, придумал, по шатдауну консьюмер будет все свои id выкидывать на шину, и пусть другие их разбирают

Ну да и надо учесть что шатдаун не всегда бывает запланирован и они должны кому -то говорить о том, сколько взяли. Ну и делать это все транзакциями. и тебе все равно состояние нужно востанавливать после сбоев, т.е. какой -то кеш будет нужен. Вот только завязывая всю логику внутри консьюмера ты обрекаешь процессы изменения и расширения в атракцион :)

незапланированный шатаун - это упал и был поднят мониторингом и подхватил свой стейт из редиса. Мена вопрос запланированного шатдауна интересовал, когда мы число нод хотим уменьшить

ну по сути ты можешь просто на базе редиса сделать очередь и просто оттуда консьюмерами забирать id, а если нужно уменьшить число, добавь в очередь приоритеты и просто ставь слитые id с убитых консьюмеров в верх списка

редис не умеет балансить сообщения вроде

а если пулить, что уже не айс, то еще состояние гонки решать

ну так есть же пакеты вроде https://github.com/gabfl/redis-priority-queue/tree/master/clients/php

да и свой сделать в принципе не сложно

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

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

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

тут ктонибудь с aliexpress работал? нифига не пойму где там и что включить чтобы эти гады мне токен дали. Портал их с методами api нашел, но там пишут > To register as a developer, simply sign up for an AliExpress.com account и че? ну сигнапнулся я и куда тыкать так и не понял...

Добрый день! Тут можно вопрос по php задать? Я просто написал в одном чате, а меня сразу почему-то забанили, вопрос не сложный для бывалых, но я гуглил пол дня, сдался, не могу решить.

Добрый день! Тут можно вопрос по php задать? Я просто написал в одном чате, а меня сразу почему-то забанили, вопрос не сложный для бывалых, но я гуглил пол дня, сдался, не могу решить.

Можно

Задача следующая, надо выковырять картинку из страницы, но сложность в том, что она без https и в конце лишниее расширение добавлено: Вот кусок кода страницы: <span class="pimg"> <img onerror="_errIMG_(this)" src="//img12.server.com/s800x800_jfs/asdasd123.jpg.dpg" width="44" height="38" /> </span> Я выковыриваю ссылку следующим методом: $pageOfGood = getPage($link); //Тут выковыриваю ссылку до .dpg" preg_match('/onerror="_errIMG_(this)" src="(.+?).dpg"/s',$pageOfGood, $matches); // а тут пытаюсь добавить вначале строки выковырянной ссылки https: чтобы ссылка получилась полной. $a = 'https:'; $linkToImg = $a . $matches[1]; Вот у меня сильные сомнения по поводу того, что я правильно соединяю строку, чтобы получить полную ссылку?

ну id может быть много, вот как этот консьюмер масштабировать...

А просто сделать очередь из list и повесить на нее слушать 100 консьюмеров нельзя чтоли?

ну не

у редиса нет rr консюмеров, да вопрос то не в этом, а в том, как хранить консюмеру id с которыми он работает

Можно в редисе хранить ?

ERROR: S client not available

не в чем, а как

rr это round robin? Как раз консьюмеры так и работают там

Вернее консьюмер приходит, ждет пока в списке не появится задача, берет ее. И так они по очереди ждут задач.

Вызовы атомарные и блокирующиеся.

что значит "ждет"? постоянно опрашивает?

а, блокирующийся вызов.... это какой?

Blpop если я правильно помню

что значит "ждет"? постоянно опрашивает?

Нет, висит на этой команде и ждет просто

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

ок, но все еще не о том, вопрос не в том, как накидать задач консьюмерам

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

BLPOP никак не решает хранение стейта

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

Так то да

Но зачем совмещать хранение стейта с получением задач. Этим и кролик не занимается

ну редис умеет слать события при изменении ключей

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

Да, звучит странно и я не понимаю

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

можно из постановщика задач писать сразу в этот ключ в редисе, нарпимер, добавлять id в список - а консьюмер по событию "ключ изменен" перечитает его себе в память.

Но от этой идеи я отказался уже.

основная задача сейчас как минимальными силами обеспечить 1. подхват задач в случае падения (не важно каким консюмером), 2. скейл числа консьюмеров в обе стороны

нюанс в том, что одна задача (работа с одним id) длится около часа-двух

прерывать ее можно но не более чем на минуту

не в чем, а как

можешь написать исходную задачу в личку? листать 2 дня обсуждений по 2м чатам не очень хочется

да в общем вот она, три сообщения последних ;) есть консьюмеры куда попадают id (т.е. есть некая задача другими словами), они с ними работают как-то

задача может быть разделена на части? задача является транзикцией?

Задача следующая, надо выковырять картинку из страницы, но сложность в том, что она без https и в конце лишниее расширение добавлено: Вот кусок кода страницы: <span class="pimg"> <img onerror="_errIMG_(this)" src="//img12.server.com/s800x800_jfs/asdasd123.jpg.dpg" width="44" height="38" /> </span> Я выковыриваю ссылку следующим методом: $pageOfGood = getPage($link); //Тут выковыриваю ссылку до .dpg" preg_match('/onerror="_errIMG_(this)" src="(.+?).dpg"/s',$pageOfGood, $matches); // а тут пытаюсь добавить вначале строки выковырянной ссылки https: чтобы ссылка получилась полной. $a = 'https:'; $linkToImg = $a . $matches[1]; Вот у меня сильные сомнения по поводу того, что я правильно соединяю строку, чтобы получить полную ссылку?

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

основная задача сейчас как минимальными силами обеспечить 1. подхват задач в случае падения (не важно каким консюмером), 2. скейл числа консьюмеров в обе стороны

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

задача может быть разделена на части? задача является транзикцией?

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