SQS Lambda-重新驱动策略与死信配置
我已经将lambda集成设置为具有固定保留并发的SQS，以限制对后端服务的请求。我需要使用DLQ来跟踪和存储错误。
使用SQS的ReDrive策略与lambda函数的DeadLetterConfig在行为上有什么不同？
我对队列中有大量消息但lambda并发性有限时的行为特别感兴趣。
共有1个答案
在函数上配置的死信队列用于函数的异步调用，而不是用于事件源队列。Lambda轮询sqs队列，并与包含队列消息的事件同步调用函数。因此，如果使用SQS作为事件源，则DeadLetterConfig没有任何用处。您必须为源SQ配置DLQ和重新驱动策略。
资料来源：https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html
-
我有一个SNS主题&订阅（实际上不止1个）设置来使用SQS DLQ。然而，每一个都告诉我，我有一个策略错误。 我的SNS订阅设置了DLQ： 我的队列存在： 我还尝试在队列上使用一个真正通用的访问策略： 我遵循的是：https://docs.aws.amazon.com/sns/latest/dg/sns-configure-dead-letter-queue.html（步骤5解释了设置策略） 其他
-
我正在设计一种机制来处理消费者没有收到的消息。
-
我正在使用ActiveMQ Artemis 2.17和Spring Boot 2.5.7。我正在发布关于主题和队列的消息并使用它。所有这些都是通过JMS完成的。所有队列（选播或多播）都是耐用的。我的主题（多播地址）有两个持久队列，以便有两个独立的使用者。在我的主题中，这两个消费者使用持久和共享订阅（JMS 2.0）。所有处理都是事务性的，通过Atomikos事务管理器进行管理（我需要它来提交数据库
-
Kubernetes文档以及关于重新启动策略的Openshift文档显示，可以使用Always、Never或OnFailure配置POD。 那么我如何从部署配置中做到这一点呢？
-
我正在使用Datastax Cassandra驱动程序，并设置了RetryPolicy，以便在主机不可用时重试。然而，我注意到它尽可能快地重试。我想将其更改为在重试之间有越来越大的延迟，而不是在集群陷入困境时对其进行重击。这对于过载的请求错误尤其重要，因为我确实希望在这些情况下重试，但会有很大的延迟。 哪里是实施延迟的正确地点，什么是正确的机制？我应该抛出一个
-
本节介绍Mixer的配置模型。 背景 Istio是一个具有数百个独立功能的复杂系统。Istio部署可能涉及数十个服务的蔓延事件，这些服务有一群Envoy代理和Mixer实例来支持它们。在大型部署中，可能在管理整体部署中涉及到许多运维人员（每个运维人员都有不同的领域和责任范围）。 Mixer的配置模式可以利用其所有功能和灵活性，同时保持使用的相对简单。该模型的范围特征使大型支持组织能够轻松地集中管理