请求率大

Question

我使用 Azure documentdb 并通过我在 express 服务器上的 node.js 访问它，当我循环查询时，少量的几百个没有问题。但是在loop中query的时候体积稍微大一点，比如说千加

我得到部分结果（不一致，每次我运行结果值都不相同。可能是因为 Node.js 的异步性质）结果很少后，它因此错误而崩溃

正文：'{"code":"429","message":"Message: {\"错误\":[\"Request rate is large\"]}\r\nActivityId:1fecee65 -0bb7-4991-a984-292c0d06693d，请求 URI：/apps/cce94097-e5b2-42ab-9232-6abd12f53528/services/70926718-b021-45ee-ba2f-46c4669d952e/partitions/dd46d670-ab6f-4dca-bbbb-937647b03d97/replicas/130845018837894542p"}' }

意思是 DocumentDb 无法每秒处理 1000+ 个请求？总而言之，这让我对 NoSQL 技术产生了不好的印象。它是 DocumentDB 的短板吗？

Answer 1

正如 Gaurav 所建议的那样，您可以通过提高定价层来避免该问题，但即使您转到最高层，您也应该能够处理 429 错误。当您收到 429 错误时，响应将包含 'x-ms-retry-after-ms' header。这将包含一个数字，表示您在重试导致错误的请求之前应该等待的毫秒数。

我在 documentdb-utils node.js package 中编写了逻辑来处理这个问题。您可以尝试使用 documentdb-utils 也可以自己复制它。这是一个 snipit 示例。

createDocument = function() {
   client.createDocument(colLink, document, function(err, response, header) {
        if (err != null) {
            if (err.code === 429) {
                var retryAfterHeader = header['x-ms-retry-after-ms'] || 1;
                var retryAfter = Number(retryAfterHeader);
                return setTimeout(toRetryIf429, retryAfter);
            } else {
                throw new Error(JSON.stringify(err));
            }
        } else {
            log('document saved successfully');
        }
    });
};

注意，在上面的例子中document是在createDocument的范围内。这使得重试逻辑更简单一些，但如果您不喜欢使用广泛范围的变量，那么您可以将 document 传递给 createDocument，然后将其传递给 setTimeout 调用中的 lambda 函数。

请求率大

Request rate is large

asynchronous

azure

node.js

azure-cosmosdb