AWS Lambda对接MSK事件源并发异常与触发延迟问题咨询

1. 并发理解正确性判断 #

你的基础认知符合Lambda对接Kafka类事件源的官方逻辑：MSK事件源默认采用1个分区对应1个Lambda消费者实例的调度规则，47个分区的场景下预留并发设置为47是匹配理论最大并发的合理配置，核心逻辑没有理解错误。

实际并发远低于预期，属于配置遗漏或调度规则限制导致的问题，和基础认知无关。

2. 需排查的遗漏配置项 #

你遇到的并发不足、触发延迟1分钟的问题，优先从以下配置项排查：

• 事件源映射的批次等待配置
  MSK事件源默认支持MaximumBatchingWindowInSeconds（最长批次等待时间）和BatchSize（单批次最大消息数）两个参数，Lambda会等攒够BatchSize条消息或者等待时间到达MaximumBatchingWindowInSeconds阈值才会触发一次函数调用。

  你提供的日志中Kafka消息生产时间和Lambda触发时间刚好相差60秒，和该参数的常用默认值完全吻合，1分钟延迟问题大概率是该配置导致的。如果配置了较高的批次等待时间，Lambda不需要频繁拉起新实例，也会直接导致并发数上不去。

• Lambda执行角色权限缺失
  确保Lambda执行角色已配置kafka:DescribeGroup、kafka:ListGroups、kafka:GetBootstrapBrokers等MSK访问权限，权限不足时Lambda消费者组的分区分配会出现异常，多个分区会被分配给同一个消费者实例，直接导致并发数远低于分区数。
• 函数执行时长影响调度
  如果你的Lambda函数单次执行时长极短（<100ms），Lambda服务侧的调度逻辑会复用现有实例处理多个分区的消费请求，不会无脑拉起满额47个实例，属于正常的成本优化逻辑。如果需要强制拉满并发，可以调小BatchSize为1、关闭MaximumBatchingWindowInSeconds（设为0），但会大幅提升调用成本。
• 调度扩容逻辑限制
  Lambda对接MSK的消费者组实例是逐步扩容的，不会一上来就直接拉满等于分区数的实例，持续高负载运行3-5分钟后，并发数才会逐步上涨到接近分区数的水平，短时间低负载场景下并发数低属于正常现象。

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