条带-超出API请求速率限制-Firebase云函数

Question

假设我正在创建一个PWA（渐进式网络应用程序），用户可以在其中添加产品。这些产品的价格从0.01 EUR到1.00 EUR不等。我使用条纹支付。条纹订单对象不支持动态价格，动态传递，没有任何引用（一种外键）。要接受订单，Stripe需要引用SKU。在我的例子中，这个SKU将是产品价格的变化。这意味着，为了涵盖所有变化，我需要100个SKU，从1（0.01欧元）到100（1,00欧元）。因此，对于在Stripe中创建的每个产品，我需要在Stripe中创建100个SKU。

我尝试插入200个产品的测试数据集，这意味着（200个产品（200x100个SKU））=20200个请求。我从Stripe收到了一个令人惊讶的“请求速率限制超出”错误。创建的记录不到一半…：(

“超过请求速率限制”是问题的核心。

现在，插入过程如下（x 200）：

• 在Firestore中创建产品

我需要解决方案来对付这个条带API速率限制错误。我有几种解决方案：

能够在给定的时间内提高条带速率API限制。我不确定这是否可行。

能够使用不同的条带键，然后在其上旋转，以执行管理工作，例如在条带中插入多个产品/SKU。最终在生产环境中，我们能够以编程方式为每个用户创建一个条带密钥，这样每个用户都有自己的限制。我不确定这是否可行。

在javascript中减慢插入过程。不知道如何表演。此外，云函数的预算/限制为60秒的javascript执行。所以我不能耽搁太多。

使用发布/订阅（？）延迟工作，或Firestore触发器，例如，在Firestore中有一个整数，每个函数调用递增，同一函数侦听写入以重新递增数字，等等，等等，直到第100个SKU的数字等于100。该解决方案将100个SKU写入的数据按条带顺序排列。不确定这是否真的会减慢工作速度，使其低于API速率限制。此外，这样的解决方案将花费大量资金：对于一种产品，100次Firestore写入，以及100次函数调用来执行这些写入，这意味着对于200种产品，这将是20000/20000。那会很贵。

当用户付费时，执行实时插入。服务器端算法，在一个付款请求API调用后，可能看起来像这样：

Create order in Stripe
If error 'No such sku...' catched {
  For each SKU { // Ideally filter here SKUs to create (only those in error)
    If price not between 1 and 100 {
      continue // Bad price, not legit
    }
    Create SKU in Stripe
    If error 'Already exists' {
      continue // no creation needed for that SKU
    }
    If error 'No such product...' catched {
      If productId does not exists in Firestore {
        continue // Bad productId, not legit
      }
      Create product in Stripe
    }
    Create SKU in Stripe
  }
}
Create order in Stripe

最后一个解决方案可以完成这项工作。但是当用户执行支付时，它可能会有一些延迟，这可能会增加压力。此外，它可能会增加条纹电话在营业时间。在同一时间内多次购买可能会导致Stripe API速率限制错误，尤其是在设备齐全的购物车中（假设购物车中平均有30种产品，那么在最坏的情况下，支付期间会有30次HTTPS调用，乘以1000用户=30000次调用=

你怎么认为？你还有别的想法吗？

Answer 1

同样的想法（JIT），但将SKU创建从付款时间移到产品选择时间。每次选择产品时，请尝试在条带中创建产品及其当前SKU（价格变化）。这样，条带调用在时间上应该更分散。或者它可能会以更多的API调用结束，因为我们选择产品的频率比我们支付的频率高，因为用户可以选择

同样的想法（JIT），但是使用缓存在Algolia或Firebase中的SKU，所以我可以执行“这个SKU存在吗？”不查询Stripe的调用，如果在create调用之前执行存在性测试，则应该减少Stripe调用（我们不盲目调用Stripe.skus.create（）。缺点是，Firebase和Algolia在前面暴露，因此SKU和价格也会暴露，这是一个潜在的威胁源，因此必须使用另一个专用且仅由服务器知道的索引。

Answer 2

解决方案3和解决方案5经过一些调整将发挥最佳效果。

解决方案3：您可以使用异步模块的forEachLimit或队列将并发请求的数量限制为条带化。

解决方案5：及时插入也是一个很好的选择，因为它不会同时给条纹服务器带来太多负载。关于你担心在工作时间会出现同样的错误，这将是一个非常罕见的情况，因为条纹API的性能非常好。但是如果您仍然对此有疑问，您可以做的是在非工作时间添加SKU的后台过程，这将继续为您创建SKU，而不会遇到条带API速率限制错误。

解决方案6（修改后的解决方案5）：具有即时插入功能，但也可以在购物车中输入产品时向服务器创建额外的API请求，然后检查SKU是否存在于条带中，如果不存在，则在购物车付款之前在后台创建。