配置消息存储政策

如果您将消息发布到全局 Pub/Sub 端点， Pub/Sub 会自动将消息存储在最近的 Cloud de Confiance by S3NS 区域中。如果您想控制将消息存储在哪些区域以及在哪些区域处理消息，可以针对主题配置消息存储政策。

消息存储政策概览

您可以在创建新主题时或使用控制台、Google Cloud CLI 或 REST API 更新主题时设置消息存储政策。

消息存储政策仅适用于消息内容。该政策不适用于其他数据，例如主题名称、标签或 Identity and Access Management (IAM) 设置。

当客户端将消息发布到 Pub/Sub 时，Pub/Sub 会存储消息。消息存储政策可确保 Pub/Sub 仅在您指定的一组 Cloud de Confiance by S3NS 区域中存储和处理消息，无论发布或 订阅请求来自何处。如果该政策允许发布 操作使用多个区域，则 Pub/Sub 会将消息存储在发布的消息进入网络时所处位置最近的允许使用的区域中。 Cloud de Confiance

指定消息存储政策时，您可以将 enforceInTransit 设置为 True。此标志控制以下内容：

• 在消息存储政策不允许使用的区域中收到的发布、拉取和流式拉取请求会被拒绝，并显示 FAILED_PRECONDITION 错误。

• 如果客户端在允许使用的区域之一（例如 Compute Engine 虚拟机）内运行，则可以使用全局 端点。 Cloud de Confiance 客户端的请求会在允许使用的区域中本地路由。 客户端还可以使用以允许使用的区域为目标的 定位端点 或区域性端点 。

• 如果客户端在不允许使用的区域内运行 Cloud de Confiance ， 或者在不允许使用的区域外运行 Cloud de Confiance，则必须使用以允许使用的区域列表中的区域为目标的定位端点或区域性 端点。

• 推送订阅的传送仅在允许使用的 Cloud 区域内处理。在某些情况下，此限制可能会完全暂停推送订阅的消息传送。当推送订阅因推送位置受到消息存储位置、允许使用的区域和导出资源位置等因素的过度限制而进入此类状态时，此状态会在 Stackdriver 中显示。

新主题的消息存储政策

• 如果您在创建主题时未指定消息存储政策， 系统会根据有效的 资源位置限制 组织政策自动确定消息存储政策。 如果没有任何组织政策，则允许使用所有区域。

• 同样，在没有指定消息存储政策的情况下，enforceInTransit 标志会根据有效的对 Pub/Sub 消息强制执行传输中区域 组织政策确定。如需详细了解此组织政策，请参阅 组织政策限制条件。

• 如果您在创建主题时指定消息存储政策，该储政策可以仅包含有效资源位置限制 组织政策所允许的区域。如果没有任何组织政策，则消息存储政策可以包含任何区域。

现有主题的消息存储政策

• 更新组织政策后，相应的更改不会自动传播 到现有主题。因此，现有主题的消息存储政策可能与最新的组织政策不同步。如需了解详情，请参阅管理组织政策与主题政策之间的差异。

• 更新主题的消息存储政策后，相应的更改不会传播 到已发布的消息。已根据旧政策存储的消息不会 更改为与更新后的政策一致。相应的更改仅适用于更新后发布的消息。

例外情况

该政策会指定允许使用的 Cloud de Confiance 区域名称列表。因此，系统不支持以下两项：

• 排除列表
• 地区或多区域位置

如果您发布带有 排序键的消息，并且消息 存储政策排除最近的区域，则 Pub/Sub 服务 将返回错误。

配置消息存储政策

您可以通过以下两种方式为主题配置消息存储政策：

• 使用组织政策设置消息存储政策。
• 在创建主题时配置消息存储政策。

使用组织政策设置消息存储政策

在创建主题时配置消息存储政策

gcloud pubsub topics create TOPIC_ID \
    --message-storage-policy-allowed-regions=REGION1,REGION2

 POST https://pubsub.googleapis.com/v1/projects/PROJECT_ID/topics/TOPIC_ID
 Authorization: Bearer $(gcloud auth application-default print-access-token)
 Content-Type: application/json --data @response-body.json

