sykobeats
@sykobeats
Developer

Веб сервер под фото. Какую архитектуру хранения выбрать с учетом масштабирования?

Всем привет!

Есть веб проект, в нем куча фоток.
Нужен совет, как правильно хранить фотки с учетом масштабирования?
Сейчас все фотки валятся в общий раздел веб сервера, места становится все меньше и меньше...
В планах купить машинку под статику, отдельный домен типа my-cdn.com
В nginx создать поддомен fs1.my-cdn.com и туда складывать файлы. Как закончится место еще один сервер fs2.my-cdn.com и т.д. В таблице фоток хранить цифру сервера (или fs1), чтобы понимать на какой машине лежит файл.
В линуксе не силен, поэтому больше ничего на ум не приходит. Веб сервер трудится под debian.

p.s. Буду рад любым ответам. Отмечу всех!:D Только без флуда плз.
  • Вопрос задан
  • 594 просмотра
Решения вопроса 3
Не рассматривали подключения хранилищей вроде S3?
Ответ написан
SashokSmir
@SashokSmir
Инженер
Лучше сделать немного иначе. Сделать узел — входной узел для статики. Этот входной узел требует мало ресурсов, но позволит сделать интерфейс для всей вашей системы, с помощью которого вы избежите многих проблем в будете и сможете легко масштабироваться.

Все запросы на доступ к статическим файлам нужно отправлять на этот узел, например, files.example.com. Тот, кто отправлят запрос даже не знает на каком сервере и т.д. находится файл и ему это не нужно знать.

Именно этот узел ведет учет файлов и знает на каком именно сервере у вас находится файл. Ваше приложение (сайт) посылает запрос на узел (files.example.com) на доступ к определенному файлу и этот узел смотрит у себя в базе где именно находится этот файл (на каком сервере и по какому адресу) и в ответ отдает этот адрес, например, srv01.files.example.com/f/405/502.jpg

Таким образом у вас будет единый интерфейс в виде точки входа и весь ваш код будет общаться за файлами именно через этот интерфейс (в виде API). Если в будущем нужно будет поменять алгоритм работы, то придется менять только то, что находится за интерфейсом, но не то, что впереди (то, что впереди интерфейса даже не заметит изменений).

В будущем для надежности можно сделать зеркальные узлы.
Ответ написан
@reallord
Если миграция фото не предполагается, то Ваш вариант вполне надежен. При массовой миграции с сервера на сервер надо будет только сделать UPDATE колонки с названием сервера.

Если надо удалять/перемещать/добавлять файлы между серверами, то надо еще писать обработчик, котороый следит за местом на серверах и приоретизирует запись текущей фотки на нужный сервер на котором низкая загрузка IO и есть место. Аля балансировщик нагрузки.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы