問題タブ [fault-tolerance]

データ ストアとしての DB と y (>5) 個の他のマシンがあります。x 分ごとにデータ (更新) を持つマシン A があります。y 台のマシンは x 分ごとにマシン A からデータを取得し、データベース内のデータを更新します。同じことを行うすべてのマシンは、ある程度の耐障害性を備えています。フォールト トレランスを使用した作業をモデル化するクリーンな方法はありますか?

任意のポインタをいただければ幸いです。

ピザの配達店向けに、フォールト トレラントなソフト リアルタイム Web アプリケーションを構築したいと考えています。これは、ピザ店が顧客からの電話を受け付け、(CRM Web クライアントを介して) 注文としてシステムに入力し、ディスパッチャーが配達ドライバーを注文に割り当てるのに役立ちます。

これらの目標は特別なことではありませんが、サービスを 24 時間 365 日利用できるようにしたいと考えています。つまり、フォールト トレラントにすることです。さらに、私はそれを非常に速く動作させ、非常に反応が良いようにしたいと思っています.

以下は、そのようなアプリケーションの非常に単純なアーキテクチャ ビューです。

問題は、Erlang/OTP の優れた機能をすべて使用して、アプリケーションの応答性と耐障害性を高める方法がわからないことです。

ここに私の質問があります：

1. フォールト トレランスを提供するために、どのシステム要素を複製する必要がありますか?また、その方法は? 各車両のステータス (座標、割り当てられた命令など) を複製された Mnesia データベースに保存できることを知っています。それは正しい方法ですか？
2. 従来の SQL ベース (例: Boss_dbベース) にする必要があるデータ ストレージ サービスと、非常に高速な応答を提供するために Mnesia で実行する必要があるサービスはどれですか? 従来の SQL データベースを使用して、このようなフォールト トレラントで応答性の高いアプリケーションに顧客の記録と履歴を保存してもよいでしょうか?
3. アプリケーションの応答性を高めるために、すべてのサービス (顧客、車両の状態など) のすべてのデータを RAM に保存する必要がありますか?
4. 永続的な車両データ (ID、容量など) を従来の SQL データベースに保存し、リアルタイム データ (座標、割り当てられた注文、トランク内の注文など) を Mnesia データベースに保存して、アプリケーションをより多く作成する必要がありますか?リアルタイムレスポンシブ?

リアルタイムのドキュメント編集およびチャット アプリケーションの作成を検討しています。しばらくの間、Erlang を学びたいと思っていましたが、これは試してみるのに良いプロジェクトではないかと考えていました。

具体的には、Mongrel や LAMP スタックで実行されている Rails アプリと比べて、Erlang のフォールト トレランスと軽量プロセスの利点をどの時点で認識し始めるでしょうか? 100 人の同時ユーザーでしょうか。1,000? 10万？基本的に、新しい言語を学ぶ価値があるかどうか、または現在のスキル セットで十分かどうかはわかりません。ありがとう！

慎重に作成された Java コードの多くが、java.lang.OutOfMemoryError によって無駄にされています。プロダクションクラスのコードでさえ、それによってダウンしてしまいます。

私が聞きたい質問は、このエラーの発生を回避できる優れたプログラミング/アーキテクチャの実践があるかどうかです。

したがって、Java プログラマーが自由に使えるツールは次のようになります。

1. java.lang.Runtime.addShutdownHook(Thread hook) -- シャットダウン フックにより、正常な終了が可能になります。
2. java.lang.Runtime.freeMemory() -- VM で使用可能なメモリを確認できます

したがって、私が考えたのは、オブジェクトを作成する前に、メモリを割り当てようとする前にシステムに十分なメモリが残っているかどうかをチェックするファクトリ メソッドを記述できるかということです。たとえば、C では、malloc が失敗し、理想的な状況ではなく、メモリー不足であることがわかりますが、単に java.lang.OutOfMemoryError 動脈瘤で死ぬことはありません。

推奨されるアプローチは、より適切なメモリ管理を行うか、メモリ リークを塞ぐか、単にメモリを増やすことです。これらは重要な点であることに同意しますが、次のシナリオを見てみましょう。

