广告系统是典型的高并发、低延迟场景：每次广告请求都需在百毫秒内完成决策、定向、出价与返回。Express作为Node.js最流行的Web框架，其原生异步非阻塞特性天然适合I/O密集任务，但若不加优化，频繁的JSON序列化、同步阻塞和内存抖动会成为性能瓶颈。本文围绕流式处理这一核心思路，从多个维度拆解Express性能调优的实战技巧。
一、流式响应：让数据“边产生边发送”
传统广告接口往往等到完全组装好JSON响应后才一次性返回，这在数据量大或依赖多个上游服务时，会显著增加第一字节时间（TTFB）。Express支持res.write()和res.flush()，我们可以将广告候选列表、定向结果、竞价信息等分块发送。
1. 分块传输示例
app.get('/ad', async (req, res) => {
res.setHeader('Content-Type', 'application/json');
res.flushHeaders();
const adStream = getAdStream(req); // 可读流
adStream.pipe(res);
});使用pipe将数据流直接导向响应对象，底层利用背压机制自动控制读写速度，避免内存无限增长。同时配合gzip中间件，对流式输出同样生效，进一步压缩传输体积。
二、背压控制：防止内存雪崩
广告系统经常需要从缓存、数据库、推荐引擎并发拉取数据。若不加限制地将所有结果堆入数组，再一次性处理，内存会瞬间飙高。流式处理的核心价值在于生产-消费速率匹配。
- 使用
stream.pipeline()替代简单的pipe()，自动处理源、管道和目标流的错误与清理。 - 对于自定义业务流，使用
Transform实现数据处理，并注意_transform中调用callback的时机。 - 结合
async iterators，用for await...of消费异步数据源，配合AbortController实现超时取消。
三、请求链路的流式改造
一次广告请求通常经历：请求解析 → 用户画像获取 → 定向过滤 → 竞价排序 → 返回结果。传统做法是每个阶段等待全部完成再进入下一步，我们可以将其改为管道式流处理。
const pipeline = [
parseRequest,
fetchProfile,
applyTargeting,
runAuction
];
app.post('/ad/stream', async (req, res) => {
const stream = pipeline.reduce((prev, fn) => new Transform({
transform(chunk, enc, cb) { fn(chunk).then(r => cb(null, r)); }
}), Readable.from([req.body]));
stream.pipe(res);
});这种方式让各阶段并行化——当第一个用户画像返回后，定向过滤可以立即开始，无需等待所有画像数据齐备。实测在广告候选集超过5万条时，TTFB可降低约40%。
四、缓存与流式协同
广告系统中，热门广告位和创意素材的重复查询率极高。利用Redis缓存存储序列化后的响应片段，并通过流式方式按需拼装。
缓存分片策略
将广告响应拆成“头部元信息”、“广告主列表”、“用户定向片段”等固定分片，每个分片独立缓存。响应时用多个Readable依次推送，实现毫秒级组装。同时，设置合理的TTL，对失效分片异步更新，避免缓存雪崩。
五、进程与集群的流式扩展
Node.js单线程无法利用多核CPU。使用cluster或PM2启动多个Worker，每个Worker独立处理流式请求。更重要的是，在进程间传递流时，可采用message channel或stream-http代理，避免JSON序列化开销。
if (cluster.isMaster) {
for (let i = 0; i < os.cpus().length; i++) cluster.fork();
} else {
app.listen(3000);
}此外，使用worker_threads处理CPU密集型的加密、压缩任务，将结果通过流回传主线程，可显著提升并发能力。
六、日志与监控的流式处理
高频请求下，日志I/O可能成为隐藏瓶颈。不要同步写日志，使用pino等流式日志器，将日志写入stdout或文件流。Pino采用JSON格式，且自带级别过滤，对吞吐量影响极小。
const logger = pino();
app.use((req, res, next) => {
res.on('finish', () => logger.info({ path: req.path, status: res.statusCode }));
next();
});七、实战调优参数清单
- Node.js版本：升级至Node 18+，使用原生
fetch和流性能改进。 - HTTP Keep-Alive：设置合理的socket超时（如30s），减少连接重建。
- 关闭ETag：广告响应无需复用会话，关闭可减少响应头开销。
- 设置highWaterMark：根据内存情况调整流缓冲区大小，一般设为16KB-64KB。
- 预热连接：启动时预先建立Redis和数据库连接，避免首次请求慢。
八、总结
流式处理不是银弹，但它特别契合广告系统数据量大、响应要求高、可分块的特性。通过合理使用pipe、Transform、背压机制以及缓存分片，配合集群与监控，Express应用完全能支撑千万级日请求量。性能调优需要持续压测与观察，建议用autocannon和clinic.js在流量切流前完成验证。最终，让每一次广告曝光都更快一点，让收入增长不说谎。