Google Pub/Sub の cloud.google.com/go/pubsub ライブラリの RetryPolicy は、指数バックオフをPub/Sub とそのクライアント間の通信の信頼性を高める構成可能な機能です。
指数関数的バックオフでは、再試行間の遅延が指数関数的に増加します。 。これにより、過剰な再試行によるサーバーの過負荷が防止され、より段階的な再接続が保証されます。
RetryPolicy 構成では、MinimumBackoff は、 github.com/cenkalti/backoff ライブラリであり、MinimumBackoff は MaxInterval に対応します。
MinimumBackoff は最初の再試行前の初期待機期間を設定し、 MaximumBackoff は再試行間に許容される最大遅延を表します。デフォルトでは、MinimumBackoff は 10 秒、 MaximumBackoff は 10 分です。
Pub/Sub は、ランダム化された指数関数に基づいて再試行間の待機間隔を計算します。バックオフ式:
`
`RetryInterval * (random value in range [1 - RandomizationFactor, 1 + RandomizationFactor])
`
ここで、RetryInterval は現在の再試行間隔であり、最初は MinimumBackoff です。
github.com/cenkalti/backoff ライブラリの MaxElapsedTime 機能とは異なり、Pub/Sub RetryPolicy は制限されません。再試行を制限する同等のオプションがあります。代わりに、再試行を制限する必要がある状況では、デッド レター キュー (DLQ) を使用することをお勧めします。
Pub/Sub RetryPolicy は、ランダム コンポーネントを使用して、再試行間隔に差異を導入し、同じ構成の複数のクライアントがまったく同じ間隔で再試行しないようにします。
実験による観察結果指数バックオフ動作を反映します。 MinimumBackoff に 1 秒、 MaximumBackoff に 2 秒を使用すると、ナック間の遅延が比較的一貫して ~3 秒であることがわかり、これは最大バックオフ 2 秒を表しています。
再試行間に 2 倍の間隔がないことは、明示的な乗数が適用されていないことを示唆しています。さらに、再試行回数のハード制限は観察されておらず、再試行の制限に DLQ を使用するという推奨事項が裏付けられています。以上がGoogle Pub/Sub の RetryPolicy は指数バックオフをどのように実装していますか?また、他のバックオフ ライブラリとの違いは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。