【发布时间】：2017-10-05 10:21:18
【问题描述】：
我们正在使用 google-cloud-pubsub (0.24.0-beta) 拉取客户端来读取来自订阅者的消息并看到其中的高重复率。谷歌文档说几乎不会出现重复，但在我们的例子中，我们看到 80% 的消息即使在确认后也会出现重复。
最奇怪的部分是，即使我们使用 consumer.ack() 立即在接收器中确认消息，重复仍然会发生。 有谁知道如何处理。
【问题讨论】：
【发布时间】：2017-10-05 10:21:18
【问题描述】：
大量消息重复可能是flow control settings 设置过高或过低的结果。如果您的流量控制设置太高，您允许同时有太多消息未处理给您的客户端，那么可能是设置得太晚了。如果这是原因，您可能会看到机器的 CPU 达到或接近 100%。在这种情况下，请尝试将未完成消息或字节的最大数量设置为较小的数字。
也可能是流量控制设置太低。某些消息在传递到您的 MessageReceiver 之前会在客户端中进行缓冲，尤其是在您受流控制的情况下。在这种情况下，消息在传递之前可能会在客户端中缓冲过多的时间。此状态下的消息存在问题，正在 an outstanding PR 中修复。在这种情况下，您可以增加最大未完成字节数或消息数（直到您的订阅者实际可以处理的任何内容），或者您可以尝试将setAckExpirationPadding 设置为大于默认 500 毫秒的值。
还值得检查您的发布者，看看它是否意外地多次发布消息。如果是这种情况，您可能会看到消息的内容是相同的，但它们并不是由 Google Cloud Pub/Sub 本身生成的重复消息。
编辑提及客户端库中的错误：
如果您使用的是介于 v0.22.0 和 v0.29.0 之间的 google-cloud-pubsub 版本，您可能会遇到一个问题，即获取消息的底层机制可能会发生变化result in excessive duplicates。该问题已得到解决。
【讨论】：
-
在我的用例中，发布者在一分钟内发布大约 50k 条消息，然后在订阅者端，以下是我的配置： 1. FlowControlSetting MaxOutstandingElementCount 设置为等效于 ExecutorThreadCount 。说 20。 2. MaxAckExtensionPeriod 设置为 1 小时。有了这个，我也可以看到重复项。我首先尝试使用更高的 FlowControlSetting 值（比 ExecutorThreadCount），但这也不起作用，因此，我想将它们设置为等效。我们甚至尝试过同步拉取，但这也导致了同样的问题。
-
如果即使您使用同步拉取 API 也会发生这种情况，我认为您的发布中很可能有重复。您的发布是否完全失败并被重试？另外，您订阅的确认截止日期是什么时候？
-
感谢您回复卡马尔。为避免重复发布，我总是首先从堆栈驱动程序监控仪表板检查我开始发布时没有消息，然后我确保发布的消息是唯一的。因此，我确信发布部分不会发送重复。是的，如果我的订阅者没有进行任何处理而只是立即确认，我的消息将降为零。确认截止日期设置为 600 秒。
-
我再次尝试使用 Synchronous Pull API 并观察到它正在重复，以防它可能需要比 ackDeadline 更长的时间。因为我有 setMaxMessages:100 并且每条消息都需要 10 秒，所以当收到的消息大约大于 60 时，它会超出 ackDeadline（600 秒）。当我将消息处理时间更改为 5 秒时，重复项不可见。这意味着 Pull 同步 API 工作正常，但我仍然可以看到 Pull Async API 的问题（这是我们的首选）。我们可以在 Pull Async API 中做些什么来解决同样的问题吗？