升级策略用于 Pub/Sub 订阅应用程序

学习Golang要努力，但是不要急！今天的这篇文章《升级策略用于 Pub/Sub 订阅应用程序》将会介绍到等等知识点，如果你想深入学习Golang，可以关注我！我会持续更新相关文章的，希望对大家都能有所帮助！

我很好奇如何处理使用来自 Google Pub/Sub 的消息的应用程序的升级/重新启动情况。

例如，我对开发一个 Golang 应用程序特别感兴趣，该应用程序部署在 Kubernetes 中运行多个 Pod，并使用来自 Google Pub/Sub 的消息。我关心的是如何确保在升级 Pod 时不会丢失任何消息（或处理两次）。

我了解应用程序将从订阅中读取消息，然后必须确认已收到该消息。我觉得在确认消息和 Pod 关闭升级之间可能存在竞争条件？

我知道数据流作业可以做类似的事情，因为您可以停止流作业并指示它耗尽消息。

我认为必须有某种方法来优雅地处理这个问题，或者这确实是 Dataflow 更适合的情况吗？

正确答案

Kubernetes 使用 SIGTERM，等待 30 秒，然后 SIGKILL。这可以让您的应用程序在完全终止之前有适当的时间，如果 30 秒默认值不够，您可以使用 terminationGracePeriodSeconds: 60 字段进行调整（链接 1）。

然后，您需要在 Golang 中添加逻辑以接收 SIGTERM 信号（链接 2）。

最后，假设你的队列是rabbit（但其他队列也有类似的功能），在收到SIGTERM后，你可以将逻辑写入A）停止接收新消息，然后B）（这是可选的，你可以只让它们完成）为 Pod 当前已确认但未完成的所有消息返回 NACK 和重新排队信号，将消息放回原处（链接 3 和 4）。

如果您可以避免实现 NACK/Requeue，而只需通过关闭队列侦听器并完成当前保留的消息的其余部分来处理 SIGTERM（假设 30 或 60 秒就足够了），那么这就简单多了推荐。

1. https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace

2. Golang catch signals

3. Ack or Nack in rabbitMQ

4. https://www.rabbitmq.com/nack.html

** 编辑 **

对于 Google Cloud pub/sub，您还可以发送 Nack。

https://pkg.go.dev/cloud.google.com/go/pubsub#Message

“Ack 表示消息处理成功。如果消息确认失败，消息将被重新传送。Nack 表示客户端不会或不能处理消息。Nack 会导致消息比原来更快地重新传送”允许过期。”

理论要掌握，实操不能落！以上关于《升级策略用于 Pub/Sub 订阅应用程序》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！