如何优化SQS按客户分组的批处理逻辑，降低Lambda额外调用开销

以下方案按改动成本从低到高排序，可根据实际业务需求选择：

方案一：现有标准队列最小改动优化 #

无需调整队列架构，仅通过参数和业务逻辑优化即可达到目标：

• 调整Lambda SQS事件源配置：将BatchSize从50适当上调至最高10000（SQS标准队列支持的最大Lambda批次大小），同时将MaximumBatchingWindowInSeconds拉满到300秒，拉长聚合窗口大幅提升同客户消息被划入同一批次的概率，额外的聚合时长也刚好适配你短时间缓冲重复事件的需求。
• 优化递归调用逻辑：原有递归调用容易触发调用栈限制，可改为将分组后的同客户消息异步调用Lambda处理，同时新增Lambda全局变量//tmp目录本地暂存逻辑，收到零散的小客户消息组后可暂存1-2个批次周期，攒够同客户消息后再触发处理，进一步减少调用次数。
• 新增重复事件缓冲逻辑：搭配DynamoDB（带TTL）做轻量缓冲控制，key为客户ID+消息标识Mx，value存储最后收到消息的时间戳，每次收到消息更新对应时间戳；额外用EventBridge每隔5秒触发一次扫描任务，当某条记录的最后更新时间超过你设定的缓冲窗口（比如10秒）时，再触发对应客户的刷新操作并删除记录，即可实现短时间重复事件只刷新1次、且保证在最后一条消息到达后执行的需求，全程不会丢弃任何消息。

方案二：FIFO队列适配方案（可打消你的所有顾虑） #

你担心的FIFO队列问题全部可以通过配置规避，且能完美实现同客户消息聚合的需求：

• 去重问题可完全关闭：SQS FIFO的去重是可选能力，仅当你主动开启内容去重、或传入MessageDeduplicationId参数时才会生效，只要你不配置这两项，FIFO队列不会做任何去重操作，不会丢失你需要的间隔到达的重复消息。
• 消息组聚合效果符合预期：FIFO队列的MessageGroupId特性本身就保证同一消息组的消息会被尽可能投递到同一个批次，且同一时间只会被一个消费者获取，你只需将客户ID设为MessageGroupId，就能实现同客户消息优先进入同一个Lambda批次的目标，递归调用次数会降到极低水平。
• 吞吐量完全够用：FIFO队列默认吞吐量为3000条/秒，开启高吞吐量模式后可达30000条/秒，你的客户总量不到100，完全不会遇到吞吐量瓶颈，额外的成本支出相对于架构简化来说可以忽略。
• 无顺序要求不影响使用：FIFO的顺序保障是额外能力，你不需要使用也不会产生额外开销，对业务无任何负向影响。

方案三：轻量多队列实现（复杂度远低于预期） #

你担心的动态创建队列的复杂度其实非常低，完全可以落地：

• SQS的create_queue接口是幂等的，你只需在首次收到新客户的消息时调用该接口创建对应队列，将客户ID和队列URL的映射关系存在DynamoDB中，后续发消息前先查映射表即可，全程只需要几行代码就能实现。
• 消费端可以为每个客户队列配置独立的Lambda事件源映射，每个触发的Lambda调用天然只处理单个客户的消息，完全不需要拆分逻辑和递归调用，架构最简洁稳定。你的客户总量不到100，远低于AWS的SQS队列配额限制，不会有资源问题。

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