Проблема с многоступенчатой отправкой изображения на сервер с балансировкой нагрузки

#php #apache #load-balancing #squid

#php #apache #балансировка нагрузки #squid

Вопрос:

У нас есть два веб-сервера apache / php, балансировка нагрузки которых осуществляется с помощью прокси-сервера squid для кэширования страниц. Кэширование squid не активировано на страницах отправки изображений. У нас есть форма, в которой пользователи могут отправлять изображения.

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

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

У нас на этих серверах тысячи файлов изображений, поэтому синхронизация между ними происходит медленно. Можем ли мы каким-либо образом заставить определенную страницу всегда обслуживаться с определенного сервера? В основном для обхода функции балансировки нагрузки.

Комментарии:

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

Ответ №1:

Для этого есть несколько решений.

  1. Переключитесь на nginx в качестве обратного прокси, и вы сможете подключать клиентов к хосту
  2. Сделайте каталог загрузки общим ресурсом NFS, установленным на обоих хостах
  3. Загрузите файл в таблицу mysql (вероятно, лучше всего использовать хэш-таблицу), чтобы оба сервера могли получить к нему доступ.

Лично я бы выбрал вариант 1, поскольку вы по-прежнему получаете циклическую балансировку нагрузки, но каждое соединение привязано к хосту, к которому оно было изначально подключено.

Преимущество варианта 2 заключается в том, что запросы по-прежнему одинаково балансируются, но недостатком является общий ресурс NFS, который является единственной точкой отказа.

Вариант 3 может вызвать проблемы, если на сервере БД недостаточно оперативной памяти, если вы используете хэш-таблицу.

Комментарии:

1. Похоже, что # 2 — лучший вариант.

Ответ №2:

Я вижу два варианта, близких к ответу Джеффри.
1. Загрузите изображения в каталог загрузки, синхронизированный через rsync.
Тогда количество изображений было бы намного меньше, и они синхронизировались бы намного быстрее.
После того, как вы пройдете весь процесс, вы можете переместить изображение в нужную папку.
2. DB: хранение не самого изображения, а URL изображения, чтобы вы всегда знали, на каком сервере оно хранится, и имели к нему доступ.
Всего два варианта, которые появились при чтении ответа Geogrey и поиске информации, связанной с этой темой.