Как решать капчу в задаче Celery (очередь на Python)

У задачи Celery, решающей капчу, есть одно правило, которое определяет всё остальное: решать нужно с нуля при каждой попытке. Celery обеспечивает доставку не менее одного раза, поэтому задача может выполниться дважды, а результат CapSkip читается только один раз. Сохраните id капчи, продолжите с него после повтора, и вы не получите ничего. Решите капчу, используйте токен и завершите работу, всё это внутри одного тела задачи.

Что понадобится

• Celery 5 с брокером, Redis или RabbitMQ. Выбор брокера позже повлияет на одну настройку.
• CapSkip, запущенный на машине с Windows, и клиент на Python, установленный в образ воркера.
• Server mode практически в любом реальном развёртывании. Воркеры обычно работают в Linux-контейнерах, а решатель нет.
• Sitekey и URL страницы, переданные как аргументы задачи, а не зашитые в неё.

# pip install capskip
pip install -U celery[redis] capskip

Шаг 1: сама задача

Всё решение умещается в один вызов. SDK отправляет запрос, опрашивает результат и возвращает токен, поэтому нет ни id, который надо тащить между шагами, ни чего-либо, что надо сохранять.

# pip install capskip
import os
from celery import Celery
from capskip import CapSkip, NetworkException

app = Celery("solves", broker="redis://redis:6379/0")

# CAPSKIP_HOST is the solver machine. Loopback only works if the
# worker runs on the same Windows box as CapSkip.
solver = CapSkip(
    host=os.environ.get("CAPSKIP_HOST", "127.0.0.1"),
    port=int(os.environ.get("CAPSKIP_PORT", "8080")),
    apiKey=os.environ.get("CAPSKIP_API_KEY", "capskip"),
)

@app.task(
    bind=True,
    autoretry_for=(NetworkException,),
    retry_backoff=True,
    max_retries=3,
    soft_time_limit=330,
    time_limit=360,
)
def solve_and_submit(self, sitekey, page_url):
    result = solver.recaptcha(sitekey=sitekey, url=page_url)
    return submit_form(page_url, result["code"])   # token, used here

Обратите внимание на то, чего здесь нет. В возвращаемом значении нет id капчи, нет второй задачи для отправки токена, нет результата, отложенного на потом. Токен используется в той же задаче, которая его получила. Причина кроется в тайминге, а не в аккуратности, и разбирается она ниже, в разделе про повторы.

Этот вызов относится к reCAPTCHA v2. Остальные типы, которые поддерживает CapSkip, устроены точно так же: передайте invisible или enterprise со значением 1, либо version со значением v3 и действие, либо вызовите turnstile или geetest. Полная поверхность API описана на странице сервиса распознавания капч для Python.

Шаг 2: два лимита времени и куда их поставить

По умолчанию в Celery нет лимита времени ни в одной из двух настроек. Для задачи, которая ждёт ответа сетевого сервиса, такое значение по умолчанию не подходит, потому что зависшее решение капчи занимает слот воркера навсегда.

Задайте обе настройки и выставьте их выше того, что допускает сам SDK. CapSkip отводит на решение reCAPTCHA, Turnstile или GeeTest триста секунд, а на картиночную капчу сто двадцать, и оба значения настраиваются в клиенте. Если первым сработает мягкий лимит, Celery выбросит SoftTimeLimitExceeded внутри вашей задачи, и вы потеряете собственное исключение SDK TimeoutException, а оно полезнее, потому что говорит: до решателя дозвонились, но работу он не закончил.

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

Шаг 3: правило повторов, специфичное именно для решения капчи

Автоматические повторы Celery идеально подходят для решателя, который перезапускается, и совершенно не подходят для токена, который у вас уже на руках. В этом различии стоит разобраться точно.

При retry_backoff со значением True первый повтор ждёт одну секунду, затем две, затем четыре, затем восемь, а джиттер включён по умолчанию, поэтому реальная задержка представляет собой случайное значение вплоть до этого максимума. Ограничение задаётся через retry_backoff_max и по умолчанию равно шестистам секундам. Сравните это с токеном reCAPTCHA, который живёт около двух минут.

Получается, что задача, которая успешно решила капчу, сохранила токен, упала на отправке и ушла в повтор, может возобновиться после задержки, в несколько раз превышающей срок жизни токена. Она упрётся в токен, который был совершенно действителен в момент создания, а лог обвинит целевой сайт. Этот сценарий отказа разобран в руководстве по истечению срока действия токена reCAPTCHA.

Исправление состоит в той форме задачи, что показана выше: решайте капчу внутри повтора, а не до него.

Ограничьте autoretry_for теми исключениями, которые описывают проблему транспорта. NetworkException означает, что CapSkip был недоступен, и такой случай стоит повторить. ApiException и ValidationException означают, что запрос был неверным и останется неверным. С TimeoutException придётся решать по обстоятельствам, и обычно он заслуживает одного повтора, а не трёх.

Шаг 4: acks_late и почему результат можно прочитать только один раз

По умолчанию Celery подтверждает сообщение прямо перед его выполнением, поэтому воркер, умерший посреди задачи, теряет работу. Включение task_acks_late переносит подтверждение на момент после завершения задачи, поэтому работа упавшего воркера доставляется повторно и выполняется снова. Обычно именно это и нужно для работы, которая где-то стоит денег, и именно из-за этого правило однократного чтения становится важным.

Результат CapSkip читается только один раз. Если первая попытка отправила капчу, прочитала токен и упала до подтверждения, повторно доставленная попытка уже не сможет перечитать этот id. Ей придётся отправлять заново. Задача выше делает именно так, потому что не хранит состояние между попытками, и повторное решение обходится в несколько секунд работы вашего собственного оборудования, а не во второе списание денег.

