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

亿牛云爬虫专家
44 阅读4分钟

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

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

到底是谁在拖后腿？

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

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

一、事情是怎么变糟的

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

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

跑得挺舒服。

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

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

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

  1. 接入16YUN代理IP
  2. Worker 扩容，多进程、多线程一起上
  3. 请求失败自动重试
  4. 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，往往就是那个最容易制造“等待”的变量。

avatar
文章
阅读
粉丝