📚 课程目录第1章 html

为什么需要限流降级？——高并发采集的第一道防线

做高并发采集，说白了就是跟资源较劲。

我记得刚入行那会儿，接手过一个爬虫项目。目标网站平时挺稳，结果一到双十一，服务器直接被打懵了。我那爬虫还在那疯狂发请求，最后不仅数据没采到，还把对方接口搞挂了。嗯，从那以后我就明白了一个道理——采集不是越快越好，稳才是王道。

高并发采集的三大痛点

你想想看，当你的爬虫从单线程升级到多线程，再从多线程升级到分布式，问题就来了：

资源竞争：CPU、内存、带宽，哪个先撑不住？
目标服务压力：对方接口扛不住，直接封你 IP。
数据一致性：并发写库，搞出脏数据。

我在项目中遇到过最典型的情况：一个爬虫集群 50 个节点，每个节点 20 个线程，同时往同一个 API 发请求。结果对方网关直接返回 503，连正常业务都受影响。说白了，这就是没做限流的后果。

核心观点：限流降级不是限制你的采集能力，而是保护你的采集系统不被自己搞垮。

限流 vs 降级：两个概念，一个目标

很多人把限流和降级混为一谈。我习惯这么区分：

维度	限流	降级
核心动作	控制请求速率	牺牲非核心功能
触发条件	流量超过阈值	系统资源不足
处理方式	排队、拒绝、丢弃	返回降级数据、关闭次要功能
典型场景	每秒最多 100 次请求	数据库挂了，用缓存顶

举个例子：限流就像高速公路的收费站，车多了就排队；降级就像遇到堵车，你绕道走小路。两者配合使用，才能保证系统不崩溃。

限流降级的核心价值

我总结了三句话：

保护采集端：防止自身资源耗尽，比如内存溢出、线程阻塞。
保护目标端：避免对目标服务造成冲击，减少被封风险。
保证数据质量：稳定的采集节奏，减少重试和重复数据。

个人经验：我建议在项目初期就把限流降级设计进去。等出问题了再加，成本至少翻三倍。

本章知识体系总览

先给你一张图，看看我们这一章要讲什么：

什么时候该用限流？什么时候该降级？

我个人的判断标准很简单：

限流：系统还能跑，但流量太大。比如每秒 1000 个请求，你只处理 200 个，剩下的排队或拒绝。
降级：系统快撑不住了，必须放弃一些东西。比如数据库连接池满了，先关掉日志写入功能。

避坑指南：我曾经在一个项目里只做了限流没做降级。结果限流把请求都堵在队列里，队列越积越多，最后内存溢出了。限流和降级一定要配合使用，缺一不可。

一个简单的限流示例

先看个最基础的限流实现，用 Python 写个令牌桶：

import time

class TokenBucket:
    def __init__(self, capacity, rate):
        self.capacity = capacity      # 桶容量
        self.tokens = capacity        # 当前令牌数
        self.rate = rate              # 每秒生成令牌数
        self.last_refill = time.time()
    
    def acquire(self, tokens=1):
        # 先补充令牌
        now = time.time()
        elapsed = now - self.last_refill
        self.tokens = min(self.capacity, 
                         self.tokens + elapsed * self.rate)
        self.last_refill = now
        
        # 判断是否足够
        if self.tokens < tokens:
            return False
        
        self.tokens -= tokens
        return True

# 使用示例
bucket = TokenBucket(capacity=10, rate=5)
for i in range(20):
    if bucket.acquire():
        print(f"请求 {i}: 通过")
    else:
        print(f"请求 {i}: 限流")
    time.sleep(0.1)

这段代码很简单，但核心思想都在了：有令牌就放行，没令牌就拒绝。后面我们会讲更高级的算法，但原理万变不离其宗。

本章小结

限流降级不是锦上添花，而是高并发采集的生存底线。我见过太多项目，功能做得花里胡哨，结果一上生产就被流量冲垮。记住：稳定的采集系统，一定是先保命，再办事。