使用推送订阅作为负载均衡器的细节

Question

我正在尝试使用推送订阅发送 IoT 命令。我有两个原因。首先，我的设备经常处于不稳定的连接状态，所以通过 pubsub 让我重试，我不必在发送消息时等待 QoS 1 超时（我仍然需要它，因为我将其记录下来供以后使用） .第二个原因是推送订阅可以充当负载均衡器。据我了解，如果多个消费者收听同一个推送订阅，每个消费者都会收到消息的一个子集，从而有效地平衡我的工作量。现在我的问题是，这种平衡是我在请求订阅中观察到的一种行为，我想知道是否：

1. 推送订阅的行为是否相同？
2. 这是平衡工作量的可靠方法吗？
3. 如果有 15 个实例监听该订阅，我是否保证这些命令最多执行一次？

这是我要实现的目标的图表：

这里的想法是，我仅在实例收到要处理的设备子集时（推送订阅触发时）才与 IoT Core 交互。另请注意，我不需要这个完美的 1 个实例来实现 1 个设备平衡。我只需要以半均等的方式分配工作量。

编辑：问题不清楚所以我重写了它。

Answer 1

我认为您对 Pub/Sub 背后的概念有点困惑。通常，您向 一个 或 多个 订阅者的主题发布消息。我更喜欢将 Pub/Sub 与一家大型出版公司出版的杂志进行比较。喜欢该杂志的人可以通过订阅的方式获得该杂志的副本。然后，当该杂志的新版本到达时，将向杂志订阅者发送一份副本，所有订阅者的内容完全相同。

对于 Pub/Sub，您可以为一个主题创建多个推送订阅，每个主题最多 10,000 个订阅（也每个项目）。您可以在 documentation 中阅读有关这些配额的更多信息。这些推送订阅可以包含不同的端点，在您的情况下，代表您的物联网设备。回到出版公司的例子，那些推送端点可以看作是订阅者的地址。

这是一个 example IoT 核心架构，它侧重于处理从您的设备到商店的数据。反过来也行得通。将消息（包括 device/registry ID）从您的前端发送到包裹在 API 网关中的 Cloud Functions。然后，此 Cloud Function 将消息发布到主题，该主题将消息发送到使用 MQTT 协议发布消息的 Cloud Function。我为您制定了松散耦合的两个流程，这样即使您的设备或处理出现任何问题，数据也不会丢失。

存储设备：

1. 设备
2. 物联网核心
3. Pub/Sub
4. 云函数/数据流
5. 存储（BigQuery 等）

设备前端：

1. 前端（点击按钮）
2. API 网关/云端点
3. 云函数（发送命令到pub/sub）
4. Pub/Sub
5. 云功能（使用 MQTT 向设备发送命令）
6. 设备（执行命令）