Репликация файла / изображения
У меня простой вопрос, и я хочу услышать опыт других относительно того, какой способ лучше всего реплицировать изображения на нескольких хостах.
Я определил, что хранение изображений в базе данных, а затем использование репликации базы данных на нескольких хостах приведет к максимальной доступности.
Меня беспокоит файловая система - это трудности с синхронизацией изображений (например, я не хочу, чтобы все 5 серверов обращались к одному и тому же серверу для изображений!).
Теперь единственное, что меня беспокоит при хранении изображений в базе данных, - это дополнительные запросы, попадающие в базу данных, и дополнительную обработку, которую мне пришлось бы выполнить в apache, если бы я хотел, чтобы «виртуальные» ссылки на изображения указывали на записи базы данных. (например, AddHandler)
Насколько я понимаю:
- Если у вас есть сценарий, обслуживающий изображения: для каждого изображения потребуется вызов базы данных.
- Если вы отображаете встроенные изображения как двоичные данные: что можно сделать в один вызов базы данных.
- Для предоставления внешнего / связанного изображения, которые вам нужно будет добавить addHandler для расширения, которое вы хотите "подделать" и указать на свой язык сценариев (например, php, asp).
Возможно, я что-то упустил, но мне любопытно, есть ли у кого-нибудь идеи получше?
Редактировать: Том предложил использовать mod_rewrite для сохранения с помощью AddHandler, я принял как предлагаемое решение проблемы с AddHandler; однако я еще не чувствую, что у меня есть полное решение, поэтому, пожалуйста, продолжайте отвечать;)
Некоторые предложили использовать lighttpd вместо Apache. Насколько отличаются модули ISAPI для lighttpd?
Ответы 4
Наличие ваших изображений в базе данных не обязательно означает обращение к базе данных для каждого из них; вы можете кэшировать их отдельно на каждом хосте (например, во временных файлах), когда они будут извлечены. Исходные изображения по-прежнему будут в базе данных, и их будет легко синхронизировать между серверами.
Вам также действительно не нужно добавлять обработчики Apache для обслуживания изображения с помощью сценария PHP, сохраняя при этом хорошие URL-адреса - вы можете создавать URL-адреса, такие как http: //server/image.php/param1/param2/param3.JPG, и читать параметры через $_SERVER['PATH_INFO']. Вы также можете удалить часть URL-адреса 'image.php' (если вам это нужно), используя mod_rewrite.
Если вы храните изображения в базе данных, вы берете дополнительный удар базы данных плюс, вы теряете врожденную оптимизацию кэширования / обслуживания файлов на вашем веб-сервере. Apache будет обслуживать статическое изображение намного быстрее, чем PHP.
В наших больших средах приложений мы используем до 4 кластеров:
- Кластер серверов приложений
- Кластер веб-сервисов / сервисов данных
- Кластер статических ресурсов (изображения, документы, мультимедиа)
- Кластер базы данных
Вы будете удивлены, сколько трафика может обработать сервер статических ресурсов. Поскольку это не совсем вычисления (нет логики приложения), ответ можно безумно оптимизировать. Если вы выберете отдельный кластер статических ресурсов, вы также сможете изменить только эту часть своей архитектуры. Например, в некоторых тестах lighttpd обслуживает статические ресурсы даже быстрее, чем apache. Если у вас есть отдельный кластер, вы можете изменить свой http-сервер там, не меняя ничего другого в среде вашего приложения.
Я бы начал с двухмашинного кластера статических ресурсов и посмотрел, как это работает. Это еще одно преимущество разделения функций - вы можете масштабировать только там, где вам это нужно. Что касается синхронизации файлов, обратите внимание на существующие инструменты синхронизация файлов, а не на собственные. Вы можете найти что-то, что сделает то, что вам нужно, без написания строчки кода.
Привет, Корбин, спасибо за ответ. Честно говоря, я даже не подумал о кеш-памяти веб-сервера, вы правы, что веб-сервер может отвечать HTTP 200, а не HTTP 304 для изображений. Вы на 100% уверены, что веб-сервер не увидит URI и размер файла и ответит 304?
Я не слишком много думал о 200 против 304. Даже если сервер не улавливает это, вы можете закодировать свой обработчик, чтобы он возвращал 304. Когда я упоминаю оптимизацию обслуживания файлов, я больше думаю, что ваш сервер оптимизирован для обрабатывать статические файлы - кэшировать часто запрашиваемые файлы и избегать выполнения сценария.
Привет, Корбин, спасибо, я согласен. Однако при «подделке» HTTP 304 может возникнуть ловушка, если запись действительно изменилась. Я бы определенно предпочел, чтобы запрос изображения попадал в кеш до того, как он попадет в базу данных, однако должна быть какая-то недействительность кеша.
То, что вы ищете, уже существует и называется МогилеFS Настройка цели включает mogilefsd, реплицированные базы данных mysql и lighttd / perlbal для обслуживания файлов; Это обеспечит аварийное переключение и точную репликацию файлов (например, вы можете решить дублировать образы конечных пользователей на нескольких физических устройствах и сохранить только один физический экземпляр эскизов). Балансировка нагрузки также может быть достигнута довольно легко.
Привет, MatthieuP, Спасибо за очень интересный ответ! Мне придется разобраться в этом, но это звучит идеально!
Я обновил свой вопрос, мне любопытно: Чем отличаются модули ISAPI для lighttpd?
Раздача изображений из того места, где вы решили их хранить, - тривиальная проблема; Я не буду обсуждать, как это решить.
Решить, где их хранить, - вот реальное решение, которое вам нужно сделать. Вам нужно подумать о своих целях:
- Резервирование оборудования
- Много дешевого хранилища
- Чтение-масштабирование
- Масштабирование записи
Последние два не совпадают и определенно вызовут проблемы.
Если вы уверены, что размер этой библиотеки изображений не превысит размер диска, который вы с удовольствием поместите на свои веб-серверы (скажем, 200 ГБ на момент написания, поскольку это самые большие высокоскоростные диски серверного уровня, которые можно получить ; Я предполагаю, что вы хотите использовать веб-серверы 1U, поэтому вы не сможете хранить больше, чем это в raid1, в зависимости от вашего поставщика), тогда вы можете получить очень хорошее масштабирование чтения, разместив копии всех изображений на каждом веб сервер.
Конечно, вы можете захотеть сохранить где-нибудь и главную копию, и иметь демон или процесс, который время от времени синхронизирует их, и иметь мониторинг, чтобы убедиться, что они остаются синхронизированными, и этот демон работает, но это детали. Хранение копии на каждом веб-сервере сделает масштабирование чтения идеальным.
Но хранение копии повсюду разрушит масштабируемость записи, поскольку каждый веб-сервер должен будет записывать каждый измененный / новый файл. Поэтому ваша общая пропускная способность записи будет ограничена самым медленным отдельным веб-сервером в кластере.
«Разделение» данных изображения между многими серверами даст хорошую масштабируемость чтения / записи, но это нетривиальное упражнение. Это также может позволить вам использовать дешевое хранилище.
Наличие единственного центрального сервера (или пары активный / пассивный или чего-то еще) с дорогостоящим оборудованием ввода-вывода даст лучшую пропускную способность записи, чем повсеместное использование «дешевого» оборудования ввода-вывода, но тогда вы будете ограничены масштабируемостью чтения.
Спасибо за ответ MarkR, в настоящее время я обдумываю ответы здесь, чтобы увидеть, какое решение подходит мне лучше всего. Последнее, что мне нужно, это 4 разных сервера с несинхронизированными данными !! Я слышал много хорошего о Stackless IO, каково ваше мнение?
Привет, Том, спасибо за ответ. Использование mod_rewrite определенно позволит избежать использования Apache AddHandler. Я уже использую перезапись модов, поэтому реализовать это не составит особого труда.