简单问题:我想在Amazon上运行一个autoscale组,它会启动多个实例来处理来自SQS队列的消息。但我怎么知道这些实例没有处理相同的消息呢?
我可以在处理消息时将其从队列中删除。但如果它还没有被删除,并且仍由一个实例处理,那么另一个实例可以下载相同的消息,并对其进行处理。
你可以收到重复的信息,但只能在“极少数情况下”收到。所以你应该以幂等为目标。
除了SQS不正确地多次传递相同消息的可能性相当小(您仍然需要解释,尽管这不太可能)之外,我怀疑您的问题源于对SQS“可见性超时”概念的不熟悉
组件收到消息后,消息仍在队列中。然而,不希望系统中的其他组件再次接收和处理该消息。因此,Amazon SQS通过可见性超时来阻止它们,这是一段时间,在此期间Amazon SQS阻止其他消费组件接收和处理该消息。
http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/AboutVT.html
这就是防止多个队列运行者看到相同消息的原因。一旦可视性超时过期,消息将再次传递给队列使用者,除非您将其删除,或者它超过了配置的最大传递次数(此时消息将被删除,或者如果您已经配置了一个死信队列,它将进入一个单独的死信队列)。如果作业所需时间超过配置的可见性超时,则消费者还可以向SQS发送请求,以更改该消息的可见性超时。
更新:
由于这个答案最初是写出来的,SQS在一些AWS地区引入了FIFO队列。它们使用与上述相同的逻辑进行操作,但有保证的按序交付和额外的保护措施,以保证偶尔不会出现重复的消息交付。
FIFO(先进先出)队列设计用于在操作和事件顺序非常关键或不能容忍重复时增强应用程序之间的消息传递。FIFO队列也只提供一次处理,但限制为每秒300个事务(TPS)。
http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html
将应用程序切换到FIFO队列确实需要一些代码更改,并且需要创建一个新队列--现有队列不能更改为FIFO。
我使用的是AWS SQS服务,很难定义SQS队列上的权限。在我的设置中,我使用的是AWS Lambda服务,当一个对象被推到S3存储桶上时会触发该服务。 然而,让我简短地提问,这是我想要实现的: 对象被推送到S3存储桶中 正如您可以从前面的用例中看到的,我希望我的AWS Lambda方法是唯一可以向SQS队列发送消息的应用程序。我试图设置一个原则和一个条件“sourceArn”。但是它们都不起作用
我想从多个SQS队列中触发一个lambda函数。lambda将进行的大部分处理都是相同的,只是一个小步骤将基于表名。我不想为此保留两个单独的lambda。拥有相同/多个lambda的利弊是什么?
提供实时监视发送到SQS队列的消息总数的最佳方法是什么? 我目前设置了一个Grafana仪表板来监视一个SQS队列,但它似乎大约每两分钟刷新一次。我正在寻找的东西设置,以更新几乎是实时的,例如刷新每秒。 我使用的队列每分钟大约消耗6,000条消息。 我的同事已经构建了一些用于实时监控上传到S3 bucket的东西,使用lambda填充PostgreSQL数据库,并使用Grafana查询。 这是否达
我有一个Spring Boot应用程序,希望从多个AWS SQS队列接收消息。这些队列都有自己的凭据(遗憾的是,我对此无能为力)。这些凭据都不能访问其他队列之一,它们都仅限于一个队列。 因为只有一个队列和凭证,所以很简单。我只需要提供作为AWSCredentialsProvider的凭据,并用启用SQS注释我的方法 但我不知道如何使用多个凭据来执行此操作。 SqsListener注释无法提供凭据、
属于同一消息组的消息总是按照相对于消息组的严格顺序逐个处理(但是,属于不同消息组的消息可能会被无序处理)。 是否知道这是否意味着300 TPS限制应用于while队列或每个消息组?
让我们假设,有一个消费者与多个工作者一起从同一个运动流的多个碎片中读取数据。我们决定从某个时间点开始重新读取所有记录。订单是否保证与第一次阅读时相同?我知道,从单个碎片读取时应该是这样。但是,在处理多个碎片时,它是否以某种方式在幕后得到了解决?