Golang调用SQS ReceiveMessage：WaitTimeSeconds和Context超时方案对比

结论 #

两种方案并非非此即彼，WaitTimeSeconds是SQS服务端的长轮询等待参数，控制服务端最多等多久有消息再返回；context超时是客户端侧的调用生命周期控制，控制客户端最多愿意等待本次调用的时长。context超时方案有几个不可替代的原则性优势，更适合绝大多数生产场景：

• 全链路生命周期对齐：如果你的SQS消费逻辑嵌套在更大的业务流程里（比如HTTP请求处理、定时任务、上游服务调用链），上游传入的context本身已经携带了超时时间，或支持上游主动取消，直接把这个context传给SQS调用，就能保证整个链路的生命周期一致。比如上游请求已经因为超时取消，你不需要继续空等SQS返回，直接中断调用释放资源即可。
• 多操作统一管控：当你的业务逻辑不止调用SQS一个接口，还要同时调用其他AWS服务、数据库、第三方接口等支持context的组件时，你只需要给整个业务流程初始化一个统一超时的context，传给所有下游操作即可，不需要给每个组件单独计算、配置超时时间，大幅降低配置出错的概率。
• 支持主动取消场景：context除了超时自动中断外，还支持手动触发取消。最典型的就是服务优雅停机场景：你收到系统停机信号后，只需要cancel全局context，所有正在阻塞的SQS ReceiveMessage调用会立刻返回，不需要等到WaitTimeSeconds设置的时间结束，能大幅加快停机速度，避免进程被强制杀死导致消息处理异常。

推荐生产级配置 #

二者完全可以结合使用，不会冲突：

1. 把WaitTimeSeconds设置为SQS长轮询的推荐最大值20，最大化降低空轮询的频次，减少API调用成本
2. 外层传入带业务合理超时的context，控制单次ReceiveMessage调用的最长等待时间，同时对齐全链路生命周期
3. 代码里主动判断返回的错误是否为context.DeadlineExceeded或context.Canceled，这类错误可以当成无消息的正常情况处理，不需要当成异常告警。

内容的提问来源于stack exchange，提问作者Tim Bray