重复受限制的 DynamoDB 请求
我正在使用适用于 PHP 的 AWS 开发工具包以编程方式与 DynamoDB 交互.
I am using the AWS SDK for PHP to interact programmatically with DynamoDB.
我想检测对 DynamoDB 的请求是否受到限制，以便在短暂延迟后发出另一个请求.
I would like to detect if a request to DynamoDB has been throttled so another request can be made after a short delay.
现在，我在假设未满足受限制的请求的情况下进行操作.亚马逊常见问题解答 建议在发生限流时返回 400 错误.
Right now, I am operating under the assumption that throttled requests are not fulfilled. Amazon FAQs suggest that a 400 error is returned when throttling occurs.
所以我目前的逻辑看起来像这样:
So I currently have logic that looks something like this:
for( $i=0; $i<10; $i++ ) {
$response = $dynamodb->get_item($get_item_args);
if( $response->isOK() ) {
break;
} elseif( $i < 9 ) {
sleep(1);
}
}
我想这可行，但它是一个 bit 愚蠢.特别是，它将重复所有失败的请求，而不仅仅是受限制的请求.如果出现不可解决的错误，我真的不想重复请求.
I suppose this works, but it is a bit dumb. In particular, it will repeat all failed requests, not just throttled requests. If there is a non-resolvable error, I really don't want to repeat the request.
为了更智能，我想在一个受限制的响应中查看唯一标识符(即特定错误消息).但就我的一生而言，我无法捕获(或在 Internet 上的任何地方找到)样本限制响应.
To make this smarter, I'd like to look inside a throttled response for a unique identifier (i.e. a specific error message). But for the life of me, I can't capture (or find anywhere on the internet) a sample throttled response.
补偿限制风险和最大限度提高满足请求的可能性的最佳方法是什么?
What is the best way to compensate for the risk of throttling and maximize the likelihood of a fulfilled request?
推荐答案
事实证明，AWS SDK 会自动重试受限制的请求，直到成功.所以我上面的努力是不必要的(因为我使用的是 AWS SDK for PHP).
It turns out, the AWS SDKs will automatically retry throttled requests until success. So my efforts above are unneeded (since I am using the AWS SDK for PHP).
处理 Amazon DynamoDB 中的错误 文档页面对 ProvisionedThroughputExceededException 错误说如下:
The Handling Errors in Amazon DynamoDB documentation page says the following for the ProvisionedThroughputExceededException error:
适用于 Amazon DynamoDB 的 AWS 开发工具包自动重试请求收到此异常.所以，你的请求最终成功了，除非请求太大或您的重试队列太大而无法完成.
The AWS SDKs for Amazon DynamoDB automatically retry requests that receive this exception. So, your request is eventually successful, unless the request is too large or your retry queue is too large to finish.
相关文章