問題タブ [exponential-backoff]

AmazonDynamoDBClient以下を使用して標準を作成しましたAmazonDynamoDBClientBuilder。

AmazonDynamoDBClientのドキュメントには、次のように記載されています。

ProvisionedThroughputExceededException- リクエスト率が高すぎます。DynamoDB の AWS SDK は、この例外を受け取ったリクエストを自動的に再試行します。再試行キューが大きすぎて完了できない場合を除き、リクエストは最終的に成功します。リクエストの頻度を減らし、指数バックオフを使用します。

が原因で失敗した要求を再試行するときに、標準クライアントに対してデフォルトで指数バックオフが使用されますProvisionedThroughputExceededExceptionか? または、これは手動で構成する必要があるものですか?

1 分あたりの最大リクエスト レートを持つ CDN システムを扱っています (すべてのオブジェクトがほぼ同じサイズであるため、ビットレートの制限はありません)。

率直に言って、それが #/clock 分なのか、それとも計算されたレートなのかはまだわかりません。

(独立したワーカーではなく) スレッド オンデマンドでアイテムをダウンロードする単一のデーモンがあります。これは、このシステムの適切なモデルです。

「彼ら」は、制限に達したときに指数バックオフを使用することを提案しましたが、それは私には意味がありません. 指数バックオフの主な用途は、リソースの衝突の問題を解決することです。独立した労働者がいれば、これは理にかなっていると思います。

しかし、単一のデーモン システム (ここでも適切な使用モデル) の場合、次のクロック分を待つか、レート調整メカニズムを使用するよりも、なぜこれが優れているのでしょうか?

これが良いメカニズムであることを示すKnuthの「ベストフィットに相当するファーストフィット」の証拠はありますか? それは確かに実装するのが最も簡単です!

ですから、これは以前に何度も尋ねられたことは知っていますが、多くのことを試しましたが、何もうまくいかないようです.

これらのブログ/記事/コードから始めましょう:

• https://blog.danlew.net/2016/01/25/rxjavas-repeatwhen-and-retrywhen-explained/
• https://jimbaca.com/rxjava-retrywhen/
• http://blog.inching.org/RxJava/2016-12-12-rx-java-error-handling.html
• https://pamartinezandres.com/rxjava-2-exponential-backoff-retry-only-when-internet-is-available-5a46188ab175
• https://gist.github.com/wotomas/35006d156a16345349a2e4c8e159e122

そして他の多く。

簡単に言えば、それらはすべて、retryWhen を使用して指数バックオフを実装する方法を説明しています。このようなもの：

ライブラリのドキュメントでさえ、 https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/core/Observable.java#L11919に同意してい ます。

ただし、これといくつかのかなり類似したバリエーションを試しましたが、ここで説明する価値はありませんが、何も機能していないようです. 例が機能し、ブロックしているサブスクライバーを使用している方法がありますが、スレッドのブロックを避けたいです。

したがって、前のオブザーバブルに次のようなブロッキング サブスクライバーを適用するとします。

期待どおりに動作します。しかし、それはアイデアではありません。試してみると：

フローは一度しか実行されないため、達成したいことではありません。

それは私がしようとしているように使用できないことを意味しますか? ドキュメントから、私の要件を達成しようとするのは問題ではないようです。

私は何が欠けているのですか？

ティア。

編集：これをテストしている2つの方法があります：

テスト方法 (testng を使用):

Kafka コンシューマーから (Spring ブートを使用):

これはオブザーバーへのサブスクリプションにすぎませんが、再試行ロジックは、この投稿で以前に説明したものです。

アプリケーションでいくつかのソファベースの例外を処理しようとしています。upsert メソッドは、サーバー側での一時的な障害を示すTemporaryFailureExceptionをスローできます。ドキュメントの CAS 値が更新された可能性はありますか? この例外が発生した場合に備えて、指数バックオフで一定回数再試行しています。CAS 値が更新された場合は、次回再試行するときに、更新された CAS 値を渡すことを確認する必要があります。そうしないと、CASMismatchException が発生します。

サーバー側で障害が発生した場合に CAS 値が更新されないという保証はありますか?