发布/订阅应用程序的升级策略

Question

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

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

我知道应用程序会从订阅中读取消息，然后必须确认它已收到它。我觉得在确认消息和 Pod 关闭以进行升级之间可能存在争用条件？

我知道使用Dataflow作业可以执行类似操作，因为您可以停止流式处理作业并发出信号以清空消息。

我假设必须有某种方式可以优雅地处理这个问题，或者这真的是数据流更适合的情况吗？

Answer 1

Kubernetes 使用 SIGTERM，等待 30 秒，然后是 SIGKILL。这会在完全终止应用程序之前为应用程序提供适当的时间，如果 30 秒的默认值不够，则可以使用该字段进行调整（链接 1）。terminationGracePeriodSeconds: 60然后，您需要在 Golang 中添加逻辑以接收 SIGTERM 信号（链接 2）。最后，假设你的队列在这里是兔子（但其他队列将具有类似的功能），在收到SIGTERM时，你可以将逻辑写入A）停止接收新消息，然后B）（这是可选的，你可以让他们完成）返回一个NACK和重新排队信号，用于Pod当前已确认但未完成的所有消息， 将消息放回原处（链接 3 和 4）。如果您可以避免实现 NACK/Requeue，只需通过关闭队列侦听器并完成当前保留消息的其余部分来处理 SIGTERM（并说 30 或 60 秒就足够了），那就简单多了，建议这样做。https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace戈朗捕捉信号兔子MQ中的Ack或Nackhttps://www.rabbitmq.com/nack.html** 编辑 **对于谷歌云发布/订阅，您还可以发送Nack。https://pkg.go.dev/cloud.google.com/go/pubsub#Message“Ack 表示成功处理消息。如果消息确认失败，将重新传递消息。Nack 表示客户端不会或无法处理消息。Nack 将导致消息被重新传递的速度比允许它过期时更快。