問題タブ [fault-tolerance]

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

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

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

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

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

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

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

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

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

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

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

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

Ruby でリアルタイム データ分析タスクのアルゴリズムを開発しています。データセットが非常に大きいため、ボトルネックは CPU です。したがって、必要なパフォーマンスを達成するには、おそらく別のマシンで、より多くのコアを並行して使用する必要があります。

私の質問は、次の機能を提供する既存の Ruby ライブラリがあるかどうかです。

• クラスター管理、理想的にはマスターレス、動的再構成 (ノードの参加と離脱) およびある程度の耐障害性
• (アクティブな) ノードへの計算ジョブの分散、エラー処理 (ジョブの再試行など)
• リアルタイム機能を確保するための高速 (直接?) 通信

私がすでに見たもの：

• DRb: レベルが低すぎる、手動でノードを処理する、耐障害性がない?
• DCell: 成熟した？自動クラスター管理?
• Resque/Sidekiq: いいけど遅すぎる (Redis のポーリング、ワーカーのスリープ、...)
• Riak Map/Reduce: 便利ですが、リアルタイム クエリにはお勧めしません
• Spark : 複雑なもの、エンタープライズ?

最後の手段: Ruby 以外のプラットフォームでは解決策がないのではないでしょうか? おそらく Java (そう、JRuby!) または node.js です。

分散フォールト トレラント システムを使用して、何百万もの画像を保存したいと考えています。リレーショナル データベースに画像を保存することは決して推奨されていませんが、画像ファイルを NoSQL データベースに保存および管理するのに適切な方法であるかどうか疑問に思っていました。

ここであなたの経験を詳細に共有していただければ幸いです。（つまり、どのNoSQLデータベースを使用しましたか？この場合の長所と短所など）

ありがとう

背景:

Lamport の論文Paxos Made SimpleのImplementing a State Machineという名前のセクション 3 では、Multi-Paxos が説明されています。Multi-Paxos は Google Paxos Made Liveで使用されます。( Multi-Paxos はApache ZooKeeperで使用されます)。Multi-Paxos では、ギャップが発生する可能性があります。

一般に、リーダーは先にコマンドを取得できると仮定します。つまり、コマンド 1 からコマンドが選択された後、コマンドを通じてコマンドαを提案できます。コマンドまでのギャップが発生する可能性があります。i + 1i + αiα - 1

ここで、次のシナリオを検討してください。

システム全体がマスタースレーブアーキテクチャを使用しています。マスターだけがクライアント コマンドを提供します。マスターとスレーブは、Multi-Paxos を介して一連のコマンドについて合意に達します。マスターは Multi-Paxos インスタンスのリーダーです。ここで、マスターとその 2 つのスレーブが次の図に示す状態 (コマンドが選択されている) であると仮定します。

.

マスター状態には複数のギャップがあることに注意してください。非同期性のため、2 つのスレーブは遅れます。この時点で、マスターは失敗します。

問題：

1. マスターの障害を (たとえば、ハートビート メカニズムによって) 検出した後、スレーブは何をすべきか?

2. 特に旧マスターとのズレや不足しているコマンドをどう扱うか。

ザブについての更新:

@sbridges が指摘したように、ZooKeeperは Paxosの代わりにZabを使用します。引用すると、

Zab は主に、ステート マシンの複製用ではなく、ZooKeeper などのプライマリ バックアップ (マスター スレーブ) システム向けに設計されています。

Zab は上記の私の問題と密接に関係しているようです。Zab の簡単な概要論文によると、Zab プロトコルは 2 つのモードで構成されています。リカバリとブロードキャストです。回復モードでは、コミットされたメッセージを決して忘れないことと、スキップされたメッセージを手放すことの2 つの特定の保証が行われます。ザブについての私の混乱は次のとおりです。

3. リカバリ モードでは、Zab もギャップの問題に悩まされますか? もしそうなら、ザブは何をしますか？

JobDetail.requestsRecoveryプロパティのドキュメントには、次のように記載されています

「リカバリ」または「フェイルオーバー」状況が発生した場合に、ジョブを再実行するかどうかをスケジューラに指示します。

では、「リカバリ」状況または「フェイルオーバー」状況とは何ですか?

それらはどう違いますか？

回復は、ジョブの実行中に JVM がクラッシュした場合にのみ行われますか?それとも、例外が原因でジョブの実行が失敗した場合にも発生しますか?