Промяната на response.request.meta променя Python обект. За още едно изтегляне трябва да дадете на Scrapy друг Request за планиране.

За GET, който вашето callback изрично решава да повтори, публичният помощник за повторни опити на Scrapy може да запази отчитането на повторния опит с новата заявка:

from scrapy.downloadermiddlewares.retry import get_retry_request

def retry_through(self, response, proxy_url):
    retry = get_retry_request(
        response.request,
        spider=self,
        reason='choose_another_proxy',
    )
    if retry is None:
        return None
    retry.meta['proxy'] = proxy_url
    retry.headers.pop('Proxy-Authorization', None)
    return retry

Това е помощник за паяка. Извикващият трябва да върне или yield-не получения Request, когато има такъв. None означава, че помощникът е отказал още един повторен опит в рамките на приложимия лимит.

Помощникът за повторни опити копира заявката, обновява броя на повторните опити и осигурява поведение на планировчика, подходящо за повторен опит. Ако просто yield-нете същия URL като обикновена нова заявка, може да попаднете на филтриране на дубликати.

Използвайте URL на прокси, поддържан от включения HttpProxyMiddleware. За повторни опити на разрешени публични GET заявки, неудостоверен HTTP кандидат от списъка с HTTP прокси може да предостави proxy_url. Изчистването на предварително прикачено поле proxy-authorization избягва пренасянето на заглавие на стар посредник в този избор; оставете middleware да извлече новия акаунт от новия URL на прокси, когато е приложимо.

Дръжте този избор на ниво callback отделно от автоматичната обработка на конфигурираните откази от RetryMiddleware. Решете кой слой притежава повторния опит, за да не изразходва операцията два независими бюджета. Примерът се отнася до възпроизводима GET работа, а не до обещание, че повторението на произволна подадена транзакция е безопасно.

Подобни статии