如何过滤AWS SNS重复消息？实现去重后如何测试对应逻辑？

你提到的基于DynamoDB实现消息去重的方案是合理的，但实际落地时需要注意优化实现逻辑，避免出现竞态条件漏洞：

• 不要采用「先查询messageId是否存在、不存在再写入」的两步操作，高并发场景下同时到来的重复消息可能都读到不存在的结果，最终重复执行业务逻辑。建议直接使用DynamoDB的PutItem接口搭配条件表达式，仅当messageId不存在时才写入记录，捕获ConditionalCheckFailedException异常即可判定为重复消息，直接忽略即可，该方式无需额外做强一致读查询，性能和可靠性都更高。
• 需将DynamoDB表的分区键设为messageId，同时配置TTL自动清理过期的消息ID记录，避免表容量无限膨胀。TTL时长建议设置为大于SQS队列的最大消息保留时长即可，比如SQS默认最长保留14天，可设置15天的TTL。
• 注意提取SQS消息体中SNS原始的MessageId作为去重键，不要误用SQS队列自身生成的消息ID，否则SQS重投消息时ID会发生变化，导致去重逻辑失效。

• FIFO队列原生去重：如果业务允许调整队列类型，可直接改用SNS FIFO队列+SQS FIFO队列的组合，开启队列自带的消息去重功能，AWS侧会自动丢弃指定时间窗口内的重复消息，无需自行实现去重逻辑，运维成本更低。
• 业务逻辑幂等改造：无需单独维护去重存储，直接在业务处理逻辑中实现幂等，比如对业务数据加唯一键约束、处理前先校验对应业务记录的处理状态，从业务层面避免重复执行的副作用，适用大多数不需要严格强一致去重的场景。
• 缓存去重：如果消息吞吐量极高，DynamoDB成本或性能无法满足要求，可使用Redis的SETNX命令存储消息ID，同时给Key设置过期时间，性能比DynamoDB更高，缺点是需要自行保障缓存的可用性，缓存故障时可能出现去重失效。

• 单元测试：构造两条携带相同SNS MessageId的消息输入，调用Lambda handler函数，验证仅第一次调用会执行业务处理分支，后续调用直接返回，无重复业务操作。
• 集成测试：手动向SQS队列投递两条携带相同SNS MessageId的消息，观察Lambda执行日志和下游业务系统数据，确认仅一条消息被正常处理，另一条被识别为重复忽略，无重复数据生成。
• 并发压测：同时向SQS队列投递数十至上百条相同MessageId的消息，验证高并发场景下仍不会出现重复处理的情况，确认竞态条件防护逻辑有效。
• 异常场景测试：模拟Lambda处理过程中意外中断、消息被SQS重投的场景，验证若此前业务已经处理完成，重投的消息会被识别为重复；若此前处理失败，重投的消息会被正常执行。

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