1. Amazon マイクロ インスタンスで実行しています
2. VM に割り当てられるメモリはごくわずかで、たとえば 400M です。
3. Java プロセスはマルチスレッド方式でジョブを処理します。各スレッドは、計算タスクのパラメーターに応じてさまざまな量のメモリを消費します。
4. 私のプロセスにメモリリークがないと仮定しましょう
5. ジョブが完了する前にジョブを供給し続けると、最終的にはメモリ不足で死んでしまいます
6. -Xmx を高く設定しすぎると、OS でスワッピングが発生し、スラッシングが発生する可能性があります。
7. 同時実行の上限を設定すると、利用可能なRAMで実行できるジョブの受け入れを制限したり、さらに悪いことに、大量のメモリを必要とするジョブを受け入れたりして、最終的にjava.langにアクセスする可能性があるため、最適ではない可能性があります.OutOfMemoryError とにかく。X.質問の動機を説明するのに役立つことを願っています-標準的な回答は、問題に対するフォールトトレラントなアプローチを求めることと相互に排他的ではないと思います。

前もって感謝します。

私は Akka の初心者ですが、Actors、Agents、Futures など、Akka が提供する非同期プログラミング用の機能の多くを楽しんでいます。

Akka の強力なセールス ポイントは、アクターがクラッシュすると、同等のアクターがアクター システムによって新たに作成され、古いものの代わりにプラグインされるため、強力な安定性が保証されるという事実です。

他のいくつかのシステム (JMS はその 1 つだと言われています) はさらに一歩進んで、アクター間で送信されるメッセージを継続的に永続化します。このようにして、たとえばハードウェア障害が原因でマシンが物理的にクラッシュした場合でも、障害が発生する前の状態に復元することができます。

これは、私が現在開発しているアプリケーションにとって非常に魅力的です。Akka はそのようなメカニズムを提供していますか? そうでない場合、これを実現できるように外部システムと統合する方法はありますか?

下の図で、中央のメッセージ キューが失敗したとします。送信者は、他のメッセージ キューを使用して送信されたメッセージを引き続き取得できます。

しかし、メッセージを受信した後にメッセージ キューが死んだらどうなるでしょうか。送信者は、メッセージが受信者に送信されたかどうかをどのように認識して、別のメッセージ キューで再送信するかどうかを決定しますか?

同様に、メッセージ キューがメッセージを配信した後に受信者が死亡した場合はどうなりますか? 送信者は、意図した要求が受信者によって実行されたかどうかをどのように知ることができますか?

ホスト ファイル内のノードがダウンした場合、MPI を使用して残りのノードを処理する方法

LDAP フォールト トレランス構成 (SunOne など): SunOne LDAP などの LDAP の "フォールト トレランス" を構成する方法を知っている人はいますか。

Google で検索しても有益な結果が得られません。

ありがとう

たまたま Joe Armstrong の論文を読んだだけで、Erlang についての予備知識はあまりありません。あるメッセージの配信確認が届かなかったらどうなるのだろうか。送信側のアクターは何をしますか? メッセージをもう一度送信しますか？これにより、同じメッセージをもう一度受信したときに、受信者のアクターが混乱する可能性があります。そのレシートが受信されなかったことを伝えることができなければならないため、2 番目のメッセージは無効になります。

この種の問題は、メッセージ配信がトランザクションではない解決策から常に遠ざかっていました。私は答えを知っていると思います: 送信側のアクターは、監督側のアクターに、適切な時間内にレシートを取得できなかった場合、何かが間違っているに違いないと伝え、スーパーバイザーに何らかのアクション (関与するアクターの再起動など) を実行させます。これは正しいです？理論的に無限のメッセージ送信が発生しない解決策は他にありません。

答えてくれてありがとう、オリバー

例外を処理するときのベスト プラクティスは何ですか?

私は通常、いかなる犠牲を払っても例外を回避するコードを作成します。通常、私のコードには多くの条件があり、正規化されたデータベースを扱っている場合は、通常、値が既に存在するかどうかを再確認する一連のクエリを作成します。

ただし、例外をリッスンするだけのコードを見たことがあります。例外が発生した場合は、適切に処理されます。

このシナリオでのベスト プラクティスは何ですか?

エラーを回避して発生する前に処理する方が良いですか、それとも単に例外をキャッチして適切な場所に送る方がよいでしょうか?

パフォーマンスに関しては、例外をキャッチする方が速いことがわかりました。特にデータベースが関係している場合。

ただし、一部の例外は特定のシナリオでは一般的すぎると感じており、スタック トレースが表示されない限り、その例外が発生した理由を特定するのは困難です。

とはいえ、エラー報告ツール (ロールバー、新しいレリックなど) を用意していない限り、顧客向けのインターフェイスがあり、「500」という単語のみを含むチケットを受け取った場合、ログでスタック トレースを見つけるのは特に困難Xページのエラー」。

この質問がstackoverflowには広すぎる場合は、お気軽に閉じてください