*) Добавление: предварительная поддержка кэширования в модуле
ngx_http_proxy_module.
Возможно я много хочу... но хотелось бы поднять следующую проблему
(которая еще и с mod_accel была):
когда frontend не один а N эффективность кеширования падает в N раз и
пропорционально растет нагрузка на backend.
Что хочется... если уж есть механизм вычисления cache key готовый...
хотелось бы иметь возможность указывать что если (в случае 3х
frontends):
key%3 = 0 то локально работать с локальным кешем
если key%3 = 1 то идти к серверу N2 и получать (не кешируя) ответ от
него
если key%3 = 2 то идти к серверу N3 и получать (не кешируя) ответ от
него
Т.е. используется следующий алгоритм:
1. вычисляется ключ кэша, проверяется "свой-чужой"
2. если "свой", идем в свой кэш; если там нет, то на бэкэнд, ответ
кэшируем
3. если "чужой", отправляем запрос на другую машину, а та уже либо
отдаёт из кэша, либо запрашивает бэкэнд и кэширует (локально ответ не
кешируем).
т.е. получаем exclusive распределенный кеш (ценой увеличения
внутрисерверного траффика и дополнительного хопа на часть ответов).
+ более устойчивую систему к выходу из строя одного из frontends так
как потеряется не весь кеш а только 1/N часть
Устойчивость как раз понизится - пользователь увидит "502 fateway
timeout"
Потому что значение key%3 не зависит от числа живых фронтендов, и,
поскольку "мужики-то не знают" про падения друг-друга - в твоей схеме
живые фронтенды по-прежнему будут переправлять часть запросов к
упавшему товарищу.
В этой ситуации "равноправные фронтенды" ведут себя лучше.
Вообще метод борьбы с упавшим сервером давно известен. Если получили от
какого то из других серверов 502 или 503 или еще какую то ошибку можно
сделать fallback и самостоятельно сходить к backend'у.
Все эти проблемы уже частично решены в upstream модуле и сделать
аналогичную логику для распределенного кеша я особой проблемы не вижу.
