parsing - DocumentDB 返回 "Request rate is large"，在 azure 上解析

我在 azure 上运行解析(托管 Azure 服务上的解析服务器)，
我不包括 DocumentDB 作为数据库，并且有每秒请求数的限制。
一些解析云函数很大，请求速度太快(即使是 S3 层)，所以我收到这个错误(使用 Visual Studio Team Services(Visual Studio Online)和流日志看到)。

    error: Uncaught internal server error. { [MongoError: Message: {"Errors":["Request rate is large"]}

ActivityId: a4f1e8eb-0000-0000-0000-000000000000, Request URI: rntbd://10.100.99.69:14000/apps/f8a35ed9-3dea-410f-a89a-28650ff41381/services/2d8e5320-89e6-4750-a06f-174c12013c69/partitions/53e8a085-9fed-4880-bd90-f6191765f625/replicas/131091039101528218s]
  name: 'MongoError',
  message: 'Message: {"Errors":["Request rate is large"]}\r\nActivityId: a4f1e8eb-0000-0000-0000-000000000000, Request URI: rntbd://10.100.99.69:14000/apps/f8a35ed9-3dea-410f-a89a-28650ff41381/services/2d8e5320-89e6-4750-a06f-174c12013c69/partitions/53e8a085-9fed-4880-bd90-f6191765f625/replicas/131091039101528218s' } MongoError: Message: {"Errors":["Request rate is large"]}

ActivityId: a4f1e8eb-0000-0000-0000-000000000000, Request URI: rntbd://10.100.99.69:14000/apps/f8a35ed9-3dea-410f-a89a-28650ff41381/services/2d8e5320-89e6-4750-a06f-174c12013c69/partitions/53e8a085-9fed-4880-bd90-f6191765f625/replicas/131091039101528218s
    at D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:673:34
    at handleCallback (D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:159:5)
    at setCursorDeadAndNotified (D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:501:3)
    at nextFunction (D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:672:14)
    at D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:585:7
    at queryCallback (D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:241:5)
    at Callbacks.emit (D:\home\site\wwwroot\node_modules\mongodb-core\lib\topologies\server.js:119:3)
    at null.messageHandler (D:\home\site\wwwroot\node_modules\mongodb-core\lib\topologies\server.js:397:23)
    at TLSSocket.<anonymous> (D:\home\site\wwwroot\node_modules\mongodb-core\lib\connection\connection.js:302:22)
    at emitOne (events.js:77:13)

如何处理这个错误？

最佳答案

TL; 博士;

在新的定价方案下将旧的 S3 集合升级为新的单个集合。这最多可以支持 10K RU(从 2500 RU 开始)

删除旧的 S3 集合并创建一个新的分区集合。将需要在解析中支持分区集合。

实现符合 x-ms-retry-after-ms 响应 header 的退避策略。

长答案:

对 DocumentDB 的每个请求都会返回一个 HTTP header ，其中包含该操作的请求费用。每个集合配置请求单元的数量。根据我的理解，您有 1 个大小为 S3 的集合，因此该集合每秒只能处理 2500 个请求单位。

DocumentDB 通过添加多个集合来扩展。对于使用 S1 -> S3 的旧配置，您必须手动执行此操作，即您必须使用一致性散列、 map 或日期等算法将数据分布到集合中。使用 DocumentDB 中的新定价，您可以使用分区集合，通过定义分区键，DocumentDB 将为您分片您的数据。如果您看到持续的 RequestRateTooLarge 错误率，我建议扩展分区。但是，您需要调查 Parse 是否支持分区集合。

当您收到 HTTP 429 RequestRateTooLarge 时，还有一个名为 x-ms-retry-after-ms :### 的 header ，其中 ### 表示重试操作之前等待的毫秒数。您可以做的是实现重试操作的退避策略。请注意，如果您在重试期间有客户端卡在服务器上，您可能会建立请求队列并阻塞服务器。我建议添加一个队列来处理这种突发。对于短时间的请求，这是一种很好的处理方式，无需扩展集合。

关于parsing - DocumentDB 返回 "Request rate is large"，在 azure 上解析，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/37537811/