Question

我使用Azure documentdb并通过我的node.js在快速服务器上访问它，当我在循环中查询时，低容量的几百没有问题。但是当循环中的查询量略大时，请说大约一千加

我得到部分结果（不一致，每次运行结果值都不一样。可能是因为Node.js的异步性质）几个结果后它崩溃了这个错误

正文：＆＃39; {＆＃34;代码＆＃34;：＆＃34; 429＆＃34;，＆＃34;消息＆＃34;：＆＃34;消息：{\＆＃34;错误\＆＃34;：[\＆＃34;请求率很大\＆＃34;]} \ r \ nActivityId：1fecee65-0bb7-4991-a984-292c0d06693d，请求URI：/ apps / cce94097-e5b2-42ab- 9232-6abd12f53528 /服务/ 70926718-b021-45ee-ba2f-46c4669d952e /分区/ dd46d670-ab6f-4dca-BBBB-937647b03d97 /复制/ 130845018837894542p＆＃34;}＆＃39; }

意味着DocumentDb每秒无法处理1000多个请求？总而言之，我对NoSQL技术给人留下了不好的印象..它是DocumentDB的缺失吗？

Answer 1

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

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

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函数调用

要求率很高

1 个答案: