Node.js 服务性能优化有哪些方向？
简化版
Node 性能优化要从事件循环阻塞、数据库访问、缓存、序列化、日志、网络、进程模型和监控入手。核心是避免主线程 CPU 长任务，减少 I/O 次数，使用缓存和连接池，并用指标定位瓶颈。
详细版
常见方向：
- 避免同步阻塞 API，如大文件
readFileSync。 - CPU 密集任务放 worker_threads 或任务队列。
- 数据库查询优化、索引、连接池。
- 热点数据缓存到 Redis 或内存。
- 响应压缩、HTTP keep-alive。
- 日志异步化和采样。
- 多进程/多实例扩展。
- 监控 event loop lag、QPS、P95/P99、内存、GC。
性能优化先测量，再动手。
完整版教学
一、先看事件循环是否被阻塞
Node 的高并发依赖事件循环。如果主线程做大 JSON 解析、复杂加密、图片处理，所有请求都会排队等待。
可以监控 event loop lag。如果 lag 明显升高，说明 JS 主线程被长任务占用。
二、I/O 优化更常见
很多接口慢不是 Node 慢，而是数据库慢、下游服务慢、网络慢。优化 SQL、加索引、减少 N+1 查询、批量请求、缓存热点数据，往往收益更大。
Node 层要合理设置连接池，避免每次请求新建连接。
三、缓存要考虑一致性
缓存能提速，但也会带来过期、击穿、雪崩、脏数据问题。接口缓存、Redis 缓存、本地内存缓存都有不同边界。
本地内存缓存速度快，但多进程不共享，重启丢失；Redis 共享性好，但有网络开销。
四、面试追问与工程落地
常见追问是“如何定位慢接口”。可以从网关耗时、Node handler 耗时、数据库耗时、下游 RPC 耗时拆分，打点到日志或 tracing。只看总耗时不知道瓶颈在哪。
工程里关注尾延迟比平均值更重要。P99 高说明少数请求很慢，用户体感可能很差。GC、锁等待、慢 SQL、偶发下游超时都可能拉高 P99。
五、建立指标与排队模型
性能优化先定义目标：吞吐量回答“单位时间处理多少请求”，延迟回答“一个请求等多久”，P95/P99 则暴露少数慢请求。Node 侧至少应同时观察 CPU、RSS、堆内存与 GC、事件循环利用率（ELU）、事件循环延迟，再用 tracing 拆分数据库和下游耗时。
Little 定律可以帮助判断容量：平均并发数 ≈ 吞吐量 × 平均响应时间。例如服务稳定承受 1000 QPS，平均响应时间是 0.2 秒，则系统内平均约有 1000 × 0.2 = 200 个在途请求；如果连接池只有 50 个槽位，请求很可能在数据库前排队。
| 现象 | 优先验证的证据 | 可能动作 |
|---|---|---|
| ELU、事件循环延迟和 CPU 同时高 | CPU profile、长任务 | 降低计算量或移入 worker |
| Node CPU 不高但接口慢 | trace、慢 SQL、下游延迟 | 索引、批量请求、超时与隔离 |
| RSS 持续涨、堆回落正常 | Buffer、原生内存、连接数 | 检查堆外内存与资源释放 |
| 堆占用锯齿上移 | heap snapshot、GC 指标 | 查找持续被引用的对象 |
平均值不能替代分位数，也不能只看压测 QPS。若平均 100ms、P99 2s，1% 的请求仍会明显影响用户，而且重试可能继续放大队列。
六、用证据定位 CPU、内存和 I/O
CPU 问题用 CPU profile 或火焰图找热点函数，内存问题用 heap snapshot、分配采样和 RSS/heap 对照，I/O 问题用 trace 和依赖侧指标定位。monitorEventLoopDelay() 的直方图值以纳秒表示，展示为毫秒时要除以 1e6；ELU 高说明循环忙，但要结合 profile 才能判断忙在业务计算还是大量短回调。
如果主线程每秒发生 20 次、每次 50ms 的同步计算，理论上 20 × 50ms = 1000ms，一整秒都没有余量处理其他回调。把它搬到 worker 并不保证更快，还要计算消息序列化、排队和线程池成本；小任务往往先优化算法更有效。
压测必须接近生产的请求分布、数据量、缓存命中率和依赖延迟，并记录改动前后的同一组基线。Heap snapshot 可能暂停主线程并显著增加内存，生产采集要评估影响，不能为诊断制造新的故障。
“加缓存、加进程、上 worker”只是候选方案；没有瓶颈证据和前后对比，就不能证明它是性能优化。
一次完整优化实验
可复现的优化过程通常包含：
- 定义容量、P95/P99、错误率和资源成本目标。
- 固定运行时版本、实例规格、数据集和依赖环境。
- 预热 JIT、连接池和缓存，再采集稳定基线。
- 用 profile、trace、慢查询和事件循环指标定位主瓶颈。
- 一次只改一个主要变量，保留可回滚方案。
- 用相同负载重复测试，比较置信区间而非单次峰值。
- 检查数据库、Redis 或下游是否因优化而被压垮。
- 小流量上线并观察真实分布，确认没有回归再扩大。
例如把接口从 500 QPS 提到 800 QPS，却令数据库 CPU 从 60% 升到 100%、错误率上升，这不是系统容量提升，只是把排队点向后移动。性能结论必须覆盖整个请求链路和资源成本。
对比结果还应保存测试脚本、数据版本和关键配置，保证团队能够复验，而不是只留一张无法追溯的峰值截图。
七、常见误区与追问
- 误区：平均响应时间下降就代表所有用户都变快。 平均值会掩盖尾延迟，应同时比较 P50、P95、P99 和错误率。
- 误区：CPU 高一定说明事件循环被某个长任务阻塞。 大量短回调也会拉高 CPU，必须结合事件循环延迟和 CPU profile 判断。
- 误区：把逻辑放进 worker_threads 一定能提速。 worker 适合足够重的 CPU 任务，小任务可能被通信、序列化和调度成本抵消。
- 追问：事件循环延迟和 ELU 有什么区别？ 延迟衡量回调被推迟多久，ELU 衡量循环处于活跃状态的比例，两者结合才能区分“忙”和“卡”。
- 追问：为什么缓存不是越多越好？ 缓存消耗内存并引入一致性、失效和击穿问题，只有命中率与节省成本覆盖这些代价时才值得。
- 追问：同步 API 是否完全不能使用？ 启动阶段的短小一次性操作通常可接受，请求热路径上的同步 I/O 会阻塞所有并发请求。
- 追问：如何证明一次优化有效？ 固定负载和环境，对比吞吐、分位延迟、错误率与资源消耗，并确认瓶颈没有只是转移到下游。
八、加强记忆
Node 优化先问“是主线程卡，还是 I/O 在排队”，再用 ELU、事件循环延迟、profile 和 trace 给出证据。CPU 长任务减少或移出去，I/O 次数与排队降下来，热点数据按一致性边界缓存。最后用相同基线比较吞吐、P95/P99、错误率和资源成本，验证收益而不是凭感觉宣布完成。