Golang:使用waittimesecseconds与使用Context参数对SQS ReceiveMessage进行

Question

我可以调用SQS ReceiveMessage

sqs.ReceiveMessageInput{
QueueUrl: &mysqr.poolQUrl,
MaxNumberOfMessages: 1,
WaitTimeSeconds: 5,
}

和context.TODO()，或与

ctx := context.Background()
ctx2, cfn := context.WithTimeout(ctx, time.Second * 5)
defer cfn()
rmo, err := svc.ReceiveMessage(ctx2, &rmi)

让我们假设在5秒内没有可读的内容。

在第一种情况下，它返回fine，没有消息也没有错误，在第二种情况下，我得到一个operation error SQS: ReceiveMessage, https response error StatusCode: 0, RequestID: , canceled, context deadline exceeded。

AWS在go SDK中放置上下文是很好的，但我宁愿使用waittimesseconds参数，它感觉更简单。是否有一个良好的原则性理由来使用context方法?

Answer 1

AWS在go SDK中加入上下文真是太好了

您将WaitTimeSeconds(ReceiveMessagesAPI的一部分)与您可以潜在地附加到上下文的超时合并。

waittimesseconds是长轮询SQS队列的重要组成部分。如果没有它，空队列将导致消费者尽可能快地发出api请求，从而给AWS带来巨大的负载。超过WaitTimeSeconds并不表示错误-请求可能在降级的网络上合法地花费更多的时间。

上下文可以用于在SDK本身范围之外的原因中止SDK操作-WithTimeout只是上下文的一个这样的使用。在多线程应用程序中，您还可以使用上下文来取消由于应用程序中其他地方出现致命错误而导致的多个未完成的请求。

所以，首先，认为WaitTimeSeconds是超时是不正确的。其次，将Context视为超时也是不正确的——上下文不仅仅是控制最大运行时间。

但我宁愿使用waittimesseconds参数，它只是感觉更简单。

他们做不同的事情。Context.WithTimeout不排除WaitTimeSeconds。如果没有WaitTimeSeconds(或队列上的默认设置)，ReceiveMessages将立即返回，而Context.WithTimeout将永远没有机会超时。

是否有一个良好的原则性理由来使用上下文方法?

所以不，当然不是。除了WaitTimeSeconds之外，还有一个很好的理由使用上下文——甚至Context.WithTimeout在某些情况下也可能对ReceiveMessages请求有意义。但是，即使它们都有持续时间，在用例中也没有重叠。不管有没有上下文，在WaitTimeSeconds设置为0的情况下运行ReceiveMessages几乎都是不正确的。