消息无法重复时AWS SQS标准队列或FIFO队列？

Question

我们计划使用AWS SQS服务对从Web服务创建的事件进行排队，然后使用多个工作程序来处理这些事件。一个事件只能处理一次。根据AWS SQS文档，AWS SQS标准队列可以“偶尔”生成重复的消息，但吞吐量无限。 AWS SQS FIFO队列不会产生重复消息，但吞吐量限制为每秒300次API调用（batchSize = 10，相当于每秒3000条消息）。我们当前的高峰时段流量仅为每秒80条消息。因此，两者在吞吐量要求方面都很好。但是，当我开始使用AWS SQS FIFO队列时，我发现我需要做额外的工作，比如提供额外的参数 “MessageGroupId”和“MessageDeduplicationId”或需要启用“ContentBasedDeduplication”设置。所以，我不确定哪一个是更好的解决方案。我们只需要不重复的消息。我们不需要将消息作为FIFO。

解决方案＃1： 使用AWS SQS FIFO队列。对于每条消息，需要为“MessageGroupId”和“MessageDeduplicationId”参数生成UUID。

解决方案＃2： 使用启用了“ContentBasedDeduplcation”的AWS SQS FIFO队列。对于每条消息，需要为“MessageGroupId”生成UUID。

解决方案＃3： 将AWS SQS标准队列与AWS ElasticCache（Redis或Memcached）一起使用。对于每条消息，“MessageId”字段将保存在缓存服务器中，稍后检查是否有重复。存在意味着此消息已被处理。 （顺便说一下，缓存服务器中存在“MessageId”多长时间.AWS SQS文档没有提到消息可以复制多久。）

Answer 1

您的系统使SQS变得复杂。

我们已经搬到了Kinesis Streams，它完美无瑕。以下是我们看到的好处，

1. 活动顺序
2. 数据显示在流
时触发事件
3. 分批交付
4. 负责处理接收器的错误
5. 如有问题，请及时回头   Buggier实施过程
6. 比SQS更高的性能

希望它有所帮助。

Answer 2

• 我的第一个问题是，为什么你没有得到重复的消息这么重要？一个理想的解决方案是使用标准队列并将您的工作人员设计为幂等的。例如，如果消息包含类似任务ID的内容并将完成的任务的结果存储在数据库中，则忽略DB中已存在任务ID的那些。
• 不要使用收据句柄来处理应用程序端重复数据删除，因为每次收到邮件时都会更改。换句话说，SQS不保证重复消息的收据处理相同。
• 如果您坚持重复数据删除，那么 使用FIFO队列。