Streaming（流式传输）和 Backpressure（反压）是处理"数据持续流动"时绕不开的两个概念。一个讲怎么把大数据切块送, 一个讲接收方处理慢于发送方时怎么办。下面用水管类比 + 实时模拟 + 代码 diff + 按严重程度色码的陷阱清单四件套讲清楚。
为什么它们总是一起出现?
Streaming = 数据分块送, 不一次性塞完。 一个 10 GB 的文件不会等加载完才开始处理, 而是边读边处理边写。LLM 不会等整段回复生成完才发, 而是逐 token 流式吐字。视频不会等全片下载完才播, 而是边下边播。
Backpressure = 接收方处理慢于发送方时, 反向施压让发送方"慢点"。 这是流式传输的"必备配套"——一旦数据持续流动, 处理速度永远不会完美匹配, 慢的一方必须有办法告诉快的一方 stop / slow / resume。
没有反压的流式传输是炸弹——快的一方持续灌, 慢的一方处理不过来, 中间缓冲区无限膨胀, 直到内存爆炸 / 进程崩溃 / 数据被迫丢弃。
三种情况, 一眼看懂为什么需要反压
水龙头 ─────▶ 水管 ─────▶ 漏斗 ─────▶ 桶
2 L/s 缓冲区 2 L/s
几乎空
进出速度相同, 漏斗维持低水位, 系统稳态。
水龙头 ──▶ 水管 ─────▶ 漏斗 ─────▶ 桶
5 L/s 缓冲爆膨胀 1 L/s
⚠️⚠️⚠️ OOM
漏斗每秒进 5 L 出 1 L, 净流入 4 L/s。
有限的内存几秒钟就被填满 → 进程崩溃 / 数据丢失。
水龙头 ──▶ 水管 ─────▶ 漏斗 ─────▶ 桶 ↑5L/s 高水位 1 L/s 暂停──────"我满了, 停一下" 漏斗水位达到阈值 → 反向通知水龙头关闭。 水位降下来 → 通知水龙头重开。 系统稳态, 实际吞吐被慢的一方限速。
点按钮切换三种策略, 观察缓冲区水位变化
Node.js Streams 经典示例 · 上面是反例, 下面是正解
// 一边读一边推, 不等接收方 readable.on('data', (chunk) => { writable.write(chunk); // 不看返回值 // write() 返回 false 表示 // 内部缓冲已满, 但代码无视 }); // readable 读多快, 就推多快 // writable 内部 buffer 无限增长 // 最终: heap out of memory
// 检查 write 返回值, 满了就暂停 readable.on('data', (chunk) => { const ok = writable.write(chunk); if (!ok) readable.pause(); }); writable.on('drain', () => { readable.resume(); // 缓冲排空再继续 }); // 或者一行: readable.pipe(writable) // pipe 内部自动做反压
关键差异在三个动作:
① write() 返回值不能吞——返回 false 就是接收方在喊"我满了"。
② 收到 false 立刻 readable.pause() 停止读取上游。
③ 监听 drain 事件——内部缓冲降到 lowWaterMark 以下时触发, 这时才 resume()。
实践中 能用 pipe() 就用 pipe()——它把上面三步全部封装了, 一行代码自带反压。手动监听 data 事件几乎总是错误的开始。
从致命到无害 · 按色排序自上而下
stream.pipeline(), Web Streams 用 readable.pipeTo(writable), 都是端到端反压 + 错误传播 + 资源清理一起做好。readable.pipe(writable) · pipeline(a, b, c) · readable.pipeTo(writable)write() 返回 false → pause() 上游 → drain 触发 → resume()。每一项都是工业上验证过的反压实现
highWaterMark + write() 返回值 + drain 事件; pipe() / pipeline() 自动处理ReadableStream.pipeTo(WritableStream) 自带反压; 自定义 controller 时用 controller.desiredSize 判断onReadyHandler 协调throttleTime / sample / bufferTime 做"采样/丢弃"近似bufferedAmount 检查客户端待发送队列, 超阈值则跳过推送实操遇到流式场景时回想这几条
① 凡是"持续流动的数据", 必须问反压怎么实现。 没问就是把炸弹放进系统。
② 能用平台原生的 pipe / pipeTo / pipeline 就用, 别手写 data 事件。 自己接的反压链 99% 会出 bug, 标准 API 已经把所有边角踩过了。
③ 反压的目标是"匹配速率", 不是"无脑加大缓冲"。 缓冲只能吸收瞬时抖动 (秒级), 处理不了系统性慢——发送方比接收方持续慢 10%, 任何缓冲早晚都会满。