クライアント・サーバー・システムのバックオフ・メカニズムのパターン

Question

ユーザーがシステムで検索するたびに外部システムに要求を送信する必要があるシステムがあります。

外部システムがダウンしている、または異常に長い時間がかかっている場合は、しばらくの間、システムを「バックオフ」したいと思います。外部システムへの要求を増やそうとするのではなく、私のシステムのユーザーがすぐに要求を処理しないようにするだけです。

これにより、ユーザーにとってより良いエクスペリエンス（タイムアウトを待つ必要はありません）、システムでのリソース使用率が低下します（スレッドは外部システムからの応答やタイムアウトを待つことなくビジー状態になります）。それは外部システムを救うだろう。 （既に負荷がかかっている状況で）

しばらくして、またはシステムが外部システムが再び応答していることがわかったときに、再び正常な動作を再開したいと思います。

このようなことを行うためのパターンや標準的な方法はありますか？具体的には、タイムアウト/ロング要求を追跡するためのメカニズム、および再試行を開始するときのための制御メカニズムです。

Answer 1

これは文献に記載されているのを覚えていませんが、このようなタスクセンターが「スケジューリングキュー」に気づいたパターンは、さまざまなことを実現する方法です（==関数（例えば、Pythonのsched標準ライブラリモジュール）。バックエンドに（非同期）リクエストを送信すると、今からX秒間のタイムアウトイベントもスケジュールされます。要求オブジェクトはスケジュールされたタイムアウトのIDを知っている（要求がそれ以前に満たされた場合にそれをキャンセルする）か、保留中の要求のセットも維持される（タイムアウトが本当に必要でない時を知る）とにかく、「本当にそれを意味するタイムアウト」を扱いやすくするためのアイデアは、以下を参照してください。

タイムアウトが発生すると、将来Y秒間の再試行をスケジュールし、そのコンテナから保留中のすべての要求を、将来再試行される要求のコンテナに移動します（システムがどのようにシステムまた、待機中のすべてのクライアントに対して、「バックエンドが遅い、Y秒間に再試行します」という通知を送信します。

リトライイベントが発生した場合などシステムが中断されている間に新しい要求が到着した場合は、「再試行する」ビンに移動します。

私が説明し、このパターンを見つけることはできませんが、どこにでもあれば、それはSchmidt's excellent bookで、おそらくです...非常にとにかく読んでお勧めします - ！）