# Redelivery is safe here because the task resolves rather
# than resuming. Pair it with reject_on_worker_lost so a
# killed worker requeues instead of dropping the job.
app.conf.task_acks_late = True
app.conf.task_reject_on_worker_lost = True

# Long tasks and a prefetch of 4 means idle workers sit on
# queued jobs. Drop it to 1 for solve queues.
app.conf.worker_prefetch_multiplier = 1

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

Шаг 5: настройка брокера, которая дублирует решения

Если ваш брокер Redis, есть ещё одно число. У Redis нет собственного механизма подтверждения, поэтому Celery эмулирует его через visibility timeout: количество секунд, которое он ждёт подтверждения задачи от воркера, прежде чем передать сообщение другому воркеру. По умолчанию значение равно одному часу, и находится оно внутри broker_transport_options, а не существует как отдельная настройка.

Один час с запасом превышает трёхсотсекундное решение капчи, поэтому значение по умолчанию безопасно. Проблемы начинаются, когда его снижают, чтобы упавшие работы восстанавливались быстрее, ведь собственная документация Celery предупреждает: задача, время выполнения которой превышает visibility timeout, выполняется снова и снова, по кругу. Тогда каждое медленное решение капчи запускается минимум дважды.

# Keep this above your hard time limit, not near it.
# 3600 is the default and it is fine. If you must lower it,
# stay well clear of the 360 second time_limit above.
app.conf.broker_transport_options = {"visibility_timeout": 3600}

RabbitMQ подтверждает сообщения нативно и не имеет аналогичной настройки, и в этом состоит одна из причин предпочесть его для очередей, забитых медленными задачами.

Шаг 6: запуск решателя там, где воркеры смогут до него дотянуться

Воркеры Celery обычно работают в Linux-контейнерах на кластере. CapSkip работает на Windows. Поэтому на практике воркер и решатель находятся на разных машинах, и loopback здесь не подходит.

Для этого у CapSkip есть два режима подключения. Local привязывается к 127.0.0.1 и обслуживает только это устройство. Server привязывается к вашему сетевому адресу или публичному IP, поэтому другая машина, хост контейнеров или облачная платформа могут обратиться к той же машине с Windows по API. Оба режима находятся в разделе Настройки подключения, а Server mode меняет только то, по какому адресу слушает решатель. Оборудование по-прежнему ваше, и распознавание капчи по-прежнему безлимитное.

Именно последний пункт делает разумной саму идею очереди, которая срабатывает постоянно.

Читайте хост и ключ из окружения, а не из кода. Клиент на Python сам не читает ни CAPSKIP_HOST, ни CAPSKIP_PORT, ни CAPSKIP_API_KEY, именно поэтому задача из шага 1 читает их и передаёт клиенту. После этого контейнеру воркера нужны только эти переменные и больше ничего.

Решение множества капч одновременно

Способов два, и они подходят для разных форм работы. Обычный ответ выглядит так: одна задача на одну капчу, а параллелизм обеспечивает конкурентность воркера, и именно об этом замечание про предвыборку выше. Для пачки, которая приходит целиком, у клиента на Python есть настоящая асинхронная реализация, поэтому одна задача может собрать пачку внутри себя.

import asyncio
import os
from capskip import AsyncCapSkip

# AsyncCapSkip in Python is a real async client, not an alias.
async def solve_batch(pairs):
    solver = AsyncCapSkip(
        host=os.environ.get("CAPSKIP_HOST", "127.0.0.1"), port=8080)
    return await asyncio.gather(*[
        solver.recaptcha(sitekey=k, url=u) for k, u in pairs
    ])

@app.task(soft_time_limit=330, time_limit=360)
def solve_many(pairs):
    return [r["code"] for r in asyncio.run(solve_batch(pairs))]

Стоит знать, прежде чем переносить это на другой язык: клиенты для Node и .NET тоже называют класс AsyncCapSkip, но там он служит псевдонимом, а не второй реализацией. Python оказывается единственным языком, где это что-то значит. Полное сравнение приведено в руководстве по параллельному решению капчи на Python.

Частые ошибки и что они означают

Об ошибках с ключом стоит почитать отдельно, потому что один и тот же ответ покрывает и отсутствующий ключ, и просто неверный: как исправить ERROR_WRONG_USER_KEY.

FAQ

Коротко

Поместите решение капчи и всё, что использует токен, в одну задачу. Задайте мягкий лимит 330 и жёсткий лимит 360, чтобы собственный таймаут клиента сообщил об ошибке первым. Повторяйте только по NetworkException и позволяйте повтору решать капчу заново, а не продолжать с места остановки, потому что задержка перед повтором может намного пережить токен, а результат читается только один раз. Включите позднее подтверждение, снизьте множитель предвыборки до 1 и держите visibility timeout в Redis намного выше жёсткого лимита. Запускайте CapSkip в режиме Server mode всякий раз, когда воркеры находятся не на той же машине, что и решатель.

• Сам чекбокс reCAPTCHA v2 разобран на странице сервиса распознавания reCAPTCHA v2.
• Сырые эндпоинты, которые стоят за клиентом, описаны в документации CapSkip API.

И последнее, что стоит взвесить перед выбором размера очереди. CapSkip представляет собой распознавание капчи на оборудовании, которое у вас уже есть, поэтому сто воркеров, долбящих его без остановки, и один воркер, неспешно перемалывающий те же задачи, обходятся одинаково: в ноль.