AWS Lambda为自管Kafka增加队列模式：多个轮询器可读同一分区但不保序，Amazon MSK暂不支持

2026年11月2日，AWS宣布AWS Lambda现在在自管Kafka事件源映射中支持Apache Kafka队列。此前，Kafka事件源映射使用Kafka消费者组协议，把每个分区恰好分配给组内的一个消费者。想要更高并行度的团队，只能对主题过度分区，或者把流量转到单独的队列系统，这意味着要多运营一套基础设施，还要多维护生产者代码。新的队列模式建立在Kafka共享组（share group）之上，允许多个事件轮询器同时读取同一个分区。

AWS称，每个事件轮询器支持最多10个并发调用，并行度不再与分区数绑定，生产者、主题配置和函数代码都不用改。一个缓慢或失败的事件，也不会再拖住同一分区里的其他事件。公告也直白地说出了代价：队列模式不保留分区顺序，适合不需要顺序的工作负载。它举的例子是每个事件都是独立工作单元、速度比顺序更重要的场景，比如图像和视频编码、欺诈检测、通知发送和遥测数据摄取。

使用条件比标题给人的印象要窄。公告说，集群必须启用共享组，例如Apache Kafka 4.2或更高版本，并且功能在提供自管Kafka事件源映射的所有AWS商业区域可用。公告称，它覆盖客户自己运行的集群，以及Confluent Cloud这类托管产品。Lambda开发者指南则说得更进一步：共享组在Apache Kafka 4.0中就已出现，但Kafka队列轮询器要求4.2或更高版本，而且队列模式仅适用于自管集群。按指南原话，Amazon MSK目前不支持队列模式，等MSK提供启用共享组的Kafka 4.2或更高版本后，AWS才会加入MSK支持。因此，运行Amazon MSK的团队不应把这条公告理解为涵盖了自己的集群。

使用时，要创建自管Kafka事件源映射，把ConsumptionMode设为Queue，可通过控制台、Lambda API、AWS CLI、CloudFormation、SAM或CDK完成。如果不指定模式，映射使用默认的Stream模式。指南对两者做了比较：Stream保持分区内顺序，每个轮询器最多5个并发调用；Queue不保证顺序，最多10个。两者的对比表都列出每个轮询器最高5 MB/s的吞吐，但队列模式的按需部分写的是每个轮询器最高1 MB/s，最多5个轮询器，合计5 MB/s和50个并发调用。预置模式可以设定最小和最大轮询器数量，最小为1到200，最大为1到2000，指南在这里列出每个轮询器最高5 MB/s。由于不同页面对不同模式给出了不同限制，应该阅读自己实际要运行的那个模式。

几个熟悉的设置会改变。队列模式不支持MaximumBatchingWindowInSeconds，指定它会返回验证错误，因为Kafka共享消费者要求对批次中的每条记录显式确认。StartingPosition和StartingPositionTimestamp同样不支持，因为队列模式总是从共享组已提交的位置开始读取。MaximumRetryAttempts默认值为0，没有配置失败目标时由代理执行重试。事件过滤最多5个模式、模式注册表、失败目标和事件源映射日志都受支持。队列映射只与其他队列映射共享事件轮询器单元。通用的Kafka指南还提醒，映射至少处理每个事件一次，所以函数代码应当是幂等的。

关于费用，公告说适用标准的Lambda定价，配置了预置模式的客户还要为事件轮询器单元的使用付费。比较稳妥的试用方式是先选一个不关键的主题：确认集群版本并已启用共享组，在测试账户中创建一个队列映射，发送一波突发流量，测量吞吐、重复处理和失败记录的处理情况。要先决定有没有消费者需要顺序，因为队列模式会取消它。文章没有给出吞吐提升的基准数据，所以任何加速的说法都必须来自你自己的测试。

需要强调的是，这条公告本身并没有给出吞吐提升的基准数据，也没有说明在真实负载下的重复处理比例。对于以至少一次语义工作的事件源映射，队列模式让多个轮询器共享分区，重复交付与乱序处理的影响会更明显，所以幂等设计、死信或失败目标的配置，以及对失败记录的监控，都应该在放量之前先准备好。

从架构角度看，这项功能把原来要靠分区数来换并行度的做法，换成了按消息领取的做法，更接近队列服务的使用习惯。但它不是消费者组的直接替代：依赖同一订单、同一账户内事件先后顺序的流水线，应该继续用Stream模式。比较好的分法是按主题来选，把需要顺序的主题留在Stream，把彼此独立的任务型主题放进Queue，并为每个映射记录选择的理由。