请求率很大

我使用Azure documentdb并通过我的node.js在express服务器上访问它，当我在循环中查询时，数量很少的几百个没有问题。但是，当查询在循环稍微大体积，说一千左右加请求率很大

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

body：'{“code”：“429”，“message”：“消息：{\”Errors \“：[\”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“}'}

Mea nDocumentDb无法处理每秒超过1000个请求？一起给我在NoSQL技术上留下不好的印象..是DocumentDB的简短介绍吗？

来源

2015-08-26 Shreyz

你可以检查你为收藏设定的定价层次是什么？是“标准S2”（1000个请求单元）还是“标准S3”（2500个请求单元）？ –

拉夫，这是我DocumentDB性质是什么见刀片，STATUS 在线账户TIER 标准位置东南亚 – Shreyz

什么办法可以升级到S3现在？ – Shreyz

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

我写了逻辑来处理这个在我的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函数。

来源

2015-08-26 12:20:33

我刚刚重读你的问题，并有一个更多的想法。 DocumentDB处理缩放的方式是通过集合的数量。因此，如果您需要超过2500 RU /秒，您应该划分您的数据并使用第二个集合...即使您没有接近一个集合的存储容量。另一方面，如果你的稳定状态远低于2500RU /秒，但你不经常发生突发情况，那么上面的429处理方法应该没问题。 –

回答

相关问题