И сразу мгновенный бамп.
Ну или в деперсонализированном месенджере каком.
Но вряд ли вообще люди найдутся, конечно...
Но вряд ли вообще люди найдутся, конечно...
Бимп
Bamp
Ех... тут все мои друзья.
А чем тостер сру не устраивает?
Только по предоплате
Не знаю. Может и туда запощу. Но ведь "тут все мои друзья"
Вопрос не четкий, просто обговорить надо.
Сколько хочешь? Ты точно сеньер+?
Аниме, ты как всегда право. Пойду затарюсь пивасом.
Сеньер и выше ты там для банка чтоли ИС прожектируешь? Ебашь шину, кто не забрал вовремя - тот сам лох, пусть ставят больше консумеров.
Типа для банка пива.
А что делать с мультистеп процессингом?
Мне надо сообщение в несколько шагов обрабатывать. Вот ряд вопросов и появился.
Передавать и данные по шине или только ивент, а само тело хранить в базе и апдейтить по ходу дела. Или не апдейтить и новые записи создавать.
Мой тебе совет, ты сначала нарисуй что ты хочешь сделать и сколько можешь заплатить, а приходить и просто просить "нарисуйте мне архитектуру", ну блин, тебя скорее всего просто пошлют нахуй.
Да мне поговорить просто бы.
У меня есть некое видение, но оно мне не нравиться.
Согласен, что шапка мутная.
Готов 20$, за 40 минутную беседу заплатить. Да, мало, символически.
Накалякал вопрос. Все равно мутно, да.
Задача:
Принимать, обрабатывать, отсылать сообщения в несколько шагов.
Пример: получить котика в формате xml, валидировать котика, преобразовать его в формат json, сохранить котика в БД 1 если левое ушко серое, сохранить котика в БД2 если у него есть левое ушко (тоесть котик может быть сохранен дважды), отослать информацию котика с сгенерованными в БД2 или в БД1 айдишниками людям, подписаным на котика с подходящими фильтрами, трансформировать сообщение в нужный формат перед отправкой.
Все должно быть конфигурируемым.
Вопросы:
1. Разделять ли ивент и сообщение? Я имею ввиду: сохранять данные в БД и ивентом тригерить следущий шаг (по сервис басу вызовется функция где в теле будет только ИД записи) или передавать и данные вместе с ивентом.
2. Хранение данных и текущего состояния очереди.
2.1. Как я хочу сделать: по схеме выше с самого старта создадутся 2 очереди с прямой последовательностью без ветвлений. На каждую создастся запись в базе со списком необходимых действий, по мере продвижения эта запись будет мутировать.
2.2. Вариант второй - на каждый шаг создавать отдельную запись в конце выполнения предыдущей.
Или же все нахуй и просто меседж пробрасывать каждый раз новый дальше (вопрос куда дальше, и для некоторых операций в очередь его можно и не ставить, к примеру конвертировать сразу перед отправкой , а не разделят на два ша). Так будет сложней следить за состоянием месседжа. Я все-таки склоняюсь в сторону БД пока.
Задача:
Принимать, обрабатывать, отсылать сообщения в несколько шагов.
Пример: получить котика в формате xml, валидировать котика, преобразовать его в формат json, сохранить котика в БД 1 если левое ушко серое, сохранить котика в БД2 если у него есть левое ушко (тоесть котик может быть сохранен дважды), отослать информацию котика с сгенерованными в БД2 или в БД1 айдишниками людям, подписаным на котика с подходящими фильтрами, трансформировать сообщение в нужный формат перед отправкой.
Все должно быть конфигурируемым.
Вопросы:
1. Разделять ли ивент и сообщение? Я имею ввиду: сохранять данные в БД и ивентом тригерить следущий шаг (по сервис басу вызовется функция где в теле будет только ИД записи) или передавать и данные вместе с ивентом.
2. Хранение данных и текущего состояния очереди.
2.1. Как я хочу сделать: по схеме выше с самого старта создадутся 2 очереди с прямой последовательностью без ветвлений. На каждую создастся запись в базе со списком необходимых действий, по мере продвижения эта запись будет мутировать.
2.2. Вариант второй - на каждый шаг создавать отдельную запись в конце выполнения предыдущей.
Или же все нахуй и просто меседж пробрасывать каждый раз новый дальше (вопрос куда дальше, и для некоторых операций в очередь его можно и не ставить, к примеру конвертировать сразу перед отправкой , а не разделят на два ша). Так будет сложней следить за состоянием месседжа. Я все-таки склоняюсь в сторону БД пока.
Что-то взгрустнулось ажна от своих же картинок.
Вот вопрос, если что.
Эх...
Оно бампается-то хоть?
Или абу лимитирует бампы с одного ИП?
Или абу лимитирует бампы с одного ИП?
Бампается, че хотел то? Суть проблемы изложи.
Забесплатно у тру сеньоров только хуй пососать можно, держу в курсе
Вот тут немного попытался сформулировать.
Ну разве нету тру сеньеров-лапочек?
Летели два верблюда, один рыжий, другой налево. Сколько весит килограмм асфальта, если ежику 24 года?
Это у тебя Система состояний, которая представляет собой конвейерс по сути.
В одну таблицу бд ложишь событие с уникальным идом + его состояние
В другие таблицы бд ложишь данные, которые референсятся по ид события.
Как крутить конвейер решай сам. И там и там подводные камни есть.
Т.е. есть состояние 0 когда пришли данные
Состояние 1 когда данные распарсили
Состояние 2 когда распарсенные данные разослали
и тд...
Правильнее всего конвейер крутить в отдельном потоке (те. есть поток обработки и поток приема данных). В какой нибудь жабе для этого есть воркерфактори, но это уже для совсем задротов.
Ах да. Не забудь делать sleep в потоке обработки чтобы не всрать 100% цпутайма на ядро, и проверить чтобы твоя бд умела адекватно работать с асинхронными записями.
мимо-одинокий-дрочер-на-архитектуры
>В одну таблицу бд ложишь событие с уникальным идом + его состояние
Состояние - имеется ввиду всякая метаинформация, типа статус, ошибки, ретрай каунт?
>В другие таблицы бд ложишь данные, которые референсятся по ид события.
То есть сначала заполняются события (таблицы с данными пустые, кроме первого). События крутятся и смотрят на данные с предыдущего?
Выглядит хорошо.
Еще погуглю потом по твоим ключевым словам.
Спасибо.
Так в таблице Состояние должно быть по записи на действие или нет?
Каждое действие я планирую тригерить ивентом через сервис бас. Для каждого типа действий будет свой ендпоинт, так что там потоками все ок должно быть.
Тут еще ж главное, чтоб это все конфигурировалось.
Допустим надо нам отправить котика мемесному поцу - добавляем в конфигуратор таск "конвертировать кота в всратого" и потом "отправить человеку"
Вернись плиз :(
Давай бесплатно bouxroix
Не с кем посоветоваться и в голове картинка архитектуры не складывается.
Нужно с кем-то обсудить.
Если уделите мне 15 минут в скайпе/телеге - будет вообще супер.
Готов материально отблагодарить.
Поверхность: работа с сообщениями в несколько шагов и роутинг.