高并发场景下Lambda函数未被DynamoDB稳定触发问题排查求助

我之前碰到过几乎一模一样的情况！当时也是高并发下部分记录明明在DynamoDB流里，但就是没触发Lambda，查了常规指标都没问题，最后从几个容易忽略的点找到了根源，给你列几个排查方向：

1. 检查Lambda事件源映射的批量配置 #

DynamoDB流和Lambda的事件源映射里，两个关键配置很容易影响高并发场景的触发逻辑：

• BatchSize：每个Lambda调用接收的最大流记录数（默认100）。如果设置过大，高并发下单个Lambda实例处理时间过长，可能导致后续记录堆积；如果Lambda超时时间小于大批次处理时间，还会引发处理失败，重试耗尽后部分记录可能被遗漏。
• MaximumBatchingWindowInSeconds：默认0（DynamoDB尽快发送批次）。如果设置为0，高并发下可能产生大量小批次，若Lambda并发配额被占满，新批次无法触发；若窗口设置过大，低频次记录可能被合并延迟，但你是10%记录直接没触发，更要关注配额匹配问题。

可以用命令查看具体配置：

aws lambda get-event-source-mappings --function-name <你的Lambda函数名>

2. 排查Lambda的并发限制与分片处理能力 #

DynamoDB流的每个分片同一时间只能被一个Lambda实例处理，如果你的流分片数量较多，但Lambda的预留并发未配置，或者突发并发配额（默认1000）被其他函数占用，就会导致部分分片的记录无法及时分配到Lambda实例，看起来像是没触发。

虽然你说没看到限流指标，但可以检查Lambda的ConcurrentExecutions指标是否接近配额上限，或者确认Throttles指标有没有延迟显示的情况。另外，预留并发数最好能覆盖你的流分片数，避免分片等待可用实例。

3. 检查事件源映射的过滤规则 #

这个非常容易被忽略！如果你在事件源映射里配置了事件过滤（比如只触发INSERT操作，或过滤特定属性的记录），可能因为规则逻辑错误，导致部分符合预期的记录被过滤掉。比如：

• 只配置了{"eventName": ["INSERT"]}但场景里包含UPDATE操作
• 过滤规则的属性类型不匹配（比如用$.newImage.status.S匹配数字类型的status.N）

可以通过命令查看过滤规则：

aws lambda get-event-source-mappings --function-name <你的Lambda函数名>

也可以临时移除过滤规则测试，看是否所有记录都能触发Lambda。

4. 验证Lambda的检查点与分片迭代器 #

Lambda处理DynamoDB流时会自动记录检查点（处理到的流记录位置），如果Lambda发生静默失败（比如代码吞了异常，返回成功但实际未处理完），检查点会被更新，导致该批次部分记录被遗漏。另外，如果Lambda长时间未处理某个分片，迭代器（默认15分钟过期）会失效，虽然Lambda会自动刷新，但如果流记录已超过24小时保留期，就会丢失。

可以查看事件源映射的LastProcessingResult字段，确认有没有迭代器相关的错误提示。

5. 检查Lambda函数的日志完整性 #

有时候我们误以为Lambda没触发，其实是Lambda收到了事件但日志没记录。比如你的Lambda代码开头没有记录所有入站事件，或者日志级别设置过高（只记录ERROR），导致成功处理的事件无日志留存。

可以在Lambda代码最开头添加日志：

console.log('Received event:', JSON.stringify(event));

测试后查看CloudWatch日志，确认流里的记录是否都有对应的日志条目——如果有，问题出在处理逻辑而非触发环节；如果没有，才是真的未触发。

6. 检查DynamoDB流的分片分配 #

如果你的表存在热点分区，会导致对应分片的记录量极大，Lambda实例处理不过来，造成记录堆积，看起来像是没触发。可以用命令查看分片状态：

aws dynamodbstreams describe-stream --stream-arn <你的流ARN>

重点看分片的SequenceNumberRange，如果EndingSequenceNumber和StartingSequenceNumber差距极大，说明该分片有大量记录堆积。

内容的提问来源于stack exchange，提问作者tinjuiho