Google Pub/Sub 控制RateLimit
Google Pub/Sub to control RateLimit
我制作了一个云函数来执行以下操作：
- 今天晚上获取一次前天订单id的过滤器（大约400个id）。
- 对于每个 id 从源获取详细信息。
- 对于每个详细信息，从目标获取额外信息。
- 作为发票发送给目标。
我的问题在第 2 步。速率限制为每分钟 14 个请求。所以我想在 1 和 2 之间创建一个 Pub/Sub。创建一个从主题中提取消息的订阅函数。处理其中的 14 条并确认这些消息，然后解决承诺。但这给我留下了疑问：
- 这是正确的流程吗？
- 我如何安排第 2 步？
- 如果我收到 429 响应，我会等待 1 分钟（这将被计费）
- 让步骤 2 运行 每 1 分钟不获取 429 响应代码？ （这将 运行 一天中没有消息的很长时间。
- 而不是拉动 pub/sub 触发函数，检查响应代码 -> 如果是 429，则等待 1 分钟以继续。但我的问题是：它会调用云函数的一个实例还是多个实例？
希望有人能分享一些想法。我是云函数和异步编程的新手。我的孔函数按预期工作，限制为 5 个订单。就在后来我遇到了这个速率限制（我知道，愚蠢的我）。
个人认为可以使用Firestore为每个id（文档id）存储一个进程的状态。
我的意思是第一个函数在 Firestore 集合中创建（大约）400 个文档——问题中每个 id 一个文档。然后每个文档都可以用作“状态机”和给定文档处理的“日志”——从详细信息检索到发票生成和发布...
此外，第一个函数可以发送带有文档id的pubsub消息（目前大约有400条消息）。
在 pubsub 主题的另一边 - 有第二个云功能。我会并行计算其实例的最大数量 运行ning 以最小化 API 率异常，但如果收到异常 - 这不是问题。这个函数做真正的工作并在成功的情况下更新 firestore 文档的状态（即“完成”），或者在异常的情况下更新一些其他状态...
然后我们有一些调度程序（假设每 15 分钟一次，或 10 分钟，或 20 分钟 - 我不知道上下文），一个 pubsub 主题和另一个云功能。这个云函数（在收到调度程序的消息后）扫描 Firestore 集合，并且对于状态为 'exception' 的文档向第一个 pubsub（见上文）发送一条消息，以便可以重新处理文档 - 这是一个“自我修复”过程...
进程“日志”（状态更新等）可以收集在 Firestore 文档中，因此他们每个人都可以获得整个进程如何（以及多长时间）发生的“历史”...
此外，我会使用专用的 Stackdriver 日志来监控它的运行情况（如果每个时间单位的异常数量超过某个限制 - 例如，它可能会触发警报）。日志消息，应包含与 Firestore 集合中的“日志”（和其他详细信息）或多或少相似的信息。
然后我会在 BigQuery 中使用一个接收器并有一些 reports/dashboards（如果需要）...
最后应该有一个自定义服务帐户 运行 那些具有相关 IAM 角色的云功能可以使用 GCP 资源（pubsub、firestore、Stackdriver 等）...
我制作了一个云函数来执行以下操作：
- 今天晚上获取一次前天订单id的过滤器（大约400个id）。
- 对于每个 id 从源获取详细信息。
- 对于每个详细信息，从目标获取额外信息。
- 作为发票发送给目标。
我的问题在第 2 步。速率限制为每分钟 14 个请求。所以我想在 1 和 2 之间创建一个 Pub/Sub。创建一个从主题中提取消息的订阅函数。处理其中的 14 条并确认这些消息，然后解决承诺。但这给我留下了疑问：
- 这是正确的流程吗？
- 我如何安排第 2 步？
- 如果我收到 429 响应，我会等待 1 分钟（这将被计费）
- 让步骤 2 运行 每 1 分钟不获取 429 响应代码？ （这将 运行 一天中没有消息的很长时间。
- 而不是拉动 pub/sub 触发函数，检查响应代码 -> 如果是 429，则等待 1 分钟以继续。但我的问题是：它会调用云函数的一个实例还是多个实例？
希望有人能分享一些想法。我是云函数和异步编程的新手。我的孔函数按预期工作，限制为 5 个订单。就在后来我遇到了这个速率限制（我知道，愚蠢的我）。
个人认为可以使用Firestore为每个id（文档id）存储一个进程的状态。
我的意思是第一个函数在 Firestore 集合中创建（大约）400 个文档——问题中每个 id 一个文档。然后每个文档都可以用作“状态机”和给定文档处理的“日志”——从详细信息检索到发票生成和发布...
此外，第一个函数可以发送带有文档id的pubsub消息（目前大约有400条消息）。
在 pubsub 主题的另一边 - 有第二个云功能。我会并行计算其实例的最大数量 运行ning 以最小化 API 率异常，但如果收到异常 - 这不是问题。这个函数做真正的工作并在成功的情况下更新 firestore 文档的状态（即“完成”），或者在异常的情况下更新一些其他状态...
然后我们有一些调度程序（假设每 15 分钟一次，或 10 分钟，或 20 分钟 - 我不知道上下文），一个 pubsub 主题和另一个云功能。这个云函数（在收到调度程序的消息后）扫描 Firestore 集合，并且对于状态为 'exception' 的文档向第一个 pubsub（见上文）发送一条消息，以便可以重新处理文档 - 这是一个“自我修复”过程...
进程“日志”（状态更新等）可以收集在 Firestore 文档中，因此他们每个人都可以获得整个进程如何（以及多长时间）发生的“历史”...
此外，我会使用专用的 Stackdriver 日志来监控它的运行情况（如果每个时间单位的异常数量超过某个限制 - 例如，它可能会触发警报）。日志消息，应包含与 Firestore 集合中的“日志”（和其他详细信息）或多或少相似的信息。
然后我会在 BigQuery 中使用一个接收器并有一些 reports/dashboards（如果需要）...
最后应该有一个自定义服务帐户 运行 那些具有相关 IAM 角色的云功能可以使用 GCP 资源（pubsub、firestore、Stackdriver 等）...