Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: nginx-0.7.44
Hello!
On Tue, Mar 24, 2009 at 01:37:43PM +0300, 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 модуле и сделать
> аналогичную логику для распределенного кеша я особой проблемы не вижу.
В принципе - никто не мешает сделать это сейчас, но ценой
дополнительного хопа для всех запросов. Просто с помощью
upstream'а с хешированием по $uri.
Maxim Dounin
|