問題タブ [circuit-breaker]

重複の可能性：
C＃で一般的な例外をキャッチできないのはなぜですか？

最近、サーキットブレーカーのコードを確認して記述しています。次のメソッドはコンパイルされますが、catchブロックは入力されません。私にはたくさんの回避策があり、これが正しい動作（例外のフィルタリング）を取得する唯一の方法ではありませんが、なぜこれがコンパイルされて機能しないのか興味があります！

これは、前のメソッドのcatchブロックに入る必要があるテストです。

サーキットブレーカーパターン、本「Release It！ 」より 、障害が発生している（または回復している）間、リモートサービスを要求から保護し、クライアントが繰り返し発生するリモートサービスの障害を管理するのに役立ちます。私はデイビーブリオンのステートフルサーキットブレーカーが好きで、アイエンデの怠惰なタイムアウト修正はとてもきれいです。

ただし、例外によってサーキットブレーカの障害数が増加するフィルタリングの実装はあまり見たことがありません。

実装が特に巧妙なロックに依存している場合を除いて、ロックの表示について心配する必要はありません。参考までに、Phil Haackは、DavyBrionの記事で使用されているTimedLockの最新バージョンを持っているようです。

Ayende はDavy Brion のcircuit breakerに修正を投稿し、タイムアウト解決を遅延モデルに変更しました。

ただし、 aが a の最大値をすぐにオーバーフローする可能性があるため、コンストラクターが失敗する可能性があります。たとえば、サーキット ブレーカーのタイムアウトが TimeSpan の最大値である場合です。TimeSpanDateTime

System.ArgumentOutOfRangeException がキャッチされました

Message="加算または減算された値は、表現できない DateTime になります。"

...

System.DateTime.op_Addition (DateTime d、TimeSpan t) で

この問題を回避し、期待される動作を維持するにはどうすればよいでしょうか?

接続が成功するまで、制御できないサービスへのリモート呼び出しを行う方法を探しています。また、アクションが成功するまでn秒/分ごとに実行されるタイマーを単純に設定したくありません。一連の調査の結果、サーキット ブレーカー パターンが最適であることがわかりました。

Castle Windsor インターセプターを使用する実装を見つけました。唯一の問題は、使い方がわからないことです。このトピックに関して見つけたいくつかの記事から、私が見つけることができた唯一の使用例は、サーキットブレーカーを使用してアクションを1回だけ呼び出すことでした。これはあまり役に立ちません。そのことから、サーキットブレーカーをwhile(true)ループで使用してアクションを実行する必要があるようです。

Windsor インターセプターを使用して、サーバーを非難することなく、成功するまで外部サービスを呼び出すアクションを実行するにはどうすればよいですか?

誰か足りない部分を埋めてくれませんか?

これが私が思いついたものです

それに基づいて、この概念とそれを適用する方法を理解したと思います。

大規模な分散システム（AWS上）のサーキットブレーカーデザインパターンを実装しています。

Netflixはここで素晴らしい説明をしています：http：//techblog.netflix.com/2011/12/making-netflix-api-more-resilient.html

バックエンド監視データベースの実装についてアドバイスが必要です。基本的に、次のことができるデータベース/デーモン/サービスが必要です。

1. 1秒あたり数千の書き込みを保存します。
2. 数千のレコードをすばやく合計するか（最後の数秒）、ステータスなどの移動平均計算を維持します（できればキャッシュを使用して）。
3. 2週間分のデータまたはステップ2の計算結果を保存します。

このタスクに適した既存のデータベースまたは他のソフトウェアはありますか？Netflixが私に彼らのものを与えるとは思えません;）

現在、Ask パターンを使用してリクエストをディスパッチするコードがあります。ディスパッチされたリクエストは、HTTP リクエストを送信してレスポンスを返す Akka アクターを生成します。Akka のサーキット ブレーカー API を使用して、呼び出す上流の Web サービスの問題を管理しています。

サーキット ブレーカーが開いた状態の場合、後続のすべての要求はすぐに失敗します。これは望ましい結果です。ただし、アクターがすぐに失敗すると、CircuitBreakerOpenException がスローされ、アクターが停止しますが、AskTimeoutException が生成されるまで、最初の要求を行ったコードに制御が戻りません。

これは、リクエストをディスパッチするコードです

これがサーキットブレーカー

このコードブロックが実行され、回路が開いている場合、例外をすばやくスローして失敗しますが、タイムアウトを待たずに未来を処理するコードに制御を戻したいです。

これは可能ですか？

遅い例外に関するこの質問への回答を読んでいたところです。私は、リターン コードの代わりに例外を使用することができ、使用すべきであるという考えに完全に同意します。

ページリクエストごとに数回呼び出されるサードパーティに接続するサービスにサーキットブレーカーを実装しました。障害が発生した場合、これは多くの例外がスローされることを意味します (ログも同様にいっぱいになります)。

これは問題になるでしょうか？