我正在设置一个在 kubernetes pod 上运行的服务，并通过拉取订阅来订阅 pub/sub 主题。该服务将使用推送到主题的消息。
现在我将 pod 扩展到 10 个副本，并观察到有时当有新消息推送到主题时，多个 pod 会同时收到该消息。并不是 pod 1 在 ackDeadline 之前未能 ack，消息又被 pod 2 拉取，而是 pod 1 和 pod 2 在几毫秒内收到了相同的消息。
如何设置我的订阅/kubernetes，以便一次只有一个 pod 接收和处理消息？
更新：截至今天（2024 年 2 月 20 日），Pub/Sub 实施了 QoS 2（一次且仅一次），因此可以解决此问题。
旧回复： 目前 Pub/Sub 没有 QOS 2（交付一次且仅一次），因此不幸的是，没有办法开箱即用地执行您正在谈论的操作。
有关此内容的官方文档在这里：https://cloud.google.com/pubsub/docs/subscriber
建议的方法是使用 Apache Beam 的模型，而不是使用时间窗口来确保您所讨论的内容。 Google 有 Dataflow，它托管 Apache Beam 作为一个选项。
另一种方法（也许很大）可以自己实现，就是在内存中的某个位置（也许在您从 Kubernetes 访问的 Memorystore 中）有一个变量，该变量跟踪最后一个确认的时间戳，并使用有序的来自 Pub/Sub 的列表。因此，每个 Pod 都会（按顺序）从 Pub/Sub 获取，并且您将依赖共享内存中的变量来获取最后一条确认消息，而不是 Pub/Sub 的机制。显然，您仍然希望在 K8s 中处理每条消息时对其进行确认，但现在您还需要在 Memorystore 中设置变量。
我相信这应该缩小重入问题的窗口，但它仍然存在（访问变量和设置变量之间的延迟仍然足够大，您可以双重处理消息）。
这就是为什么推荐的方式是通过 Beam 开窗。数据流也可以扩展到任意大，所以从性能的角度来看，它可能与 Kubernetes 相同，但它是 Beam，所以需要学习不同的技术堆栈，而且它并不简单，但它是完成这项特定工作的工具。