MassTransit搭配AWS SQS时app1重复消费同一条消息的原因排查

问题根因分析 #

1. SQS消息可见性超时导致的自动重投 #

这是最核心的原因：

• AWS SQS的消息被消费者拉取后，会进入可见性超时周期（MassTransit对接SQS的默认值为30秒，你的代码中没有显式配置修改该值），如果在周期内消费者没有返回消费成功的确认，SQS会判定消费失败，自动将消息重新放回队列进行重投，SQS默认最大重投次数可达数千次，和你遇到的最高478次重复消费的特征完全匹配。
• 超时场景下MassTransit的异常捕获逻辑不会触发，因此Sentry没有相关异常上报，和你观测到的现象完全一致。

2. app1的消费逻辑写法大幅提升了超时概率 #

对比app2的代码，app1的消费逻辑存在明显缺陷：

• app1的Consume方法用await Task.Run()包裹了全同步的数据库操作：coinService.TlToCoin、accountService.FindByEmail、coinService.AddBonus都是同步方法，线程会被阻塞直到操作完成，高并发场景下极易出现线程池排队、操作总耗时超过30秒的情况。
• app2的消费逻辑是原生异步实现：await _scoreService.AddActivity是异步IO操作，不会阻塞线程，执行效率更高，超时概率极低，因此没有出现重复消费问题。

3. 其他辅助诱因 #

• app1的长轮询等待时间WaitTimeSeconds配置为10秒，比app2的20秒更短，队列有消息时拉取频率更高，重投后的消息会被更快拉取，加剧了重复消费的频次。
• app1的重试间隔配置为1秒，若出现极短时间的网络抖动，会更快触发本地重试，进一步放大超时风险。

修复方案 #

• 显式配置SQS接收端的可见性超时时间：在ReceiveEndpoint配置块中添加q.VisibilityTimeout = TimeSpan.FromMinutes(5);，设置为远大于你的消费逻辑最大耗时的值。
• 重构app1的消费逻辑：去掉Task.Run包裹，将所有数据库操作改为异步实现（FindByEmailAsync、AddBonusAsync），直接await异步方法，避免线程阻塞。
• 配置SQS死信队列：超过指定重投次数的消息自动转入死信队列，避免无限重投。
• 为消费逻辑添加耗时埋点日志，排查慢查询的具体原因，优化数据库操作性能。

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