Я планирую иметь такую архитектуру:
nginx - nginx - nginx - nginx
\ \ / /
varnish
/ | \
app server - app server - app server
(Все серверы приложений «идентичны» в том смысле, что запрос может быть перенаправлен на любой из них с помощью Varnish.) Varnish на этой диаграмме будет обрабатывать (потенциально) сотни тысяч запросов в секунду. Он может это сделать?
Я бы предпочел запустить несколько серверов Varnish по причинам аварийного переключения и производительности, но непосредственная проблема, которую я вижу, заключается в том, что кеширование не будет иметь большого смысла, потому что каждый запрос будет попадать на другой сервер Varnish, пока на каждом из серверов Varnish не будет копия кешированного объекта. Как правильно это сделать? (Опять же, серверы приложений идентичны Varnish, не имеет значения, на какой запрос направлен. Я бы хотел, чтобы несколько серверов Varnish (за балансировкой нагрузки nginx) обрабатывали запросы.)
Недавно я столкнулся с тем же вопросом. Varnish может обрабатывать довольно много запросов в секунду, но вы должны протестировать его со своими настройками (оборудование, сеть, размер ответов, коэффициент попадания), чтобы получить представление о показателях производительности. Помимо производительности, существует проблема переключения при отказе для начала балансировки.
если URL-адреса являются вашим ключом кеша, вы можете настроить механизм в nginx, который выбирает конкретный экземпляр лака на основе URL-адреса (varnish_instance = hash (url) modulo nr_of_varnishes). Если varnish перезаписывает URL-адрес до того, как перенаправит его на серверную часть или выполняет поиск в кеше, и разные URL-адреса перезаписываются на один и тот же новый URL-адрес, тогда этот трюк не эффективен.
в моем случае я не могу выполнить маршрутизацию на основе URL-адреса в балансировщике нагрузки. Мы используем lvs-dr и просто не знаем URL в балансировщике.
Я поигрался с идеей настроить такой механизм распределения в лаке. Можно настроить другие лаки как «внутренние», вычислить хэш и направить запрос к нужному лаку. «Правильный» лак выполняет внутренний вызов и сохраняет его в кеше. Другие лаки также могут сохранять результаты, но не обязательно. Такая настройка усложняет конфигурацию лака, поэтому хорошо подумайте, прежде чем выбирать такой путь. Прямая маршрутизация (часть lvs-dr) делает его еще более сложным.
В итоге я выбрал простое решение: распределить запросы по 2 большим экземплярам лака без всяких хитростей. Результаты вычисляются и кэшируются дважды, но конфигурации лака были максимально простыми.