amazon-web-services - 无法复制消息时的 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. 如有问题及时返回 错误的流程实现
6. 比 SQS 性能更高

希望对您有所帮助。