Привет. 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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
