У нас есть веб-приложение на основе Java EE, работающее на Стеклянная рыба кластер серверов приложений. Входящий трафик в основном будет представлять собой запросы RESTful для представлений ресурсов нашего приложения на основе XML, но, возможно, 5% трафика может приходиться на представления на основе JSON или XHTML / CSS.
Сейчас мы изучаем решения по балансировке нагрузки для распределения входящего трафика между экземплярами Glassfish в кластере. Мы также изучаем, как разгрузить кластер с помощью memcached, распределенной хэш-карты в памяти, ключами которой будут имена ресурсов REST (например, «/ user / bob», «/ group / jazzlovers») и чьи значения соответствующие представления XML.
Один из подходов, который звучит многообещающе, - убить обоих зайцев одним выстрелом и использовать легкий и быстрый nginx HTTP-сервер / обратный прокси. Nginx будет обрабатывать каждый входящий запрос, сначала просматривая его URI в memcached, чтобы увидеть, есть ли там еще не истекшее XML-представление. Если нет, nginx отправляет запрос одному из экземпляров Glassfish. Модуль nginx memcached описан в эта короткая запись.
Каково ваше общее впечатление от использования nginx и memcached таким образом, насколько вы довольны ими? Какие ресурсы вы считаете наиболее полезными для изучения их? Если вы попробовали их, и они не подошли для ваших целей, почему бы и нет, и что вы использовали вместо них?
Примечание: вот связанный вопрос. Прежде чем я узнал о ServerFault, я спросил об этом Переполнение стека.
Изменить: все ответы здесь до сих пор были весьма полезными, хотя прямого опыта не было. Этот ответ в конечном итоге появился на StackOverflow, и это было довольно оптимистично для настройки nginx / memcached.
Вам действительно следует использовать кеш-сервер перед своими веб-серверами. Рекомендую Varnish-cache. Мы используем его при работе с самым крупным и загруженным сайтом в Скандинавии. Мы заменили 13 высоконагруженных ящиков с кальмарами 1 ящиком для лака и 1 запасным.
Я протестировал простое приложение на своем частном веб-сайте, и оно увеличилось с 9 запросов в секунду до более 2000.
Вы решаете, как долго он хранит данные в памяти, вы можете сделать это до конца времени, а затем просто отправить HTTP-запрос на очистку кеш-серверу при изменении данных.
Мое личное мнение, исходя из опыта, заключается в том, что если вы используете балансировщик нагрузки, вы хотите полностью ограничить этот блок функциями балансировки нагрузки. Если ваш балансировщик нагрузки обслуживает контент, даже из кеша, ухудшается функциональность балансировки нагрузки в ситуациях высокой нагрузки (большее количество подключений остается активным дольше, что снижает общую емкость и пропускную способность).
Я бы посоветовал, чтобы приложение само выполняло поиск и обслуживало кешированный контент, а балансировщик нагрузки делал свою работу. Сказав это, nginx не идеален, когда дело доходит до балансировки нагрузки - он предлагает только очень простой алгоритм циклического перебора. Я бы порекомендовал вместо этого haproxy. По моему опыту, если вам нужны услуги дешифрования SSL, nginx работает хорошо, сидя перед haproxy.
Думаю, вы зайдете в тупик, если вам понадобятся такие вещи, как балансировка нагрузки, высокая доступность и т. Д.
Также рассмотрите такую ситуацию: когда пользователь авторизован, страница выглядит иначе, с дополнительными функциями, доступными и индивидуализированными для каждого пользователя. URL-адреса одинаковы для удобства связывания и т. Д. Например, сайт, на котором авторизованному пользователю не нужно вводить свое имя / кодировку для комментариев, или сайт отображает ваше имя пользователя вверху, когда вы вошли в систему (например, serverfault). В таких случаях nginx будет невозможно использовать, потому что вы не сможете отличить авторизованного пользователя от неавторизованного.
Если вам не нужен SSL, я бы посоветовал вам запустить Varnish. Он был разработан как HTTP Accelerator, а не как веб-сервер или прокси. Если вам нужен SSL, запустите nginx поверх как SSL-ускоритель и лак как обычный HTTP-ускоритель, потому что Varnish не может работать с SSL.
Я думаю, что выбор кеширующего сервера зависит от приложения, и вы не можете делать обобщенные комментарии по этому поводу без глубокого анализа приложения.
мой выбор - haproxy. Очень маленький и очень быстрый обратный прокси, но не кеш-прокси! Я использую для своей системы кеширования "Squid Web Proxy"
CACHE /squid/ -> Load-balancing /Haproxy/ -> WEB I /lighttpd/
-> WEB II /lighttpd/
-> WEB III /lighttpd/
Эта работа идеально подходит для моей веб-системы