消息排序是 Pub/Sub 的一项功能,可让您在订阅方客户端中按发布方客户端发布消息的顺序接收消息。
例如,假设某个区域中的发布方客户端按顺序发布消息 1、2 和 3。借助消息排序功能,订阅方客户端会按相同的顺序接收发布的消息。为了按顺序传送,发布方 客户端必须在同一 区域中发布消息。 不过,订阅者可以连接到任何区域,并且排序保证仍然有效。
消息排序是一项有用的功能,适用于数据库更改捕获、用户会话跟踪和流式应用等场景,在这些场景中,保留事件的时间顺序非常重要。
本页面介绍了消息排序的概念,以及如何设置订阅方客户端以按顺序接收消息。如需为消息排序配置发布方 客户端,请参阅使用排序键发布 消息。
消息排序概览
Pub/Sub 中的排序由以下因素决定:
排序键 。排序键是一个字符串,用于标识应排序的相关消息。排序键的示例包括客户 ID 或数据库中某行的主键。排序键的长度上限为 1 KB。
如需实现消息排序,请在所有应按顺序接收的相关消息上设置相同的排序键。此外,您必须在同一区域中发布具有相同排序键的所有消息。如需了解详情,请参阅 使用排序键发布消息。
具有空排序键的消息不会排序。
启用消息排序 。如需按顺序接收消息,您必须在订阅中启用消息排序。如需了解详情,请参阅 启用消息排序。
如果未启用消息排序,则订阅接收的消息将不按预期顺序排列。例如,假设订阅 A 和 B 都附加到同一主题 T,并且在 订阅 A 中启用了排序,但在订阅 B 中未启用排序。虽然这两个订阅 都从主题 T 接收同一组消息,但只有订阅 A 保留了排序 。
每个排序键的发布吞吐量上限为 1 MBps。主题上所有排序键的吞吐量上限为发布区域中可用的配额。此限制可以提高到多个 GBps。
一般来说,如果您的解决方案要求发布方客户端发送有序消息和无序消息,请创建单独的主题,一个用于有序消息,另一个用于无序消息。
使用有序消息传递时的注意事项
以下列表包含有关 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 的限制,而是受订阅方客户端的处理速度的限制。当单个排序键上积压的消息过多时,就会出现热键,因为每秒生成的消息数超过了订阅者每秒可以处理的消息数。如需缓解热键问题,请使用尽可能精细的键,并尽量缩短每条消息的处理时间。您还可以监控
subscription/oldest_unacked_message_age指标,如果该值不断上升,则可能表示存在热键。
如需详细了解如何使用消息排序,请参阅以下最佳实践主题:
订阅方客户端的消息排序行为
订阅方客户端会按消息在特定区域中发布的顺序接收消息。Pub/Sub 支持不同的消息接收方式,例如连接到拉取订阅和推送订阅的订阅方客户端。客户端库使用 streamingPull(PHP 除外)。
如需详细了解这些订阅类型,请参阅选择订阅类型。
以下部分讨论了按顺序接收消息对于每种类型的订阅方客户端意味着什么。
StreamingPull 订阅方客户端
将客户端库与 streamingPull 搭配使用时,您必须指定一个用户回调,该回调会在订阅方客户端收到消息时运行。 对于任何给定的排序键,客户端库都会按正确的顺序对消息运行回调,直到完成。如果在该回调中确认了消息,则对消息的所有计算都会按顺序进行。不过,如果用户回调安排了对消息的其他异步工作,则订阅方客户端必须确保异步工作按顺序完成。一种选择是将消息添加到按顺序处理的本地工作队列。
拉取订阅方客户端
对于连接到拉取订阅的订阅方客户端,Pub/Sub 消息排序支持以下功能:
对于一个排序键,一次只能有一批消息处于待处理状态。
由于 Pub/Sub 服务无法确保其为订阅者的拉取请求发送的响应的成功或延迟时间,因此需要一次只能有一批消息处于待处理状态,以保持有序传送。
推送订阅方客户端
对推送的限制比对拉取的限制更严格。 对于推送订阅,Pub/Sub 一次仅支持每个排序键的一条待处理消息。每条消息都会作为单独的请求发送到推送端点。因此,并行发送请求与同时向拉取订阅者传送同一排序键的多批消息存在相同的问题。 对于经常使用相同排序键发布消息的主题或延迟时间非常重要的主题,推送订阅可能不是一个好的选择。
导出订阅方客户端
导出订阅支持有序消息。对于 BigQuery 订阅,具有相同排序键的消息会按顺序写入其 BigQuery 表。对于 Cloud Storage 订阅,具有相同排序键的消息可能不会全部写入同一文件。 在同一文件中,排序键的消息按顺序排列。当分布在多个文件中时,排序键的后续消息可能会出现在文件名的时间戳早于包含较早消息的文件名的时间戳的文件中。
启用消息排序
如需按顺序接收消息,请在从中接收消息的订阅上设置消息排序属性。按顺序接收消息可能会增加延迟时间。创建订阅后,您无法更改消息排序属性。
您可以在使用 控制台、Google Cloud CLI 或 Pub/Sub API Google Cloud 创建订阅时设置消息排序属性。
控制台
要使用消息排序属性创建订阅,请执行以下操作:
- 在 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 客户端库的主要版本 (v2)。如果您仍在使用 v1 库,请参阅 迁移到 v2 的指南。 如需查看 v1 代码示例列表,请参阅 已废弃的代码示例。
在尝试此示例之前,请按照 《快速入门:使用客户端库》中的 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 客户端库 v3。如果您仍在使用 v2 库,请参阅 迁移到 v3 的指南。 如需查看 Ruby v2 代码示例列表,请参阅 已废弃的代码示例。
在尝试此示例之前,请按照 《快速入门:使用客户端库》中的 Ruby 设置说明进行操作。 如需了解详情,请参阅 Pub/Sub Ruby API 参考文档。