任务队列明明在跑，为什么整体速度却越来越慢

原创于 2025-12-15 13:37:44 发布 · 608 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#队列 #多线程 #网络请求 #代理IP #16YUN #Redis #timeout

爬虫代理同时被 3 个专栏收录

382 篇文章

订阅专栏

python

262 篇文章

订阅专栏

多线程

58 篇文章

订阅专栏

任务队列越堆越多，
Worker 明明在跑，
机器资源看着也不紧张，
可就是——慢得离谱。

你盯着 Redis，看着那条队列曲线，心里只有一个疑问：

到底是谁在拖后腿？

更让人崩溃的是，你几乎找不到一个明确的“凶手”。没有 CPU 飙高，没有内存泄漏，日志也干干净净。系统看起来一切正常，但效率却在悄悄下滑。

这篇文章，我不打算从“理论上讲队列系统如何设计”开始，而是从一个真实得不能再真实的业务场景讲起。

一、事情是怎么变糟的

最开始，这个采集系统其实很朴素：

单机
Redis 当任务队列
requests 抓页面
一秒几十个请求

跑得挺舒服。

后来业务一上量，情况就变了：

目标站点多了
页面越来越重
封 IP 开始频繁出现

于是你顺理成章做了几件“看起来完全正确”的事：

接入16YUN代理IP
Worker 扩容，多进程、多线程一起上
请求失败自动重试
timeout 设大一点，别太激进

刚上线那天，你甚至有点得意。
结果没过多久，队列开始一点点变慢。

不是崩，是那种慢慢失血的慢。

二、大多数时候，队列真的不是问题

很多人第一反应都会怀疑队列本身：

Redis 扛不住了？
消费速度不够？
Python 性能太差？

但说句大实话：
如果你用的是 Redis，它几乎不太可能是第一个瓶颈。

真正的问题，往往出现在队列“后面”——
也就是 Worker 拿到任务之后，到底在干什么。

三、Worker 看起来在干活，其实是在等

这是最容易被忽略的一点。

你看到的表象是：

Worker 进程在运行
线程数也没减少
日志偶尔还在打印

但实际上，很多 Worker 正在做的事只有一件：

等网络。

尤其是在你引入代理 IP 之后。

四、网络本身就是一个延迟放大器

代理IP 是采集绕不开的东西，这点没什么好争的。

但它有一个副作用，经常被低估：

任何网络问题，都会被代理放大。

直连的时候：

DNS 慢一点
TCP 卡一下
请求 200～300ms 超时

换成代理之后：

建立连接慢
隧道不稳定
TLS 握手反复失败
一个请求卡 5～10 秒很常见

如果你 timeout 设得偏大，那基本等于：

一个任务可以独占一个 Worker 好几秒。

队列慢，就是这么悄无声息发生的。

五、一段“完全不像有问题”的真实代码

下面这段代码，我敢说你八成写过类似的。

Redis + requests + 爬虫代理

import redis
import requests
import time

# Redis 连接
redis_client = redis.Redis(
    host="127.0.0.1",
    port=6379,
    db=0,
    decode_responses=True
)

TASK_QUEUE = "crawl:task:queue"

# 16YUN代理
PROXY_HOST = "proxy.16yun.cn"
PROXY_PORT = 8080
PROXY_USER = "username"
PROXY_PASS = "password"

proxy_url = f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"

proxies = {
    "http": proxy_url,
    "https": proxy_url
}

Worker 主循环

def crawl(url):
    try:
        response = requests.get(
            url,
            proxies=proxies,
            timeout=10  # 看起来很“稳妥”
        )
        return response.status_code
    except Exception:
        return None


def worker():
    while True:
        task = redis_client.blpop(TASK_QUEUE, timeout=5)
        if not task:
            continue

        url = task[1]
        start = time.time()

        status = crawl(url)

        cost = time.time() - start
        print(f"[Worker] url={url} status={status} cost={cost:.2f}s")

代码本身没什么“明显错误”，
也正因为这样，它才危险。

六、慢队列真正的元凶藏在哪

这段代码里，有几个点组合在一起，效果非常致命。

timeout 太“仁慈”

10 秒 timeout，意味着什么？

意味着：

一个坏代理
一次卡死连接
就能白白耗掉一个 Worker 10 秒

线程一多，问题会被指数级放大。

所有失败被当成一种失败

except Exception:
    return None

代理错误、网络抖动、目标站点封禁，
全被混在一起处理。

结果就是：

坏代理一直被用
慢请求不断回流
队列永远清不干净

Redis 根本不知道你在“等”

对 Redis 来说：

任务已经被取走了

至于这个任务在 Worker 里是执行中，还是卡在网络里，它一无所知。

于是你看到的就是：

队列不怎么动
系统却没明显报错

七、让队列重新“活过来”的几个小改动

把 timeout 当成“刹车”，不是安全带

requests.get(
    url,
    proxies=proxies,
    timeout=(3, 5)  # 连接超时 / 读取超时
)

在采集系统里：

慢请求不是温柔，是灾难。

至少区分一下失败类型

except requests.exceptions.ProxyError:
    return "proxy_error"
except requests.exceptions.Timeout:
    return "timeout"

你不需要一开始就做得多精细，
但至少要知道——是谁在拖慢你。

给慢任务打个标签

if cost > 5:
    print(f"[WARN] 慢任务: {url}, cost={cost:.2f}s")

第一次看到这些日志时，你会突然明白：

原来不是队列慢，是这些请求太慢。

八、写在最后的一句实话

如果你的采集系统出现了下面这些症状：

队列越来越慢
资源利用率却不高
找不到明确瓶颈

那大概率不是架构不行，也不是 Redis 不行，而是：

你的 Worker 被“等待”悄悄耗死了。

而在采集系统里，
代理 IP，往往就是那个最容易制造“等待”的变量。