Концепции4 мин чтения

Ротируемые и sticky-прокси: планируйте непрерывность сессии

Выбирайте ротацию под наименьший законченный сценарий, отличайте привязку к выходу от cookie и проверяйте, что происходит, когда sticky-сессия завершается раньше срока.

На этой странице

С чего начать

Полезный вопрос — как долго рабочему процессу нужен один и тот же выход и что должно делать ваше приложение, когда эта непрерывность исчезает.

Прочитайте, как провайдер определяет сессию

«Ротируемые» и «sticky» описывают политики выбора выхода. Ротация обычно меняет назначенный выход между запросами, соединениями или временными окнами. Sticky запрашивает привязку к одному выходу на время определённой сессии. Триггер, длительность и поведение при отказе зависят от провайдера; универсального параметра в имени пользователя для всех сервисов не существует.

Например, Decodo документирует ротацию мобильных выходов на каждый запрос и настраиваемые sticky-сессии, но предупреждает, что выход может исчезнуть раньше запрошенной длительности. Относитесь к заявленной провайдером длительности сессии как к тому, что нужно проверить, а не как к замене пути восстановления в приложении.

Согласуйте сессию с законченным рабочим процессом

Рассмотрим тест оформления заказа в вашем собственном staging-магазине: загрузить товар, добавить его в корзину и проверить расчётный срок доставки. Практичная отправная точка — один контекст браузера и одна прокси-сессия на весь этот сценарий. Сохраняйте и то и другое неизменным до завершения проверки, затем удалите состояние сценария.

Для независимых проверок региональной доступности каждая проверка может быть отдельной единицей. Снабжайте каждый результат целевым регионом, наблюдаемым выходом (если он доступен) и меткой времени. Не предполагайте, что новый выбранный выход уникален или что смена выходов даёт более высокий лимит запросов.

Разделяйте три вида состояния

Диагностика становится понятнее, когда перечисленное ниже логируется как отдельные, несекретные идентификаторы. Прокси-сессия не может восстановить потерянное хранилище cookie, а сохранённое хранилище cookie не может заставить недоступный выход вернуться.

  • Сессия приложения: cookie, токены и состояние, которыми владеет целевой сайт.
  • Клиентское соединение: TCP-соединение или переиспользуемый пул соединений.
  • Прокси-сессия: сопоставление идентификатора сессии с выходом на стороне провайдера.

Проверьте истечение сессии, прежде чем повышать параллелизм

Выберите разрешённую диагностическую конечную точку и выполните несколько последовательных запросов внутри запрошенного окна сессии. Зафиксируйте наблюдаемый выход. Повторите после документированного истечения и отдельно проверьте принудительное переподключение. Помечайте это как измерения на вашей выборке, а не как гарантию для всего пула.

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

Перед выпуском

  • Определите один законченный рабочий процесс, прежде чем выбирать длительность сессии.
  • Держите состояние cookie и привязку к прокси раздельно.
  • Проверьте досрочную потерю выхода и истечение сессии на небольшой выборке.

Источники и дополнительное чтение

Технические материалы, использованные при подготовке руководства. Сверяйтесь с документацией вашей версии и с поддерживаемой конфигурацией вашего провайдера.