Комментарии 24
После многолетних игр с PHP-сессиями пришёл к выводу, что при малейшем намёке на горизонтальное масштабирование апп(php-fpm)-серверов нужно делать их стейтлесс с разделяемыми всеми инстансами хранилищами данных, в том числе хранилищами сессий.
Приклеенные сессии несут много проблем, например выбивая пользователей при падении ноды или при вводе новой ноды при росте нагрузки не снимают нагрузку со старых сразу, а только по мере окончания текущих сессий.
Думаю, это справедливо и для других платформ. А вот для А/Б тестирования приклеивание варианта на веб-сервере очень хорошо работает, позволяя выкатить два приложения одновременно, а не писать приложение с двумя вариантами внутри.
Приклеенные сессии несут много проблем, например выбивая пользователей при падении ноды или при вводе новой ноды при росте нагрузки не снимают нагрузку со старых сразу, а только по мере окончания текущих сессий.
Думаю, это справедливо и для других платформ. А вот для А/Б тестирования приклеивание варианта на веб-сервере очень хорошо работает, позволяя выкатить два приложения одновременно, а не писать приложение с двумя вариантами внутри.
+3
Последнее время храню сессии в редиске. Работает шустро, и мне без разницы на какую ноду попадет пользователь
+1
То, что вы показали как использовать Lua, это хорошо, спасибо.
Но тут можно было обойтись чистым nginx'ом, на if'ах и несколько групп upstream'ов, cookie можно выставить непосредственно из приложения.
Ну и в довершении покажу Вам вот это — ngx_stream_split_clients_module
Но тут можно было обойтись чистым nginx'ом, на if'ах и несколько групп upstream'ов, cookie можно выставить непосредственно из приложения.
Ну и в довершении покажу Вам вот это — ngx_stream_split_clients_module
0
Чистого Nginx-а не достаточно, и о split модуле я писал в конце статьи. К тому же он реализует не такой случайный разброс как хотелось бы. А чтобы выставлять нужные куки нужным клиентам бэкенд нужно соответственно модифицировать. И настроить эту часть без участия бэкенда гораздо удобнее.
0
обычно "липкие", они же sticky, сессии нужны только когда бэкенд знает зачем они ему, например, поднимает сессию на сервере приложений. А зачем бэкенду, которому в принципе все равно на пользователей, мапить юзеров на те же сервера?
0
Можно ли этот модуль использовать в связке с mod_uid, чтобы назначать пользователями рандомные, но постоянные куки и по ним разделять? Проблема в том, что нужно использовать переменную одну из $uid_set
или $uid_got
— смотря какая заполнена.
0
Если вопрос к комментатору выше, про модуль split — то он просто задаёт соответствие входящим клиентам определённые значения, согласно желаемому распределению. Далее эти значения можно использовать как нужно.
Но Lua в дополнение к имеющимся методам nginx-a добавляет возможность обработать запрос методами языка программирования. Те же $uid_set или $uid_got и прочие значения можно проанализировать и изменить и куки сопоставить.
Но Lua в дополнение к имеющимся методам nginx-a добавляет возможность обработать запрос методами языка программирования. Те же $uid_set или $uid_got и прочие значения можно проанализировать и изменить и куки сопоставить.
0
Скорее не клиентам, а запросам. То есть после F5 клиент может попасть в другую группу?
0
При модуле split задаётся параметр по которому высчитывается хеш и от него разброс (например IP адрес). В таком раскладе, при правильных параметрах, клиента не должно кидать с сервера на сервер.
Но в нашем случае, этот вариант не был удобен, во первых из за параметров хеширования. А во вторых, из-за дальнейшей обработки сопоставленных переменных. Напрямую upstream не сопоставишь, нужно либо реврайт писать, либо на стороне бэкенда обрабатывать или ещё как.
А так получилась полная независимость от бэкенда и желаемое равномерное распределение, не зависимое от параметров клиента. Плюс к этому возможность в дальнейшем отфильтровать группы клиентов по каким-то признакам.
Но в нашем случае, этот вариант не был удобен, во первых из за параметров хеширования. А во вторых, из-за дальнейшей обработки сопоставленных переменных. Напрямую upstream не сопоставишь, нужно либо реврайт писать, либо на стороне бэкенда обрабатывать или ещё как.
А так получилась полная независимость от бэкенда и желаемое равномерное распределение, не зависимое от параметров клиента. Плюс к этому возможность в дальнейшем отфильтровать группы клиентов по каким-то признакам.
0
>>if num > 20 then
Я б такое вынес в словарь на shmem. Это позволило бы менять настройку не перечитывая конфиг, и уж тем более не перезапуская nginx.
Я б такое вынес в словарь на shmem. Это позволило бы менять настройку не перечитывая конфиг, и уж тем более не перезапуская nginx.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Nginx + Lua, гибкая балансировка нагрузки с сохранением сессии