Debugs AWS Lambda function tim…

# Node.js 18 Lambda 订单处理超时排查指南

一、先定位：是不是 DynamoDB 慢？

用 CloudWatch 相关指标对比：

• Lambda 指标：查看 Duration 的 p99/p95 值，与15秒超时线对比；关注 ConcurrentExecutions（9点是否并发打满）
• DynamoDB 指标：ThrottledRequests、ReadThrottleEvents（是否被限流）、SuccessfulRequestLatency（p99是否明显升高）
• 如果 Lambda 超时但 DynamoDB 延迟平稳，问题大概率不在 DynamoDB

加分布式追踪：

• 启用 AWS X-Ray（Lambda 控制台一键开启），在代码中引入 aws-xray-sdk 包裹 AWS SDK 客户端
• 看_TRACE_时间轴：DynamoDB 查询段占总耗时比例，一眼定位瓶颈

二、DynamoDB 常见慢查询原因

• 热分区：9点高峰时订单表分区键（如日期、状态）集中，单一分区被限流。排查 ReadThrottleEvents 是否集中在某分区
• Scan 操作：代码里若用了 Scan 或 FilterExpression（过滤不减少读取量），高峰数据量增大后耗时线性上升
• 缺少索引：查询条件无对应 GSI，导致全表扫描式 Query
• 大 Item / 大分页：单条查询返回超过数百 KB，或 Limit 设置不当导致反复分页

三、Lambda 自身常见问题（易被误判为 DB 慢）

• 冷启动叠加：Node.js 18 + 大依赖包，冷启动可达数秒，9点流量突增时大量冷启动
• 初始化放在请求路径里：SDK 客户端、数据库连接若在 handler 内每次新建，增加延迟。应移到 handler 外复用
• 内存配置过低：CPU 与内存成正比，内存低则 JSON 序列化、加密都慢。可尝试提高内存验证耗时变化
• VPC 内 Lambda 访问 DynamoDB：未配置 VPC Endpoint 会走公网 NAT，延迟和故障率都更高

四、快速验证步骤（建议顺序）

1. 开启 X-Ray，抓一早上高峰期 TRACE

2. 对照 DynamoDB ThrottledRequests 与 Lambda p99 Duration 时间线

3. 在代码中对 DynamoDB 查询打点（console.time 或 EMF 指标），输出每条查询耗时

4. 若确认 DB 慢：优化分区键、加 GSI、改用 Query、必要时开 DAX 缓存或调整表容量/按需模式

5. 若 DB 正常：提高内存、handler 外初始化、预留并发（Provisioned Concurrency）消除冷启动

结论：先靠 X-Ray 和打点数据说话，不要凭猜测直接换数据库方案。多数案例是冷启动+热分区两者叠加。