Привет.

On Wed, Jul 29, 2015 at 01:43:11AM -0400, Budulianin wrote:
> >Но hash же не гарантирует равномерного распределения запросов по бэкендам,
> >он как раз гарантирует, что запросы с одинаковым id будут идти на одну и
> ту
> >же ноду.
>
> А где-то описывается алгоритм работы hash?
> Чтобы можно было понять наверняка, всегда ли с одним id на одну и туже ноду
> или нет.
> Я конечно проверю, но ещё хотелось бы что-то в документации прочитать по
> этому поводу.

Hash (как и другие алгоритмы баллансировки) учитывает состояние апстрима.
И если апстрим не доступен, то для маршрутизации запроса будет выбран один
из оставшихся.

Недоступным апстрим может считаться по нескольким причинам: не ответил в
течение заданного таймаута, ответил, но nginx оценил его ответ как
невалидный. Это конфигурируется с помощью директивы proxy_next_upstream.

Также обратите внимание на директиву max_fails. Хоть она и не фигурирует в
вашей конструкции, но тем не менее присутствует в виде 'max_fails=1'.
При каждом неуспешном ответе (или неответе в установленное время) nginx
будет помечать указанный сервер как недоступный (на 10 секунд по
умолчанию). И в этом случае nginx заново выберет актуальный апстрим для
указанного хэша и будет использовать его до тех пор пока он жив.

Для того чтобы это подтвердить, рекомендую посмотреть error_log на предмет
таймаутов от апстрима (они видны на уровне error). Также можно в access_log
добавить пременные $upstream_status и $upstream_addr. В этом случае в
access_log'е будут видны переходы с следующему апстриму.

--
Ekaterina Kukushkina

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru