Google URL Shortener 403レート制限を超えました
GoogleのURL短縮APIを使用して、負荷でテストを開始するまで問題なく動作しました。 APIを使用するようにサインアップしたにもかかわらず、1日あたり1,000,000ヒットが発生しましたが、Googleから403レート制限超過エラーをすぐに取り戻しました。私はグーグルのレポートツールで入ってくるリクエストを見ることができます、そして、彼らはすべてのために403のを返送しているだけです。 403はAPIの約345/350ヒットで戻ってきて、何時間も続いています。
考え？
APIは、リクエストを1リクエスト/秒/ユーザーに制限します。
ユーザーは一意のIPアドレスとして定義されます。
したがって、単一のIPから負荷テストを行っていると、レート制限の問題が発生します。
https://developers.google.com/analytics/devguides/reporting/mcf/v3/limits-quotas#general_api
「1リクエスト/秒/ユーザー」ではないと思います。ドキュメントで書かれているように、私の場合、またはGoogleのURL短縮サービスの場合は100％正しいです。 （参考：私は「OAuth」ではなく「パブリックAPIアクセス」を使用しています）
私はほとんど同じ問題を抱えていますが、私にとっては、「一部のURLでこのエラーが一定期間発生する」可能性が高くなります。どういう意味ですか？読み続けてください。
これらは私が見つけたものです：
- 10スレッドを使用してgoogle url shorterを同時に使用できますが、常にではありません...
- 処理時に、1つのスレッドで1つのURLが失敗しても、他のスレッドは他のURLを取得できます。
- uRLが失敗し、後で同じURLをもう一度試しました（他のプロセスが実行されていなくても、一定の期間は機能しません。 "＆test = 1"などの文字列を追加しようとしましたが、助けにはなりませんが、別のURLに変更した場合は機能します。
そのため、Googleのサーバーには各URLのキャッシュがある可能性があります。 URLが失敗した場合、キャッシュが解放されるまでしばらく待つ必要があります。
だから、私は私の問題を解決するためにこのような気味の悪いコードを書かなければなりません：
- 失敗した場合、その特定のスレッドは1分間スリープします（はい1分間）
- 10回試行し続ける（つまり、失敗したURLの場合、合計で10分になる可能性があります）
ただし、ExecutorServiceを固定スレッドプールサイズ10で使用しているので、この不気味なコードは私の場合には問題ありません。したがって、障害が発生した場合でも、他のユーザーは短縮URLを取得できます。それは問題を解決します...少なくとも私にとっては。