配置Kinesis流源Lambda并行因子时如何保障事件流串行处理

单shard的Kinesis数据流本身天然支持按写入顺序消费，当你给Lambda事件源配置concurrent batches per shard = 10时，Lambda的事件源映射服务会自动按记录的partition key做哈希分片，把不同partition key对应的记录拆分到最多10个并发执行的Lambda实例中处理，这时候全局事件的处理顺序会被打破，但同一个partition key下的记录依然会严格按写入顺序串行处理。

方案1：固定全量记录的partition key（全局串行） #

• 调整Kinesis写入逻辑，把所有流记录的partition key设置为同一个固定字符串，比如固定为global-order-key。由于所有记录的partition key哈希值完全一致，Lambda做批次拆分时会把全部记录归到同一个处理队列，哪怕配置了10的并发批次上限，实际同一时间只会调度1个Lambda实例按写入顺序拉取批次处理，从根源实现全量事件串行。
• 适用场景：强依赖全局事件顺序、峰值流量不超过单Lambda消费Kinesis的吞吐上限（约1MB/s、1000条记录/s）的场景，不需要修改现有Lambda的事件源配置。
• 注意：该方案下配置的10并发参数不会实际生效，消费吞吐和单消费者模式一致。

方案2：直接调整事件源并发参数（全局串行） #

• 直接修改Lambda的Kinesis事件源映射配置，把concurrent batches per shard参数值调整为1。配置生效后，Lambda不会对单shard内的记录做并发拆分，同一时间只会运行1个Lambda实例按顺序拉取、处理记录，天然保证全局串行，是改造成本最低的方案。
• 适用场景：不需要高并发消费能力、可以调整事件源配置的场景，吞吐表现和方案1一致。

方案3：业务维度串行（保吞吐的细粒度顺序） #

• 如果不需要所有事件全局串行，只需要保证同一业务维度（比如同一用户ID、同一订单ID）的事件按顺序处理，可以保留现有10并发的吞吐能力：
  • 写入Kinesis时直接用业务唯一标识作为partition key，同业务标识的记录天然会被Lambda分配到同一个串行处理队列，不会和其他同key的记录并发执行
  • 为了避免重试、重复投递等极端场景导致的乱序，可以在Lambda处理逻辑中增加基于业务标识的分布式锁，处理对应业务记录前先抢占锁，拿到锁才执行处理逻辑，处理完成后释放锁，锁需要设置合理的超时时间避免死锁。
• 适用场景：仅要求同业务实体事件有序、需要尽可能保留高并发消费能力的场景。

• 不要尝试在Lambda函数内部做内存队列缓冲实现串行：Lambda是无状态运行环境，多个并发实例的内存完全隔离，本地队列无法跨实例协调处理顺序，完全达不到串行效果。
• 所有全局串行方案都会将消费吞吐限制在单消费者水平，需要提前评估峰值写入速率，避免消费速度跟不上导致消息堆积、iterator age超出阈值。

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