С рождеством, уважаемые форумчане! Столкнулся с такой темой - есть сайт, на который в т.ч. загружаются фотографии. В настоящее время фотографий не особо много, но объемы растут, в будущем могут достигать до 4Гб в день. Есть желание сделать распределенную систему хранения изображений по разным серверам, с балансировкой, с возможностью добавлять новые сервера-хранилища под все это дело. В настоящее время все загружается на один и тот же сервер. Сейчас по сути скрипты, БД, изображения да и вообще все хранится именно на нем. Как я все это вижу: картинки обрабатываются бэкендом, оптимизируются, делаются к ним миниатюры и сохраняются уже на другом сервере-хранилище с доменом 3 уровня под хэш-именем, например, dfs1.site.com/?img_hash=0123456789abcdef. Затем урл картинки присваивается одному из полей таблицы БД и делается запись. Собственно, вопрос - кто-нибудь реализовывал подобное? Это правильное решение для распред. системы? Чтобы с основного сервера передать хранилищам изображений файлы что луче использовать? FTP приемлемо http://php.ru/manual/book.ftp.html? Как лучше настроить такие сервера-хранилища и где их взять? Хостинг виртуальный(пока что). В общем, буду рад услышать любые мнения и комментарии по этому поводу. Не знаю в ту ли ветку разместил. Ветки highload не нашел. Еще раз со светлым праздником рождества!
С прошедшим! Сразу оговорюсь: нет у меня такого опыта. К обсуждению хайлоад отношусь с долей скепсиса. Считаю как ни готовься, реальность будет внезапной Описанная схема мне кажется рабочей. Процесс передачи с сегодняшнего сервера на новые непринципиально чем делать, это ведь разовая операция. Или вы всякий раз будете загружать файлы на "центральный" сервер, а потом отправлять куда-то? Лично я ftp уже исключил из оборота, использую scp или rsync. И что, реально 4GB в день ожидаете?
Форма с данными передается в скрипт на центральном сервере, но там будут только временные файлы храниться в /tmp, затем они буду обрабатываться и рассылаться по хранилищам. Как-то так. Возможно 4GB и не будет, но, думаю, лучше перестраховаться и быть готовым имея масштабируемую систему.
Считаю надо пытаться просчитать поведение системы глазами пользователя. Он не любит ждать, это важно! Поэтому надо пытаться сократить издержки и распределить времязатратные процессы. Почему бы не грузить картинку сразу на целевой сервер? Какой бы ни был прекрасный канал, пересылка будет не мгновенной. Особенно под нагрузкой. У каждой картинки несколько размеров превью. Создавать их все перед тем как отдать пользователю страницу ответа (с одной превьюшкой) нерационально. Можно генерить превью в момент первого требования.
Согласен, это затратно по времени. Но пользователю нужно вернуть урл картинки уже с сервера-хранилища. Ушел пробовать))
Правильно — вернуть URL, смотрящий на сервер-хранилище. При этом картинка может еще не существовать, мы только решили где она поселится.
Да, но люди хотят видеть привью, вдруг им что-то не понравится... В общем я сделал, что хотел. Правда через ftp. Посмотрим как работать будет...
И что, чем это мешает? Картинка отдается по запросу браузера. То есть по определению позже, чем будет получена страничка с URL этого превью. Будет запрос к картинке — будет создано превью, а не будет — значит пока не надо. Всё отлично!
Не, картинка сразу нужна. Все, что вчера сделал - работает. Но, думаю, решение не совсем правильное. Т.е. с точки зрения распред. сист. все ОК, но если на 1 бэкенд налягут праллельно 10 чел, которые захотят загрузить, например, по 10 фото. И 1 бэкенд должен будет их обработать да еще и по ftp потом разослать... думаю, будут серьезные проблемы с производительностью... Видимо, нужно неск. бэкендов... В общем, пошел читать про nginx.
Давай рассмотрим механизм появления картинок на сайте: 1) Браузер посылает запрос к серверу; 2) Сервер отдает браузеру пачку текста, которая есть - HTML; 3) Браузер парсит пачку текста, строит траницу; 4) Браузер натыкается на тег img, или на background-image или на какой-нить скрипт, подгружающий фото, не суть; 5) Браузер посылает второй запрос к серверу; 6) Сервер отдает картинку; То есть текст у тебя может отдать одна машина, а картинку - другая, хотя у пользователя загрузится одна страничка. За счет этого вот промежутка ты заранее можешь узнать, сколько юзеров ломанутся за картинками и куда и, например, принять какие-то меры.
А мне вот почему-то кажется, что ты непременно хочешь стоять на своем и сделать так, как проще. Еще раз говорю, задача такая - загрузил картинку и сразу получил ее превью, кликнул по нему - увидел оригинальное изображение... Например, вот представь, ты в ВК публикуешь новость, пишешь текст, загружаешь фото и... херакс! Вместо того, чтобы увидеть фото ты видешь ссылку на фото или кнопку, которая по хэшу через аякс подгрузит саму картинку. А может и не подгрузит. Ты же ссылку вернул пользователю до того, как убедился, что все записалось хорошо. Добавлено спустя 12 минут 23 секунды: Насчет 6 пунктов я с тобой согласен, хотя некоторые я бы описал по-другому. Вот этот вот фрагмент для меня не понятен - "То есть текст у тебя может отдать одна машина, а картинку - другая, хотя у пользователя загрузится одна страничка. За счет этого вот промежутка ты заранее можешь узнать, сколько юзеров ломанутся за картинками и куда и, например, принять какие-то меры.". Имеешь в виду куда загружать?
Это не он упрощает, а ты загоняешься. 1) ссылки не нужно показывать, есть IMG 2) ajax прекрасно работает и без кнопок, если надо им грузить.
поясню свою мысль: Код (Text): RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.+) not_exists.php?alias=$1 Код (PHP): $file = make_preview($uri); // файл теперь создан и будет по этому адресу вечно. header('Content-Type: image/jpeg'); readfile($file); php скрипт сработает только при первом обращении по данному url. далее — будет отдаваться как статика самим веб-сервером профит в том, что нагрузка по генерации нескольких превью размазывается по времени (и, возможно, по серверам). а пользователь не заметит большой паузы, в отличие от случая когда сама страница отдается после генерации всех превью.
В общем, все давно решено и все работает ок. Вопрос сместился в другую область. В чем конкретно ты считаешь, что я загоняюсь? Опиши конкретно. Добавлено спустя 9 минут 50 секунд: Тему можно закрывать. Всем спасибо за внимание. Еще можно было бы поспорить, но времени вообще нет, работы оч. много.