{
  "name": "projects/PROJECT_ID/topics/TOPIC_ID",
  "messageStoragePolicy": {
    "allowedPersistenceRegions": ["REGION"],
    "enforceInTransit": true
  }
}

{
  "name": "projects/PROJECT_ID/topics/TOPIC_ID",
  "messageStoragePolicy": {
    "allowedPersistenceRegions": [
      "REGION"
    ],
    "enforceInTransit": true
  }
}

更新消息存储政策

gcloud pubsub topics update TOPIC_ID \
    --recompute-message-storage-policy

gcloud pubsub topics update TOPIC_ID \
    --message-storage-policy-allowed-regions=REGION1,REGION2

 PATCH https://pubsub.googleapis.com/v1/projects/PROJECT_ID/topics/TOPIC_ID
 Authorization: Bearer $(gcloud auth application-default print-access-token)
 Content-Type: application/json --data @response-body.json

{
  "name": "projects/PROJECT_ID/topics/TOPIC_ID",
  "messageStoragePolicy": {
    "allowedPersistenceRegions": ["REGION"], // Replace with your required region
    "enforceInTransit": true
  }
}

{
  "name": "projects/PROJECT_ID/topics/TOPIC_ID",
  "messageStoragePolicy": {
    "allowedPersistenceRegions": [
      "REGION"
    ],
    "enforceInTransit": true
  }
}

管理组织政策与主题政策之间的差异

查看组织政策与主题政策之间的差异

gcloud pubsub topics describe TOPIC_ID

解决组织政策与主题政策之间的差异

监控和问题排查

为了帮助您了解消息数据的存储位置，Pub/Sub 提供了按每个 Cloud de Confiance 区域划分的指标。

您可以使用这些指标来实现以下目的：

• 了解您的数据在世界范围内的分布情况。
• 根据这些数据优化发布者和订阅者的部署位置。

消息存储指标

未确认的存储消息的计数：

subscription/num_unacked_messages_by_region

存储数据量：

subscription/unacked_bytes_by_region

最早的消息存在时长：

subscription/oldest_unacked_message_age_by_region

主题和快照有类似的指标。此外，选择保留用于重放的已确认消息也有相应的指标。例如：

subscription/num_retained_acked_messages_by_region

性能和可用性影响

消息存储政策不会影响整体服务等级协议 (SLA)，但是，如果发布者或订阅者在 Google Cloud 之外运行或者在该政策不允许使用的区域中运行，则该政策会影响可用性。 Cloud de Confiance 在消息存储政策允许使用的区域集内运行发布者客户端的用户不会看到服务的延迟时间或可用性有什么变化。

如需了解这些影响，有必要考虑发布请求的路由方式。通常，Pub/Sub 会尝试将消息存储在尽可能靠近请求来源的位置。源自 Google Cloud 的请求通常会绑定到同一区域中的 Pub/Sub 实例。Cloud de Confiance 如果发布者位于单个区域，则在消息存储政策中仅仅添加更多区域并不会提高可用性。 从 Google Cloud 外部发布时，需要额外的路由层来将请求发送到提供 Cloud de Confiance by S3NSPub/Sub 服务的附近区域。 Cloud de Confiance by S3NS

您可以考虑仅允许使用 us-central1 区域的消息存储政策。

1. 在 us-east1 中运行的发布者客户端发出 Publish 请求。
2. 请求路由到 us-east1 中的 Pub/Sub 服务器。
3. 请求路由到消息存储政策允许使用的最近区域 (us-central1)，而不是将数据存储在 us-east1 中。
4. Pub/Sub 将发布的消息存储在 us-central1 中，并将消息从该位置转发给订阅者。

此机制会影响请求延迟时间和整体系统可用性。由于请求会遍历更多网络链接，因此需要更长的时间才能完成，并且失败的可能性相对较高。这也意味着订阅者可能会稍微晚一点看到消息，因为消息在调度之前必须前往允许使用的最近区域。如果政策允许使用单一区域，但发布者应用在多个区域运行，则该分布式应用的可用性仅与允许使用的该单一区域相同。

后续步骤

• 如需了解如何使用全局端点或定位端点，请参阅 Pub/Sub API 概览。