真实世界的“慢”往往不是 CPU 太少，而是下游被打穿。促销瞬时流量、重试风暴、上游超卖都可能在几秒内把清算/账务/搜索等关键服务压垮。秒单把“限流与公平”做成平台能力：入口到服务网格统一策略、配额与优先级分层治理、端到端背压与重试纪律。目的很朴素——谁都快不如谁都稳。
限流算法不是选择题，而是组合拳。令牌桶（Token Bucket）适合表达“平均速率 + 峰值突发”，漏桶（Leaky Bucket）强制平滑输出，并发上限限制同时在飞的请求数量。秒单在聚合层配置“并发门 + 令牌桶”的双路：先控在飞，再控速率，避免排队无限膨胀。同时引入自适应并发（AIMD/Gradient），以响应时间/错误率的趋势动态调低上限，把“问题出现前的征兆”变成早降档。
公平调度是第二根支柱。平台将配额分三层：租户级（商家/渠道）、产品路由级（下单/查询/清算）、客户端级（APP/小程序/开放 API）。每层都有权重与爆破阈值，并采用 WFQ/SFQ 等加权公平队列，让“占用者越多、边际越少”。秒单还给“高价值/高风控”流量保留独立车道：当系统进入 Brownout 模式，非关键路径降级，高价值车道优先通行，确保核心体验不塌。
架构层面，限流既要全局一致，也要局部容错。全局配额使用分布式计数（如 Redis 原子脚本/一致性哈希分片），配合短 TTL 与时钟漂移校正；机房隔离时，回落到本地近似限流，保证“宁可略松，不可全停”。秒单把限流策略下沉至服务网格（Sidecar）：熔断/重试/超时统一下发，开发无需重复造轮子，策略切换可在秒级完成。
限流永远伴随背压与重试纪律。入口收到 429/503 后采用 指数回退 + 抖动，禁用同步“风暴式”重试；对幂等读请求允许层级化重试（边缘→近源→主源），对写请求严格单次、失败转补偿队列。秒单用 Timeout Budget 控制“在下游已紧张时，上游不能把额外压力转给它”，并通过 Hedged Requests 只在 P99 长尾时使用替身请求，避免把平均性能拉坏。
热点与倾斜同样要治理。对热 Key，秒单使用副本扩散/本地直达/结果缓存的组合，配合 请求合并（Request Coalescing） 减少击穿；对追热点行为，平台侧做速率分段：越接近热点，增量越小。队列策略上，关键路径用 FIFO 保证公平，弱一致查询允许 LIFO 以缩短尾部，但一旦超出阈值立即回到 FIFO。所有策略以 SLO 优先：只要护栏破线，就触发 Brownout（降低刷新、屏蔽次要特效）、扩容或水闸限流。
运营侧要有可观察与可教育。看板不是“流量多少”，而是“谁在用配额、谁在逼近阈值、谁在持续触发 429/熔断”。配额可视化给租户与产品经理看，告诉他们“继续加量的代价”。秒单要求每次大促前做“配额演练”：基于历史峰值回放 + 速率整形，验证各条车道的护栏会不会提前亮灯。值班 Runbook 里明确“先降哪个路由、再降哪个特效、最后去哪条安全出口”。
限流不是刹车，而是交通规则。只有规则一致、反馈清晰，系统里每个参与者才知道怎样“快而不撞”。在 秒单 的治理里，公平与配额并非“反增长”，它们恰恰让增长有边界、有顺序、有余地。
