重放和完全清除消息

Pub/Sub 订阅者数据 API(例如拉取)提供对消息数据的有限访问权限。通常,给定订阅的订阅者无法访问已确认的消息。此外,订阅者客户端必须处理订阅中的每条消息,即使只需要一部分消息也是如此。

还原功能允许您批量更改消息的确认状态,从而扩展订阅者功能。例如,您可以重放以前确认的消息或批量完全清除消息。此外,您还可以将还原功能与快照结合使用,将一个订阅的状态复制到另一个订阅。

这些功能如下所述。但是,您可以查看快速入门以获取工作示例。

工作原理

还原至某一时间戳

还原至某一时间会将 Pub/Sub 在该时间之前收到的每条消息标记为已确认,以及将在该时间之后收到的所有消息标记为未确认。您可以还原至将来的某一时间以完全清除消息。要重放和重新处理先前确认的消息,请还原至先前时间。消息发布时间由 Pub/Sub 服务器生成(请参阅 API 参考文档中的 publishTime)。由于以下原因,此方法不精确:

  • Pub/Sub 服务器之间可能存在时钟偏差。

  • Pub/Sub 必须使用发布请求的到达时间而不是源系统中事件的发生时间。

要还原至先前的时间,您必须首先配置您的订阅以保留已确认的消息:

还原至快照

快照功能允许您捕获订阅的消息确认状态。创建快照后,快照会保留以下消息:

  • 创建快照时来源订阅中未确认的所有消息。

  • 此后发布到主题的任何消息。

通过使用快照来还原至主题的任何订阅,您可以重放这些未确认的消息。

与还原至时间点不同,您无需执行任何特殊订阅配置即可还原至快照。您只需提前创建快照。例如,您可以在部署新订阅者代码时创建快照,以防您需要从意外或错误的确认中恢复。

在以下情况下快照会过期并由系统删除(二者取其先):

例如,设想某一订阅的快照,此订阅的积压中最早的未确认消息已保留一天时间。快照将在六天(而不是七天)后过期。此时间轴对于快照提供强有力的至少传送一次保证是必要的。

最终一致性

还原操作与消息传送保证严格一致。这意味着任何基于还原条件而未被确认的消息,可保证在还原操作成功后最终至少传送一次。但是,已传送的消息不会立即与还原操作保持一致。因此,在还原时间戳之前发布的消息或在快照中确认的消息可能会在还原操作之后传送。从某种意义上说,消息传送作为相对于还原操作的最终一致系统运行:该操作可能需要一分钟才能完全生效。

通过过滤条件查找

您可以重放带有过滤条件的订阅传来的消息。如果您使用带有过滤条件的订阅来查找时间戳,Pub/Sub 服务只会重新传送与过滤条件匹配的消息。

带有过滤条件的订阅快照包含以下消息:

  • 早于快照的所有消息,包括与过滤条件不匹配的消息。
  • 早于快照的未确认消息。

如果您使用包含过滤条件的订阅还原快照,Pub/Sub 服务只会重新传送快照中与还原请求匹配的订阅过滤条件相匹配的消息。

如需详细了解过滤条件,请参阅过滤消息

通过死信主题查找

如果您希望查找包含0死信主题的订阅消息,Pub/Sub 会将传送尝试设置为 。具备死信主题的订阅其属性可记录订阅者的传送尝试次数。

如需详细了解死信主题,请参阅转发到死信主题

通过重试政策查找

如果您通过重试政策查找订阅中的消息,Pub/Sub 会重置以下各项之间的延迟:

  1. 确认截止时间即将到期或订阅者发送否定确认。
  2. Pub/Sub 重新发送该消息。

如需详细了解重试政策,请参阅使用重试政策

使用场景

  • 安全地更新订阅者代码。部署新订阅者代码的一个问题是新的可执行文件可能会错误地确认消息,导致消息丢失。将快照合并到部署过程中,可让您从新订阅者代码中的 Bug 进行恢复。
  • 从意外的订阅者问题中恢复。如果订阅者问题与特定部署事件无关,您可能没有相关快照。在这种情况下,如果您为订阅启用了已确认的消息保留,则还原至过去的时间可让您从错误中恢复。
  • 节省处理时间和费用。对不再相关的大量积压消息执行批量确认。
  • 根据已知数据测试订阅者代码。在测试订阅者代码的性能和一致性时,每次运行都使用相同的数据会很有用。 快照通过强大的语义实现了数据的一致性。此外,快照还可以应用于给定主题的任何订阅,包括新创建的订阅。

后续步骤

您可以将 Pub/Sub 与 Dataflow 搭配使用。但是,我们不建议从正在运行的 Dataflow 流水线中直接使用 Pub/Sub 还原功能。如需了解建议的工作流,请参阅将 Pub/Sub 与 Dataflow 搭配使用