请求率大答案

【问题标题】：Request rate is large请求率大
【发布时间】：2015-08-26 07:26:16
【问题描述】：

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

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

body: '{"code":"429","message":"Message: {\"Errors\":[\"Request rate is large\"]}\r\nActivityId: 1fecee65-0bb7-4991 -a984-292c0d06693d，请求URI：/应用/ cce94097-e5b2-42ab-9232-6abd12f53528 /服务/ 70926718-b021-45ee-ba2f-46c4669d952e /分区/ dd46d670-ab6f-4dca-BBBB-937647b03d97 /复制/ 130845018837894542p“} ' }

意味着 DocumentDb 无法每秒处理 1000+ 个请求？所有这些都给了我对 NoSQL 技术的不好印象。是 DocumentDB 的缺点吗？

【问题讨论】：

您能检查一下您为收藏设置的定价等级吗？是Standard S2（1000 个请求单位）还是Standard S3（2500 个请求单位）？
Gaurav，这是在我的 DocumentDB 属性刀片中看到的，STATUS Online ACCOUNT TIER Standard LOCATION Southeast Asia
我现在有什么办法可以升级到 S3 吗？
你应该是。单击门户中的集合，然后单击定价层框。您应该能够将定价层从 S2 更改为 S3。 HTH。

标签： node.js azure asynchronous azure-cosmosdb

【解决方案1】：

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

我在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 函数。

【讨论】：

我只是重读了你的问题，再想一想。 DocumentDB 处理缩放的方式是通过集合的数量。因此，如果您需要超过 2500 RUs/sec，您应该对数据进行分区并使用第二个 Collection……即使您远不及一个 Collection 的存储容量。另一方面，如果您的稳定状态远低于 2500 RUs/sec，但您很少有超过该值的突发，那么上面的 429 处理方法应该就可以了。