缓存与限流

热门股票在开盘时被大量重复查询，或者某个脚本失控后每秒发出几百个请求，怎样避免数据库和上游一起被拖垮？

缓存把已经读取或计算过的结果放在更近、更快的位置。TTL（Time To Live）规定结果保持新鲜的时间。历史日 K 收盘后变化较少，可以缓存更久；盘中最新价变化快，TTL 应更短，或者由实时流主动更新。

HTTP 缓存还可使用 Cache-Control: max-age=60 表达新鲜时间，用 ETag 与 If-None-Match 做条件请求。数据未变化时返回 304 Not Modified，可以避免重新传输响应体。对过期数据采用“先返回旧值、后台刷新”时，必须明确标记数据的时间和新鲜度。

三个常见问题：

• 击穿：热点 key 刚过期，大量请求同时回源。可用单飞或分布式锁，让同一 key 同时只有一个请求回源。
• 穿透：请求本不存在的对象，永远无法命中。可短暂缓存“确实不存在”，并先做参数校验。
• 雪崩：大量 key 同时过期。可给 TTL 加随机抖动，或分批刷新。

缓存 key 必须包含影响结果的全部参数，例如代码、日期、复权方式、分页和权限范围；否则可能返回错误或越权的数据。

令牌桶用两个参数控制请求节奏：桶容量决定允许的突发量，补充速率决定长期平均速度。请求消耗令牌，没有令牌时拒绝或等待。固定窗口、滑动窗口和并发数限制也常见。

被限流时通常返回：

HTTP/1.1 429 Too Many Requests
Retry-After: 2
Content-Type: application/json

{"code":"RATE_LIMITED","retryable":true,"detail":"请在 2 秒后重试"}

限流应优先按 API Key、账号或租户设计，IP 作为兜底；多台服务实例需要共享计数，否则每台机器各自放行会让总额度失控。客户端重试应采用指数退避和随机抖动，避免重试风暴。

class TokenBucket:
    def __init__(self, rate, capacity):
        self.rate = rate
        self.capacity = capacity
        self.tokens = capacity
        self.last = time.monotonic()

    def allow(self):
        now = time.monotonic()
        self.tokens = min(self.capacity,
                          self.tokens + (now - self.last) * self.rate)
        self.last = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

示例中 rate=5, capacity=10 表示长期平均每秒约 5 个请求，同时允许最多 10 个令牌积累出的突发；实际并发实现还需要锁或原子操作。

• RFC 9111：HTTP 缓存
• RFC 9110：HTTP 语义
• RFC 6585：429 状态码
• MDN：HTTP 缓存