可以将pubsub消息重复数据删除到pubsub并进行数据流处理吗？

Question

我有一个将数据写入Google Cloud pubsub的应用程序，根据pubsub的文档，由于重试机制而导致的重复项有时会发生。还存在消息混乱的问题，pubsub也无法保证。

根据文档，也可以使用Google Cloud Dataflow对这些消息进行重复数据删除。

我想使这些消息在消息传递队列（意味着云pubsub）中可用，以供服务使用，而Cloud Dataflow似乎有一个pubsubio编写器，但是您不会回到写相同的完全相同的问题上吗？ pubsub可以创建重复项吗？那不是订单的问题吗？如何使用pubsub（或与此相关的任何其他系统）按顺序流式传输消息？

是否可以使用云数据流从pubsub主题中读取并写入另一个pubsub中，并且保证没有重复？如果没有，您将如何做以支持流式传输相对少量的数据？

我对Apache Beam / Cloud Dataflow也很陌生。这样一个简单的用例会是什么样子？我想我可以使用pubsub本身生成的ID进行重复数据删除，因为我让pubsub库执行其内部重试而不是自己进行，因此该ID在重试时应该相同。

Answer 1

不可能使用Cloud Dataflow从发布/订阅主题中读取并写入另一个可以保证没有重复的发布/订阅主题。重复可以两种方式之一发生：

1. 发布者两次发布相同的消息。从发布/订阅服务的角度来看，这是两条单独的消息，并且都将被传递。例如，如果发布者进行发布，但失败并显示DEADLINE_EXCEEDED，并且发布者重试，则会发生这种情况。在这种情况下，第一次发布尝试实际上确实可以成功，但是响应没有及时传递回发布者。

2. Pub / Sub服务将消息传递给订阅者，或者它不确认该消息，或者在回传给该服务的过程中丢失了ack。 Pub / Sub具有至少一次的交付保证。这种情况的一个主要来源是ack是尽力而为的事实，这意味着即使用户发送了ack，它也可能不会一直返回到服务，例如，如果网络中断。

鉴于这两种不同的重复模式，重复数据删除的唯一方法是在最终接收消息的订户中执行此操作，方法是通过Dataflow或其他某种机制，例如将接收到的ID记录在数据库中。请注意，在任何一种情况下，使用发布/订阅服务生成的ID可能都不足够，因为在错误后重试请求的情况下，可能会重复发布。

Answer 2

Cloud Dataflow / Apache Beam是Mac卡车。它们设计用于并行处理大型数据源/流。您可以将大量数据发送到PubSub，但是检测重复项并不是Beam的工作，因为此任务需要序列化。

阅读PubSub，然后再写入其他主题并不能消除重复的问题，因为在您要写入的新主题上可能会发生重复。此外，队列写入的并行化进一步增加了出现乱序消息的问题。

重复的问题需要在从订阅中读取的客户端上解决。一个简单的数据库查询可以让您知道某个项目已经被处理。然后您就丢弃该消息。

处理乱序消息也必须设计到您的应用程序中。

PubSub被设计为轻量级的廉价消息队列系统。如果您需要保证消息顺序，没有重复项，FIFO等，那么您将需要使用其他解决方案，当然这要贵得多。