Session affinity, consistent hashing и правильное решение

Пользователь входит в систему. Его сессия живёт на backend B2. Следующий запрос маршрутизируется на B3. Сессия не найдена. Пользователь выброшен из системы в середине работы. Это происходит, когда приложение хранит состояние на одном backend и полагается на session affinity, чтобы это скрыть — пока affinity не сломается.

Зачем нужны sticky sessions

Некоторые приложения хранят состояние сессии на backend — в памяти или в локальном файле. Если следующий запрос маршрутизируется на другой backend, состояния нет: пользователь выброшен из системы, корзина пуста, контекст загрузки утерян.

Sticky sessions (session affinity) заставляют LB маршрутизировать все запросы от одного клиента на один и тот же backend. Запросы клиента «прикреплены» к одному серверу.

Cookie-based affinity

LB устанавливает cookie при первом ответе:

Set-Cookie: LB_ROUTE=backend_2; Path=/

При каждом последующем запросе браузер отправляет этот cookie. LB читает его и маршрутизирует на backend_2.

Преимущества:

• Переживает смену IP клиента (handover мобильной сети, NAT failover).
• Допускает graceful failover: если backend_2 нездоров, LB может выбрать новый backend и обновить cookie.

Недостаток: Cookie-based affinity требует HTTP. Не-HTTP-протоколы использовать его не могут.

IP-hash affinity

Маршрутизация по Hash(client_IP) % num_backends. Cookie не нужен — работает для любого протокола.

Недостатки:

• Ломается при смене IP клиента (handover мобильной сети, переподключение VPN).
• Плохо кластеризует: 50 клиентов за одним корпоративным NAT все хешируются на один backend — этот backend получает нагрузку в 50 раз больше остальных.

Правильное решение: вынесенное состояние сессии

Храните данные сессии в распределённом кэше (Redis, Memcached, DynamoDB) по ключу session ID. Каждый backend читает из и пишет в этот хранилище.

Теперь LB может маршрутизировать запросы свободно с помощью power-of-two-choices. Без affinity. Без привязки. Данные сессии переживают отказы backends, потому что они в Redis, а не в памяти одного backend.

Этот паттерн используется в Netflix, Airbnb, Shopify и любом сервисе, масштабирующемся горизонтально.

Consistent hashing: для локальности кэша, не состояния сессии

Session affinity — о состоянии пользователя. Consistent hashing — о локальности кэша: маршрутизация ключа кэша на один и тот же backend для получения cache hit вместо miss.

Проблема round-robin для кэширования:

• Запрос user:42 → B1 (кэшировано там).
• Следующий запрос user:42 → B2 (cache miss, запрос к БД).
• Никакой локальности, никакой пользы от кэширования.

Consistent hashing отображает каждый ключ на точку кольца хешей. Backends тоже отображаются на точки (с множеством виртуальных узлов на backend для равномерного распределения, ~150–300). Ключ маршрутизируется к ближайшему backend по часовой стрелке на кольце.

Ключевое свойство: Когда backend входит или выходит, только ~1/N ключей переотображаются. Все остальные ключи остаются на том же backend. Это минимизирует нарушение кэша при изменениях топологии.

Стоимость поиска: O(log N) с отсортированным деревом (бинарный поиск по позициям виртуальных узлов).

Используйте consistent hashing для:

• Распределённых кэшей (Memcached shards, Redis cluster).
• Шардирования баз данных (маршрутизация по shard key).
• Sticky-маршрутизации запросов для локальности кэша (задачи кодирования медиа, аналитические агрегации).

Не используйте consistent hashing для общей балансировки запросов — power-of-two-choices адаптируется к реальной нагрузке в реальном времени, consistent hashing — нет.

Rendezvous hashing (highest-random-weight)

Альтернатива кольцевому consistent hashing:

1. Для каждого backend вычислите Hash(key, backend_id).
2. Маршрутизируйте на backend с наибольшим значением хеша.

Нет кольца, нет виртуальных узлов — проще реализовать. O(N) на поиск, но для малого N (<100 backends) разница незначительна. Распределение хеша зачастую более равномерно, чем у кольцевого consistent hashing на практике. Некоторые CDN и Facebook TAO используют rendezvous hashing для шардирования.