2

Paxos を使用して、サイズが約 50MB で、個々のノードで常に変更されているファイルのノード間のコンセンサスを維持しようとしています。実用性の問題に直面しています。要件:

  1. 数百のノード間で 50MB 以上のファイルを同期
  2. このファイルに変更を加えます。これはどのノードからでも行うことができ、互いに直接競合する可能性は低く、せいぜい数秒でネットワーク全体に伝播されます。
  3. ネットワークに参加する新しいノードは、Paxos メッセージに従って、数分 (1 時間未満) 以内にファイル全体を構築できます。

私が直面している問題は、目標 2 と 3 の両方を達成する方法がないように見えることです。

これまでに検討したオプションは次のとおりです。

  • ラウンドごとにファイル全体を同期する — 完全に非現実的で、Paxos ラウンドには数分かかります
  • ファイルへの変更のみを同期 — 目標 1 と 2 には妥当ですが、新しいノードはすべての状態単位が変更された後にのみファイル全体を同期できるため、目標 3 を破ります。
  • ラウンドごとに変更とファイルのランダムな部分を同期します — Paxos がこれを許可するかどうかはわかりません。ノードは自分自身に対して変更を検証することができ (新しい変更を許可する)、ファイルのランダムな部分をそれらのバージョンのその部分に対して検証することができますが、これは実用的ですか?

私は 3 番目のオプションが最適だと考えていますが、Paxos がこれを許可するかどうかはわかりません。アイデアは、各ラウンドで交換されるデータをおそらく 1500 バイトに制限し、その 1500 バイトを主にファイルへの変更で埋めることです。ほとんどのラウンドでは、ファイルは変更されず、何かが変更されたラウンドは 100 バイト未満の変更された状態である可能性が高いため、他の 1400 バイトはファイルの一部で満たされる可能性があり、これにより新しいノードを構築できます。時間をかけてファイル全体をアップします。これは実用的ですか?この問題はすでに解決されていますか?

4

2 に答える 2

0

ここで説明されているように、paxos を使用してファイルへの書き込みのトランザクション ログを複製できます。空のファイルを持つ新しいサーバーがクラスターに参加すると、最新のノードからスナップショットを要求できます。その間、新しいノードは現在の更新をリッスンしてバッファリングすることもできます。スナップショットが読み込まれ、その後の更新が適用されると、完全に最新の状態になります。

スナップショットは、ファイルの完全なコピーにすることができます。完全なスナップショットを取得すると、書き込みはブロックされますが、読み取りはブロックされません。これは、RAID された SSD ディスク上の 50M ファイルの場合、パフォーマンス オーバーヘッドとしてはそれほど大きくないかもしれません。より効率的なアプローチは、コピー オン ライト セマンティクスを備えた不変 (純粋関数) データ構造としてファイルをモデル化することです。フラット ファイルではなく、ファイル チャンクの永続的なデータ構造としてモデル化できます。例は、不変のソートされたマップですここで、キーはファイル チャンク番号で、値はファイルのチャンクです。ファイルへの書き込みとは、1 つ以上の更新されたチャンクをマップに挿入することを意味します。このようなデータ構造では、すべての書き込み操作が新しい不変マップを返します。新しいマップは、変更されていないファイル チャンクを以前のバージョンのマップと共有します。ファイルのスナップショットは、特定の時点でのマップの不変バージョンです。不変のマップを使用すると、マップ内のすべてのチャンクにアクセスして、ファイル状態の完全なスナップショットを新しいサーバーに送信するためにロックを取得する必要はありません。ログ構造化ストレージは、このような手法を使用します。

于 2015-12-08T23:35:12.510 に答える