А что с этим не так?
Ресайз картинок в локальной очереди
- Автор темы fixxxer
- Дата начала
По сути моего проекта upload не бывает равномерный. Проект - клипы для изучения языков, видео со скриншотом. Изредка создатель контента загружает несколько сотен картинок и видео за раз.
Недостатки решения через локальную очередь такие:
Результат: state остается только на запись файла в хранилище исходников, остальное можно масштабировать, картинки в любом разрешении доступны мгновенно, старые ненужные thumbnail nginx удалит сам.
Самое сложное - написать на PHP обработку PUT. Оказывается, мы умеем $_FILES только для mutipart/form-data и только при POST!
Недостатки решения через локальную очередь такие:
- Файл пишется на диск, поэтому у приложения есть состояние. Следствие - пережать картинку можно только на том же сервере, и это нельзя распараллелить.
- Когда юзер загрузил свою сотню клипов, ему надо ждать N минут, пока они отресайзятся и станут доступны для использования. Что такое сейчас заставить юзеров ждать свои фотки несколько минут.
- Если запустить несколько ресайзов фоток параллельно, процессор будет занят, и весь API будет тормозить.
- Отресайзенные фотки во всех разрешениях будут лежать на S3 мертвым грузом. Как после редизайна ресайзить все их заново в новые размеры - непонятно.
- Запросы к фоткам проходят через приложение. Зачем - непонятно, они не приватные. Быстрее отдавать их с диска nginx.
- S3 тут не нужен. У всех провайдеров есть подключаемые volume по $100 за терабайт. Терабайт фоток размером 1200х1200 - это много миллионов фотографий.
- Nginx из коробки умеет и ресайзить, и кешировать, и держать в памяти структуру кеша, и считать ttl от последнего доступа, и чистить файлы кеша не перегружая диск. Писать такое самому - очень долго. Однако, при работе через приложение этот функционал недоступен.
Результат: state остается только на запись файла в хранилище исходников, остальное можно масштабировать, картинки в любом разрешении доступны мгновенно, старые ненужные thumbnail nginx удалит сам.
Самое сложное - написать на PHP обработку PUT. Оказывается, мы умеем $_FILES только для mutipart/form-data и только при POST!
А, понятно. Ты изначально упустил важную деталь - загружается в общую кучу и очередь при этом локальная вместе со всем остальным добром. Если загружать на отдельный микросервис (инстансов которого запущено сколько надо), обрабатывающий аплоады (вот прямо по прямому урлу с JWT-токеном), то все эти проблемы отпадают. Тут в большинстве случаев даже можно не париться с локальностью очереди, это не проблема, аплоады будут распределены примерно равномерно за счет балансировки, тупо по очереди + разгребалке на каждый диск (физический или логический, не важно).
А S3 - ну не знаю, почему все его хотят. Видимо, потому что никого не увольняли за покупку IBM^W AWS. Как по мне, уж если хочется AWS, разумнее через CloudFront.
А S3 - ну не знаю, почему все его хотят. Видимо, потому что никого не увольняли за покупку IBM^W AWS. Как по мне, уж если хочется AWS, разумнее через CloudFront.
В варианте "для бедных" можно и без NAS, каждый файл загружать отдельным HTTP-запросом, балансировщиком раскидывать раунд-робином по инстансам микросервиса (или вообще, блин, случайный сервер из списка выбирать прямо на клиенте), и пусть себе на них локально каждая очередь гребется.
- Доктор, когда я делаю вот так, у меня тут болит.
- А Вы так не делайте.
Браузер подразумеваются по умолчанию, сам понимаешь. Десктоп апп понятно, его за 30 секунд не обновишь всем клиентам. Хотя в принципе и такое можно на L7 балансировщике разрулить.
А, кстати, зачем? Видеоредактор какой-то?
да, нарезать видео-ролики из диска или рипа, синкать с субтитрами на разных языках
> Браузер подразумеваются по умолчанию, сам понимаешь.
ну, клиенты сейчас чаще мобильные приложения или девайсы, 80% трафика уже с телефонов, а на JS они написаны или на Kotlin - ничего не меняет