消息排序是 Pub/Sub 的一项功能,可让您在订阅方客户端中按发布方客户端发布的消息顺序接收消息。
例如,假设某个区域中的发布方客户端按顺序发布消息 1、2 和 3。启用消息排序后,订阅方客户端会按相同的顺序接收已发布的消息。为了按顺序传送消息,发布商客户端必须在同一区域中发布消息。不过,订阅者可以连接到任何区域,并且订阅保证仍然有效。
消息排序是一项实用功能,适用于需要保留事件时间顺序的场景,例如数据库更改捕获、用户会话跟踪和流式应用。
本页介绍了消息有序传输的概念,以及如何设置订阅方客户端以按顺序接收消息。如需配置发布方客户端以实现消息有序,请参阅使用排序键发布消息。
消息排序概览
Pub/Sub 中的排序由以下因素决定:
排序键:这是 Pub/Sub 消息元数据中使用的字符串,表示必须对消息进行排序的实体。排序键的长度不得超过 1 KB。如需在某个区域内接收一组有序消息,您必须在同一区域内发布具有相同排序键的所有消息。排序键的一些示例包括客户 ID 和数据库中某行的主键。
每个排序键的发布吞吐量上限为 1 MBps。主题上的所有排序键的吞吐量受限于发布区域中的可用配额。此限制可提高到多个 GBps 单位。
排序键与基于分区的消息传递系统中的分区并不等同,因为排序键的基数预计要比分区高得多。
启用消息排序:这是一项订阅设置。当订阅启用了消息排序时,订阅者客户端会按服务收到消息的顺序接收在同一区域发布且具有相同排序键的消息。您必须在订阅中启用此设置。
假设您有两个订阅 A 和 B 附加到同一主题 T。订阅 A 的配置启用了消息排序,而订阅 B 的配置未启用消息排序。在此架构中,订阅 A 和订阅 B 都会从主题 T 接收同一组消息。如果您在同一区域发布带有排序键的消息,订阅 A 会按消息发布的顺序接收消息。而订阅 B 会收到消息,但没有任何预期的顺序。
一般来说,如果您的解决方案要求发布方客户端同时发送有序消息和无序消息,请创建单独的主题,一个用于有序消息,另一个用于无序消息。
使用有序消息传递时的注意事项
以下列表包含有关 Pub/Sub 中有序消息传递行为的重要信息:
键内排序:使用相同排序键发布的消息应按顺序接收。假设您针对排序键 A 发布了消息 1、2 和 3。启用有序传送后,1 应在 2 之前传送,2 应在 3 之前传送。
跨键排序:使用不同的排序键发布的消息预计不会按顺序接收。假设您有排序键 A 和 B。对于排序键 A,系统会按顺序发布消息 1 和 2。对于排序键 B,系统会按顺序发布消息 3 和 4。不过,消息 1 可能会在消息 4 之前或之后到达。
消息重新传送:Pub/Sub 会为每条消息至少传送一次,因此 Pub/Sub 服务可能会重新传送消息。重新传送某个消息会触发重新传送该键的所有后续消息,即使是已确认的消息也是如此。假设订阅方客户端针对特定排序键接收消息 1、2 和 3。如果消息 2 被重新传送(因为确认时限已过或尽力确认未保留在 Pub/Sub 中),则消息 3 也会被重新传送。如果在订阅上同时启用了消息排序和死信主题,则可能不是这样,因为 Pub/Sub 会尽最大努力将消息转发到死信主题。
确认延迟和死信主题:对于给定有序键的未确认消息,可能会延迟其他有序键的消息传送,尤其是在服务器重启或流量变化期间。为确保在处理此类事件时保持秩序,请确保及时确认所有消息。如果无法及时确认,请考虑使用死信主题,以防止消息无限期保留。请注意,将消息写入死信主题时,顺序可能无法保留。
消息亲和性(streamingPull 客户端):系统通常会将具有相同键的消息传送到同一 streamingPull 订阅方客户端。如果特定订阅方客户端的排序键有未处理的消息,则预计会出现亲和度。如果没有待处理的消息,则亲和性可能会因负载均衡或客户端断开连接而发生变化。
为了确保即使在可能发生亲和性变化的情况下也能顺利处理,请务必以能够针对给定排序键在任何客户端中处理消息的方式设计 streamingPull 应用。
与 Dataflow 集成:使用 Pub/Sub 配置 Dataflow 时,请勿为订阅启用消息排序。Dataflow 有自己的总消息排序机制,可确保在进行窗口操作时所有消息都按时间顺序排列。这种排序方法不同于 Pub/Sub 基于排序键的方法。将排序键与 Dataflow 搭配使用可能会降低流水线性能。
自动伸缩:Pub/Sub 的有序传送可扩展到数十亿个排序键。排序键数量越多,可以向订阅者并行传送的消息就越多,因为排序会应用于具有相同排序键的所有消息。
有序送达确实存在一些缺点。与无序传送相比,有序传送会降低发布可用性并增加端到端消息传送延迟时间。在有序传送情况下,故障切换需要协调,以确保消息以正确的顺序写入和读取。
如需详细了解如何使用消息排序,请参阅以下最佳实践主题:
消息排序的订阅方客户端行为
订阅方客户端会按消息在特定区域发布的顺序接收消息。Pub/Sub 支持通过不同的方式接收消息,例如连接到拉取订阅和推送订阅的订阅方客户端。客户端库使用 streamingPull(PHP 除外)。
如需详细了解这些订阅类型,请参阅选择订阅类型。
以下部分将讨论按顺序接收消息对每种类型的订阅方客户端意味着什么。
StreamingPull 订阅者客户端
将客户端库与 streamingPull 搭配使用时,您必须指定一个用户回调,以便在订阅方客户端收到消息时运行该回调。使用客户端库时,对于任何给定的排序键,系统都会按正确的顺序对消息运行回调,直至运行完毕。如果消息在该回调中得到确认,则对消息的所有计算都会按顺序进行。不过,如果用户回调针对消息安排了其他异步工作,订阅方客户端必须确保异步工作按顺序完成。一种方法是将消息添加到按顺序处理的本地工作队列。
拉取订阅者客户端
对于连接到拉取订阅的订阅方客户端,Pub/Sub 消息排序支持以下操作:
PullResponse 中针对某个排序键的所有消息在列表中均处于正确的顺序。
一个排序键一次只能有 1 批待处理的消息。
由于 Pub/Sub 服务无法确保其为订阅者的拉取请求发送的响应的成功或延迟时间,因此必须要求一次只能有 1 批待处理的消息,以便保持有序传送。
推送订阅者客户端
对推送的限制比对拉取的限制更严格。对于推送订阅,Pub/Sub 一次只能支持每个排序键有一个待处理消息。每条消息都会作为单独的请求发送到推送端点。因此,并行发送请求会出现与针对同一排序键传送多批消息以同时拉取订阅者相同的问题。对于经常使用相同排序键发布消息或延迟时间极其重要的主题,推送订阅可能不是一个好选择。
导出订阅客户
导出订阅支持有序消息。对于 BigQuery 订阅,具有相同排序键的消息会按顺序写入其 BigQuery 表。对于 Cloud Storage 订阅,具有相同排序键的消息可能并不都写入同一文件。在同一文件中,具有相同排序键的消息是按顺序排列的。当分布在多个文件中时,排序键的后续消息可能会出现在文件名中的时间戳比包含早期消息的文件名中的时间戳更早的文件中。
启用消息排序
要按顺序接收消息,请在从中接收消息的订阅上设置消息排序属性。按顺序接收消息可能会增加延迟时间。创建订阅后,您将无法更改消息排序属性。
您可以在使用 Google Cloud 控制台、Google Cloud CLI 或 Pub/Sub API 创建订阅时设置消息排序属性。
控制台
要使用消息排序属性创建订阅,请执行以下操作:
- 在 Google Cloud 控制台中,进入订阅页面。
点击创建订阅。
输入订阅 ID。
选择要接收消息的主题。
在消息排序部分,选择使用排序键对消息排序。
点击创建。
gcloud
如需使用消息排序属性创建订阅,请使用 gcloud pubsub subscriptions
create
命令和 --enable-message-ordering
标志:
gcloud pubsub subscriptions create SUBSCRIPTION_ID \ --enable-message-ordering
将 SUBSCRIPTION_ID 替换为订阅的 ID。
如果请求成功,命令行会显示一条确认消息:
Created subscription [SUBSCRIPTION_ID].
REST
如需使用消息排序属性创建订阅,请发送如下所示的 PUT
请求:
PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID Authorization: Bearer $(gcloud auth application-default print-access-token)
替换以下内容:
- PROJECT_ID:包含主题的项目的 ID
- SUBSCRIPTION_ID:订阅的 ID
在请求正文中,指定以下内容:
{ "topic": TOPIC_ID, "enableMessageOrdering": true, }
将 TOPIC_ID 替换为要附加到订阅的主题的 ID。
如果请求成功,则响应为 JSON 格式的订阅:
{ "name": projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID, "topic": projects/PROJECT_ID/topics/TOPIC_ID, "enableMessageOrdering": true, }
C++
在尝试此示例之前,请按照《快速入门:使用客户端库》中的 C++ 设置说明进行操作。如需了解详情,请参阅 Pub/Sub C++ API 参考文档。
C#
在尝试此示例之前,请按照《快速入门:使用客户端库》中的 C# 设置说明进行操作。 如需了解详情,请参阅 Pub/Sub C# API 参考文档。
Go
在尝试此示例之前,请按照《快速入门:使用客户端库》中的 Go 设置说明进行操作。 如需了解详情,请参阅 Pub/Sub Go API 参考文档。
Java
在尝试此示例之前,请按照《快速入门:使用客户端库》中的 Java 设置说明进行操作。 如需了解详情,请参阅 Pub/Sub Java API 参考文档。
Node.js
在尝试此示例之前,请按照《快速入门:使用客户端库》中的 Node.js 设置说明进行操作。如需了解详情,请参阅 Pub/Sub Node.js API 参考文档。
Node.js
在尝试此示例之前,请按照《快速入门:使用客户端库》中的 Node.js 设置说明进行操作。如需了解详情,请参阅 Pub/Sub Node.js API 参考文档。
Python
在尝试此示例之前,请按照《快速入门:使用客户端库》中的 Python 设置说明进行操作。 如需了解详情,请参阅 Pub/Sub Python API 参考文档。
Ruby
在尝试此示例之前,请按照《快速入门:使用客户端库》中的 Ruby 设置说明进行操作。 如需了解详情,请参阅 Pub/Sub Ruby API 参考文档。