如何实现Amazon MQ（ActiveMQ）触发Lambda的消息接收确认

Amazon MQ（ActiveMQ）作为Lambda事件源时，无需在Lambda代码中手动发送确认，AWS会通过事件源映射自动根据Lambda的执行结果完成和ActiveMQ的确认交互。

1. ActiveMQ原生的消息移除逻辑
   ActiveMQ的消息不会因为被消费者拉取就自动删除，必须等消费者返回明确的确认（ACK）指令才会移除。常见的确认模式分为三类：

• 自动确认：消费者拉取消息后自动发送ACK，不管业务是否处理成功，容易丢消息
• 客户端确认：消费者必须手动调用确认API，才会触发消息移除
• 事务确认：消息消费和确认在同一个事务中，要么全部成功要么全部回滚

2. Amazon MQ为Lambda封装的消费者逻辑
   AWS的事件源映射会自动维护和ActiveMQ的长连接、消费者会话，默认使用客户端确认模式，把Lambda的执行结果和ACK指令绑定：

• 当Lambda正常返回（无未捕获异常、无执行超时）：自动向ActiveMQ发送ACK，消息被从队列/主题中移除
• 当Lambda执行失败（抛出异常、超时、被强制终止）：自动不发送ACK，消息会被保留在队列中，按照配置的重试策略重新投递

• 批处理大小设置：如果事件源映射的批处理大小大于1，Lambda正常返回会一次性确认整批的所有消息，只要批中有任意一条处理失败，整批都会被重投。如果需要单条消息精准控制确认，建议将批处理大小设置为1。
• 重试策略配置：在事件源映射中可以配置最大重试次数，超过重试次数后，消息会被按照ActiveMQ的规则转入死信队列，不会无限重投。
• 避免异步处理逻辑：如果Lambda内部使用异步线程处理消息，主线程会直接返回触发ACK，此时异步任务可能尚未执行完成，会导致消息被提前移除、业务处理丢失。

如果你的Lambda没有使用Amazon MQ的原生触发器，而是自行内嵌了ActiveMQ客户端连接服务，此时需要手动实现确认逻辑：

• 处理逻辑执行完成后，调用对应客户端的消息确认API：Java客户端可直接调用message.acknowledge()，其他语言客户端需调用对应会话的确认方法
• 如果开启了事务模式，处理完成后需要调用session.commit()提交事务，未提交的事务会导致消息不会被确认，触发重复投递

注意：该场景下Lambda的执行结果和MQ确认完全脱钩，需要自行保障消息处理和确认的原子性，避免出现消息丢失、重复消费的问题。

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