语境
aws Simple Queue Service（ sqs ）为微服务，分布式系统和无服务器应用程序提供了完全管理的消息排队。
最佳实践
在单独的线程或过程中消耗消息
节点是单线螺纹；它只能一次执行一个任务。创建一个单独的过程会产生隔离，例如，如果消费者峰值CPU或内存使用情况，则可以防止API可用性问题。
消费者应该愿意
EventBridge和SQS都提供一旦消息传递提供。这意味着重复消息将在某个时候发生。消费者必须优雅地处理这一点。避免重复写作的一种简单方法是使用消费者使用的生产者提供的ID来重复删除消息。
快速处理消息或设置正确的配置
设置可见性超时取决于您的应用程序处理和删除消息所需的时间。例如，如果您的应用程序需要10秒来处理消息，并且将可见性超时设置为15分钟，则必须等待相对较长的时间，如果以前的处理尝试失败，则必须尝试再次处理消息。另外，如果您的应用程序需要10秒来处理消息，但您将可见性超时设置为仅2秒钟，则在原始消费者仍在处理该消息时，另一个消费者将收到一份重复的消息。
。
如果使用sqs-consumer库，并且您知道处理消息批处理需要多长时间，请配置visibility timeout。否则，配置heartbeat interval。
配置A 死信队列（ dlq ）具有最大消息保留（14天）
Details。如果消费者未能处理消息n次数（通过SQS maxReceiveCount配置），则该消息将发送到DLQ。这样可以防止毒药的信息连续失败，这会对消费者吞吐量产生负面影响。
避免自动消耗DLQ
如果您消耗DLQ消息并删除它们，它们将永远消失。相反，设置最大14天消息保留。这为消息提供了一个安全的位置，可以在根本上引起问题，从而导致消息最终到达那里。一旦部署了修复程序，您就可以消耗DLQ消息以最新服务。
处理部分批次响应
如果您的处理程序返回而没有错误，则SQS-Consumer将从队列中删除消息。但是，丢弃错误会使整个批次失败。为了删除它们，请返回处理程序中成功的消息列表。对于Lambdas，see this。
对于lambda，将可视性超时设置为6倍，将功能超时和重新列出策略至少为5
为了使您的功能时间来处理每批记录，请将源队列的visibility timeout设置为至少六倍的timeout that you configure在您的功能上。如果您的功能在处理以前的批次时，额外的时间允许Lambda重试。
在将消息发送到死书队列之前，请给出一个更好的机会处理，请将
maxReceiveCount设置在源队列的Redrive策略上至少 5 。