解读

国内 Rust 后端/云原生面试中，背压（back-pressure）是高频性能考点。面试官通过对比 bounded 与 unbounded channel，考察候选人是否真正理解“内存安全 + 高并发 + 零停机”三角约束下的资源治理思路。回答时务必先给结论，再给量化数据，最后给线上故障案例，体现“编译通过即正确”之外的工程判断力。

知识点

1. 背压本质：当下游消费速度 < 上游生产速度时，系统通过阻塞或丢弃强制上游减速，防止内存无限增长导致 OOM。
2. bounded channel（sync_channel(n)）：
   • 容量固定为 n，发送端在 n 个消息未消费完时阻塞；
   • 阻塞行为直接产生同步背压，将压力瞬间传递回上游，CPU 利用率立即下降，内存占用可预测；
   • 适用于严格限流场景，如网关 QPS 熔断、日志队列。
3. unbounded channel（channel()）：
   • 底层为链表 + 原子引用计数，容量仅受堆内存上限约束；
   • 发送永不阻塞，背压延迟到 OOM 时才暴露，造成毛刺延迟甚至进程被杀；
   • 适用于突发流量可接受内存换延迟的场景，如异步后台任务扇出、短周期埋点。
4. 调度器差异：
   • Tokio 的 bounded 在发送端阻塞时会 yield 当前任务，不会阻塞 OS 线程；
   • async-std 的 unbounded 在高并发下可能触发 allocator 锁竞争，延迟长尾可放大 10 倍。
5. 监控指标：
   • bounded 重点看**send_timeout 次数与channel饱和度**；
   • unbounded 重点看**heap_bytes 增长率与major page faults**。

答案

“背压差异一句话：bounded 用阻塞换内存，unbounded 用内存换延迟。”
具体而言：

1. 触发条件：bounded 在容量满时立即阻塞发送端，背压同步生效；unbounded 只在内存耗尽时才触发 OOM-killer，背压异步且滞后。
2. 内存曲线：bounded 的内存上限 = n × 单条消息大小，可静态计算；unbounded 的内存上限 = 堆上限，动态不可控。
3. 延迟表现：bounded 在满载时 P99 延迟突增但无长尾毛刺；unbounded 平时延迟低，内存紧张时触发 GC 或 swap，P99 可瞬间放大百倍。
4. 线上案例：某头部云厂商日志网关曾用 unbounded channel，双 11 凌晨 2 点内存 30 s 内从 2 G 涨到 14 G，被 k8s OOMKill 重启，丢失 7 秒日志；后改为 bounded + 自适应批刷，内存稳定在 1.2 G，零丢失。
5. 选型建议：
   • 入口流量必须 bounded，容量按**“峰值 QPS × 最大容忍阻塞时间”**估算；
   • 内部异步扇出可 unbounded，但须配套内存硬限制 + 水位报警 + 降级丢弃；
   • 若需无阻塞又可控，可用bounded + try_send + 自旋退避或tokio::sync::Semaphore做用户态背压。

拓展思考

1. 混合背压策略：将 channel 拆成三级队列（bounded 热队列 + unbounded 冷队列 + 磁盘溢出队列），通过水位标记动态升降级，兼顾延迟与可靠性，已在国产分布式数据库 TiKV 中落地。
2. 无锁实现：crossbeam 的 bounded 采用序列锁 + 缓存行对齐，单线程生产消费时延迟 < 15 ns；若业务为单生产者单消费者，可自旋等待而非阻塞，避免线程切换开销。
3. 背压传播：在微服务网格中，channel 背压需与HTTP/2 的 WINDOW_UPDATE 联动，Rust 侧可通过tonic 的Streaming接口将grpc 流控窗口与内部 bounded 容量绑定，实现端到端背压，防止级联雪崩。