使用Pub / Sub和docs进行Google云端存储通知

Question

在关于GCP存储和发布/订阅通知的文档中，我发现这句话并不是很清楚：

  

Cloud Pub / Sub还向收件人提供至少一次发送 [非常清楚] ，   这意味着你可以收到多个消息，多个消息   ID，代表相同的云存储事件 [为什么？]

任何人都可以更好地解释这种行为吗？

谢谢！

Answer 1

Google云端存储使用至少一次发送功能将您的通知发送到Cloud Pub / Sub。换句话说，GCS将针对发生的每个事件向Cloud Pub / Sub发布至少一条消息。

接下来，Cloud Pub / Sub订阅将至少向您（最终用户）发送一次消息。

因此，在极少数情况下，GCS会向Cloud Pub / Sub发布有关同一事件的两条消息。现在，一个GCS事件有两个发布/订阅消息ID。接下来，为了使其更加不可能，Pub / Sub会将这些消息中的每一个传递两次。现在，您已收到4条消息，其中包含2条消息ID，大约相同的单个GCS事件。

警告的重要内容是您不应尝试按发布/订阅消息ID重复数据删除GCS事件。

Answer 2

至少一次 投放意味着该服务必须接收来自收件人的确认，以确保收到该邮件。在这种情况下，我们需要某种超时时间才能重新发送消息。由于网络延迟或数据包丢失等原因，收件人可能会发送确认，但发件人在超时期限之前未收到确认，因此发件人将再次发送邮件。

这是一个常见问题，是网络通信和分布式系统，并且有不同类型的消息传递来解决这个问题。

Answer 3

回答“为什么”的问题

“至少一次”传递只是意味着将通过某种重试机制重试消息，直到成功传递（即确认）为止。因此，如果出现故障或超时，则将重试。

从本质上讲（重试机制），这意味着您有时可能会重复/多次交货。无论是发布消息的PubSub通知还是GCS通知，都一样。

在您引用的情况下，您具有：

1. 发布者（GCS通知）- 可以将GCS事件的副本发送到pubsub主题
2. PubSub主题消息--- 可能包含发布者的重复邮件
   • 在消息进入时不进行重复数据删除
   • 所有消息都分配了唯一的PubSub message_id，即使它们是同一GCS事件通知的重复项
3. PubSub主题订阅--- 还可能向订阅者发送邮件副本

---

使用PubSub

  

一旦消息发送给订户，订户必须确认或丢弃该消息。邮件一旦发送出去并在订阅者确认之前就被认为是未解决的邮件。

     

订户具有可配置的有限时间量或ackDeadline，以确认消息。截止日期过后，一条杰出的消息将不被确认。

     

Cloud Pub / Sub将反复尝试传递任何未确认或未完成的消息。

来源：https://cloud.google.com/pubsub/docs/subscriber#at-least-once-delivery

使用Google Cloud Storage

他们需要在内部做类似的事情，才能将通知事件从GCS“发布”到PubSub-因此原因基本相同。

---

这为什么重要

• 您需要期待来自GCS通知以及PubSub订阅的偶尔重复
• PubSub消息ID可用于检测pubsub主题->订户中的重复项
• 您必须弄清楚自己的幂等ID /令牌才能处理“发布者”中的重复项（GCS通知事件）
  resource representation的
  • 生成，元生成等。

如果您需要重复数据删除或仅完成一次处理，则可以使用幂等ID /令牌构建自己的解决方案，或者查看Cloud Dataflow是否可以满足您的需求。

  

您可以使用Cloud Dataflow PubsubIO对Cloud Pub / Sub消息流进行一次处理。 PubsubIO对自定义消息标识符或由Cloud Pub / Sub分配的消息进行重复数据删除。   来源：https://cloud.google.com/pubsub/docs/faq#duplicates

如果对我们看到的原因的更基本的探索感兴趣：

There is No Now - Problems with simultaneity in distributed systems