AWS SQS 消息失败重试：仅自定义异常触发

在 Spring Cloud AWS 中，通过 `@SqsListener` 配合 `ON_SUCCESS` 删除策略时，需手动捕获非目标异常，仅让特定自定义异常（如 `MyCustomException`）向上抛出以触发消息重试，其余异常应静默吞并或记录，避免意外丢消息。

当使用 SqsMessageDeletionPolicy.ON_SUCCESS 时，SQS 消息仅在方法正常返回（无异常）时自动删除；一旦方法抛出任何未捕获的异常，Spring 将默认执行失败处理逻辑（如将消息放回队列或进入死信队列，取决于 SQS 的 RedrivePolicy 和 VisibilityTimeout 设置）。但问题核心在于：我们不希望所有异常都触发重试——例如 NullPointerException 或 IllegalArgumentException 往往代表代码缺陷或数据脏污，应被拦截并记录，而非盲目重试，否则可能造成重复处理、状态不一致甚至死循环。

✅ 正确做法是：用 try-catch 显式包裹业务逻辑，仅重新抛出白名单内的自定义异常（如 MyCustomException），其他异常则统一捕获、记录日志，并不抛出，从而让方法“静默成功”退出，使 SQS 按 ON_SUCCESS 策略删除该消息（即视为已处理完毕，不再重试）。

以下是推荐实现：

@SqsListener(
    value = "https://sqs.us-east-1.amazonaws.com/123456789012/MyQueueURL",
    deletionPolicy = SqsMessageDeletionPolicy.ON_SUCCESS
)
public void getMessageFromSqs(MyMessage message) {
    try {
        log.info("Processing message: {}", message);

        if (someCondition()) {
            throw new MyCustomException("Business rule violated — retry required");
        }

        // ✅ 业务逻辑成功完成
        log.info("Message processed successfully");

    } catch (MyCustomException e) {
        log.warn("Custom exception encountered, allowing retry", e);
        throw e; // ? 关键：仅此异常透出，触发 SQS 重试
    } catch (Exception e) {
        // ⚠️ 兜底捕获：所有其他异常（NPE、JSON parse error、DB timeout 等）
        log.error("Unexpected error — suppressing to avoid unintended retry", e);
        // 不抛出 → 方法正常结束 → ON_SUCCESS 生效 → 消息被删除
    }
}

? 关键注意事项：

• 勿滥用静默吞并：catch (Exception e) 吞并所有异常虽可防止误重试，但也掩盖了潜在 Bug。务必确保 log.error 包含完整堆栈，并接入告警系统（如 CloudWatch Alarms + Slack）。
• 自定义异常需继承 RuntimeException：Spring 的异常传播机制默认只对 RuntimeException 及其子类触发重试行为（检查 SqsMessagingTemplate 默认错误处理器逻辑）。
• 配合 SQS 队列配置：确保队列设置了合理的 VisibilityTimeout（大于方法最大执行耗时）和 maxReceiveCount（配合 DLQ 使用），避免因超时导致重复投递。
• 幂等性仍是基石：即使精准控制重试，消费者端仍必须实现幂等设计（如基于 messageId 或业务唯一键去重），因为网络抖动、实例重启等场景仍可能导致重复消息。

总结：ON_SUCCESS 是一种“乐观删除”策略，它把失败判定权完全交还给开发者。通过精细的异常分类与受控抛出，你能在保障系统健壮性的同时，实现语义清晰、可运维的消息重试边界。