Re: nginx-0.7.44

[Andrew Kopeyko <kaa@xxxxxxxx>]

On Tue, 24 Mar 2009, Maxim Boguk wrote:

> Andrew Kopeyko wrote:
> > On Tue, 24 Mar 2009, Maxim Boguk wrote:
> >
> > > Igor Sysoev wrote:
> > > > Изменения в nginx 0.7.44 23.03.2009
> > > >
> > > >     *) Добавление: предварительная поддержка кэширования в модуле 
> > > > 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 модуле и сделать аналогичную 
> логику для распределенного кеша я особой проблемы не вижу.
Да, на участке frontend-backend всё так и работает.

Но ты же описывал участок frontend-frontend, не так ли?

Вот я и говорю, что твоя схема обладает существенным недостатком - 
фронтенды она делает _разными_, и, разумеется, плохо переносит выпадение 
одного из фронтендов, ибо они становытся уникальными и незаменяемыми.
--
Best regards,
Andrew Kopeyko <kaa@xxxxxxxx>