17370845950

失败任务应使用 requests + urllib3.Retry 实现指数退避重试，设置 total、status_forcelist 和 backoff_factor；任务状态需持久化至 Redis 或原子写入 JSONL 文件；异步爬虫中用 asyncio.timeout 包裹请求并 create_task 提交重试；超限失败任务应入死信队列并记录原因。

失败任务怎么自动重试？用 requests + 指数退避最靠谱

直接硬循环重试会触发反爬限流，requests 默认不带重试逻辑，必须手动加。核心是控制重试次数、间隔和异常类型，别一遇到 ConnectionError 或 Timeout 就狂试。

• 用 urllib3.Retry 配合 requests.adapters.HTTPAdapter，比自己写 while 循环更可控
• 重点设 backoff_factor（比如 0.3），它会让第 n 次重试等待 backoff_factor * (2^(n-1)) 秒，避免雪崩
• 只对网络层错误重试，别对 404 或 403 重试——那是业务状态，不是临时故障

from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
session = requests.Session()
retry_strategy = Retry(
total=3,
status_forcelist=[429, 500, 502, 503, 504],
backoff_factor=0.3,
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session.mount("http://", adapter)
session.mount("https://", adapter)

任务状态怎么持久化？别全靠内存存 queue

程序崩溃或重启后，内存里的待爬队列就丢了。得把「已取未完成」「失败待重试」的任务落地，否则回收机制形同虚设。

• Redis 是首选：用 LPUSH/RPOP 做可靠队列，配合 BRPOP 阻塞读取，天然支持多进程/多机消费
• 如果不用 Redis，至少用文件+原子写入：把任务 ID 和元数据（URL、重试次数、上次失败时间）存成 JSONL，每次消费前 flock 加锁
• 别用 pickle 序列化任务对象——跨 Python 版本或代码变更后很可能反序列化失败

asyncio 爬虫里怎么安全回收失败请求？小心协程泄漏

异步环境下，没处理完的 async with session.get(...) 可能卡住整个事件循环，而且 try/except 不捕获所有异常类型。

• 必须用 asyncio.timeout() 包裹请求，防止某个 URL 死等（比如 DNS 卡住）
• 失败后别直接 await asyncio.sleep() 然后重试——这会阻塞当前协程；改用 asyncio.create_task() 提交重试任务，并加个最大重试计数限制
• 所有异常要显式 catch asyncio.TimeoutError、aiohttp.ClientError、UnicodeDecodeError（响应编码异常）

import asyncio
import aiohttp
async def fetch_with_retry(session, url, max_retries=2):
for i in range(max_retries + 1):
try:
async with asyncio.timeout(10):
async with session.get(url) as resp:
return await resp.text()
except (aiohttp.ClientError, asyncio.TimeoutError, UnicodeDecodeError) as e:
if i == max_retries:
raise e
await asyncio.sleep(0.5 * (2 ** i))  # 指数退避
return None

重试太多次还是失败？该进死信队列还是丢弃？

不是所有失败都要无限重试。持续失败的任务可能是目标页面已下线、参数非法、或风控永久封禁，继续重试只会浪费资源、暴露 IP。

• 设定硬性重试上限（比如 5 次），超限后写入「死信队列」（redis list 名为 dead_tasks），供人工排查或定时归档
• 记录失败原因（HTTP 状态码、异常类型、响应头 X-RateLimit-Remaining 等），别只记个 "failed"
• 对高频失败的目标域名，自动触发降频策略：暂停该域名任务 5 分钟，或切到备用代理池

真正难的不是写重试逻辑，而是判断什么时候该停——这需要结合日志、监控和业务语义，纯技术方案兜不住所有情况。