Ребят есть в системе очередей фишка передавать на кластер а распределять чтение на каждом сервере отдельно?

а можете развернуть вопрос? потому что паб-саб так и работает: пишет один, читают все

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

сабскрайбер по удалению фоток хочу сделать

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

и удалить оттуда картинку нужно один раз, а не с каждого сервера

ок не ругайся ;)

ок не ругайся ;)

не, я предлагаю пообсуждать как правильно сделать, без всяких)

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

смотрите, не храните файлы на серверах. это чревато, возьмите с3-хранилище

смотрите, не храните файлы на серверах. это чревато, возьмите с3-хранилище

s3 это что-то магическое чтоле?

https://aws.amazon.com/ru/s3/

и? оно в астрале, неуничтожимое? или как? ) как по мне это говно ровно на тех же серверах и работает

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

с бекапами в какое-нибудь ленточное хранилище

там сла столько девяток, до скольки примерно умеет считать средний сисадмин - 99,999999999

таких показателей, мягко говоря, достаточно сложно достигнуть на любом своем железе, тут нужна избыточность на уровне дата-центров, магистралов, подстанций и кучи всего такого, о чем мы даже не догадываемся. но мы слегка о разном: на своем железе с3-совместимое хранилище поднимать и правда, возможно, не стоит (хотя все равно ceph + rados gw) дают девяток втрое больше, чем сингл-нод сторадж, раскиданный по нфс по компьют-нодам

мораль типа в том, что "если вы не умеете хранить файлы, возьмите managed s3, это будет в сотни-тысячи раз надежнее, удобнее и проще, чем городить свой сторадж, обладая околонулевой компетенцией в этих вопросах"

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

чувак, я не знаю сколько тебе лет, и сколько у тебя опыта, но я клянусь, ты выглядишь смешным школьником, ну не может тебе быть насрать на собственный имидж, ну нельзя систематически нести такую пургу, как это получается у тебя. нет, к сожалению, нельзя у себя поднять сколь-либо похожее "говно", увы. даже у яндекса не получается, и не получалось у сотен компаний до него. со стораджами регулярно все обсираются, это очень тонкая материя на больших объёмах и с высокими требованиями надежности. если хочется мысленного эксперимента, то у aws заявленное sla я приводил выше. вот тут его можно оценить - https://uptime.is/99.9999999 это типа реально сложно поднять. у нас, например, один из PoP в РФ - это https://www.ixcellerate.com/ru/ это крутой ДЦ, заявляющий "пять девяток" - https://uptime.is/99.999 и вот теперь подумай, как ты "на своем железе и лентах" обеспечишь больше девяток, чем tier III цод

Вопрос а надо ли оно

Как миниме все приложение должно тогда иметь такой же sla как и сторадж

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

Иначе нафига оно надо

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

Все надо в амазон

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

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

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

а для маленьких компаний с сотнями гигов с3 опять же выгоднее: не существует нормального способа иметь селф-хостед сторадж. всё упрется либо в тот же с3-интерфейс поверх цефа, либо какой-нибудь урод навроде минио, либо, прости господи, нфс. а это уже конкретно жопа. и либо у нас приложение с самого начала умеет в с3 (если говорить о симфони, то имеет что-то вроде flysystem-адаптера для файловых операций), либо мы страдаем

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

Ну это да

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

не обязательно прям у aws это покупать, есть яндексы, гуглы, мейлы, селектелы и что там ещё

там сла столько девяток, до скольки примерно умеет считать средний сисадмин - 99,999999999

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

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

девяток даже яндекс-клауда нам не достичь никогда

хотя может и нет, лол 🙂 гуглятся 4 девятки

у мейла и того лучше

SLA 99,95% - отличное доказательство того, что самим лучше в это дело не соваться

а, не, не туда смотрю

99,99999%

это всё чушня ) тупой маркетинг и развод на бабло. вот у яши потерли пару дц, нечаянно и всё. Где эти девятки? )

а потом такие "ой, ошибочка вышла"

или у овх сгорел дц, вместе с серверами игровыми, и поминай как звали :D

хотя тоже тиер3 ко-ко-ко, куча девяток )

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

так вот да! я о том же, что без кросс-дц репликации это все херня полная

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

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

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

банальная задача "у меня два бэкенда, хочу чтобы оба работали с одной файловой шарой" традиционными средставами (nfs или rsync по крону), решается не особо удобно

но с чем не поспорить - буллшита дофига, факт

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

Еще проблема в том, что у нас может случится суверенный интернет, даже без нашей воли. Тупо отключат от европейских\американских сетей и всё )

ну есть яндекс/мейл/селектел

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

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

чебурнет, который нам обещают, это примерно такая же проблема для них)

банальная задача "у меня два бэкенда, хочу чтобы оба работали с одной файловой шарой" традиционными средставами (nfs или rsync по крону), решается не особо удобно

я кстати одно время очень хотел zfs затестить, но чот так и не решился 😄

на линуксе я бы не стал, как и все эти CoW FS

вечно слышу истории, что то бтрфс данные попортило, то цпу жрать стало на ровном месте

Зато снапшоты умеет делать моментально

Это вообще придумали наверное для ролинг релиз дистрибутивов чтобы можно было откатиться при неудачном обновлении

для фряхи)

Ещё один глупый вопрос от меня, а то смотрел код со старой работы, но там через league pipline был flow и базовые операции на бандлы вынесены, не репрезентабельный пример. А где делать десериализацию запроса? В контроллере? В сервисе? В сервис по идее уже DTOшка должна прилетать? Что бы не делить одну операцию (например сохранение сущности в БД) на два сервиса. или не делать в одном сервисе Request - > DTO -> Entity, это по моему вообще фигня полная.

реквест - контекст только контроллера. там можно во всякие мидлвари шаблонный код десериализации вытащить

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

банально потому что мокать замучаешься

(не считая еще десятка причин)

реквест - контекст только контроллера. там можно во всякие мидлвари шаблонный код десериализации вытащить

Спасибо большое! Миддлвари пока сложновато (да, я ООП начал учить с симфы 😅) Немного жалею что Ларку перешагнул, было бы попроще.

прям мидлвари в симфони не сильно распространены (и слава богу), я скорее про всякие лиснеры реквест-стадий

(не считая еще десятка причин)

я в принципе основные причины понял, собственно контроллер это request/response и нужные ручки. Остальное всё выносить из него дальше.

я в принципе основные причины понял, собственно контроллер это request/response и нужные ручки. Остальное всё выносить из него дальше.

* контроллер только видимо)

прям мидлвари в симфони не сильно распространены (и слава богу), я скорее про всякие лиснеры реквест-стадий

Понял, заодно и эту тему подкачаю.

* контроллер только видимо)

Ага, описка.)

Привет, Гайс!

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

Какую команду нужно использовать?

Что тут еще нужно сделать? Композеры установлены.

у вас ОС какая-то странная, даже не знаю чем помочь

У меня виндовка.