生产者侧如何避免向Amazon SQS标准队列发送重复消息？

Amazon SQS标准队列基于「至少一次」投递设计，网络波动、服务端ACK延迟等场景都可能导致生产者重复发送消息。以下是生产者侧的具体解决方法：

1. 实现业务层面的幂等发送（核心方案） #

给每个消息分配业务唯一标识（比如订单ID+操作类型、用户ID+事件ID这类天然唯一的业务键），发送前先通过存储层（如Redis、数据库）校验该标识是否已发送过，避免重复提交。

示例代码：

// 假设已注入Redis客户端用于幂等校验
private RedisTemplate<String, String> redisTemplate;

public void sendIdempotentMessage(String queueUrl, String message, String uniqueBizKey) {
    // 检查该业务键是否已发送过消息
    String sentFlag = redisTemplate.opsForValue().get(uniqueBizKey);
    if ("sent".equals(sentFlag)) {
        return; // 已发送，跳过本次请求
    }

    SendMessageRequest request = new SendMessageRequest(queueUrl, message);
    SendMessageResult result = amazon.sendMessage(request);

    // 发送成功后，记录标识到存储层，设置过期时间（匹配消息的业务有效期）
    redisTemplate.opsForValue().set(uniqueBizKey, "sent", 24, TimeUnit.HOURS);
}

注意：不要用SQS返回的MessageId作为幂等标识，因为重复发送的消息会生成不同的MessageId。

2. 自定义SDK重试策略 #

AWS SDK默认的重试逻辑会在网络错误、服务端异常时自动重试，容易引发重复发送。可以限制重试次数，并结合幂等校验避免无效重试：

// 配置重试策略：最多重试3次，使用默认退避策略
RetryPolicy retryPolicy = new RetryPolicy(
    PredefinedRetryPolicies.DEFAULT_RETRY_CONDITION,
    PredefinedRetryPolicies.DEFAULT_BACKOFF_STRATEGY,
    3,
    true
);

ClientConfiguration clientConfig = new ClientConfiguration();
clientConfig.setRetryPolicy(retryPolicy);

// 初始化带自定义重试的SQS客户端
AmazonSQS amazonSQS = AmazonSQSClientBuilder.standard()
    .withClientConfiguration(clientConfig)
    .build();

每次重试前，先通过业务唯一键校验是否已发送成功，避免重复提交。

3. 批量发送时利用请求内去重 #

如果使用批量发送API（sendMessageBatch），可以给每个批量消息条目指定唯一的Id，SQS会自动过滤同一批量请求内重复Id的消息，避免同一批次内的重复：

List<SendMessageBatchRequestEntry> batchEntries = new ArrayList<>();

// 每个条目设置唯一的Id（业务键或随机唯一值）
SendMessageBatchRequestEntry entry1 = new SendMessageBatchRequestEntry("biz-order-1001", "order-paid-message");
SendMessageBatchRequestEntry entry2 = new SendMessageBatchRequestEntry("biz-order-1002", "order-shipped-message");

batchEntries.add(entry1);
batchEntries.add(entry2);

SendMessageBatchRequest batchRequest = new SendMessageBatchRequest(queueUrl, batchEntries);
amazonSQS.sendMessageBatch(batchRequest);

注意：该去重仅针对同一批量请求，跨请求的重复仍需依赖业务幂等校验。

补充说明 #

即使生产者侧做了上述处理，仍可能存在极端场景（如消息发送成功但幂等记录失败）导致重复消息，因此消费者侧的幂等处理仍建议保留。但生产者侧的优化能大幅降低重复消息的产生概率。

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