ゲートウェイでの不適切なマッピングやエイリアシングの問題など、ネットワークが非常に悪いクライアントがあります。何日も問題なく動作することもあれば、データベースに接続できないか、不思議なことに接続が切断されてサービスが失敗することもあります。
プログラム (つまり、サービス) は、回復または再試行するためにどこまで行く必要がありますか? 彼らのネットワーク関係者に正しく動作させるのは合理的ですか、それとも不安定な状態を乗り切るために自分自身を引き受けるべきですか?
ゲートウェイでの不適切なマッピングやエイリアシングの問題など、ネットワークが非常に悪いクライアントがあります。何日も問題なく動作することもあれば、データベースに接続できないか、不思議なことに接続が切断されてサービスが失敗することもあります。
プログラム (つまり、サービス) は、回復または再試行するためにどこまで行く必要がありますか? 彼らのネットワーク関係者に正しく動作させるのは合理的ですか、それとも不安定な状態を乗り切るために自分自身を引き受けるべきですか?
1) はい、彼らのネットワークが機能することを期待するのは合理的です... 購入した車が壊れているとは言いません。
2) とはいえ、防御的にプログラムします。車を作るとき、すべてが完全に滑らかな州間高速道路になるとは期待できません。
より具体的には、システムに再試行メカニズムを組み込むのが好きです。「再試行可能な」ロジックで何かをラップして、再試行回数を指定できるようにします。通常、再試行期間には 2 次バックオフがあります。たとえば、n*n 秒後に 1..n (n は再試行回数) 試行するか、fib(n) を使用して 1,1,2, 3.5 秒の再試行。バックオフは、アップストリーム リソースに不要な負荷がかかるのを防ぐのに役立ちます
設定された回数の再試行の後、重大度に応じて、例外をスローするか (キャッチしてユーザーまたは他のモジュールにエラーを通知できます)、ログに記録できます。