問題タブ [consensus]

私はfile1最初の操作の結果として、次の構造を持っています

異なる操作の結果でありfile2、同じタイプの構造を持っています。

ファイル 2 のサンプル

file1 (0.8)のしきい値よりも高いフィールド 3 の値を持つフィールド 1 と 2 を選択し、フィールド 1 と 2 のこれらの選択された値に対して、フィールド 3 の値が別のしきい値よりも高い値を選択したいと思います。ファイル 2 (abs(x)=0.4)。

ファイル 1 と 2 の構造は同じですが、フィールド 1 と 2 の値は同じではありません(同じ行数ではないなど)。

でこれを行うことができますawkか？

必要な出力 101 34

fasta 形式のアラインメント シーケンスのセットがあります。アラインメントからコンセンサスを得たい。ほとんどのサイトの場合、ベースの 1 つが最大の発生を示しています。2 つ以上の塩基が同数出現するサイトの場合、どの塩基を使用するか。以下に例を示します。

慣習によると、これはコンセンサスになります

しかし、このコンセンサス シーケンスの出力は、他のシーケンスと整列するとエラーになります。では、そのようなシナリオでは何をすべきで、そのようなサイトのコンセンサスを得るにはどうすればよいでしょうか?

Paxos made simpleでは、ランポートはアルゴリズムのフェーズ 2 (a) を次のように説明しています。

プロポーザーがその準備要求 (番号 n) に対する応答を多数のアクセプターから受信した場合、値 v を持つ番号 n のプロポーザルを求めるアクセプターのそれぞれに受け入れ要求を送信します。ここで、v は最高値です。回答中の番号付きの提案、または回答が提案を報告しなかった場合は任意の値です。

• これは、提案者は、提案番号に関係なく、受諾者の過半数から応答を集めたらすぐに受諾要求を送信できることを意味しますか? (引用の強調された部分は、そのことを暗示していると思います。なぜなら、同じ番号の提案はすべて同じ値を持つべきだからですよね?)
• それとも、提案者は、多数の承認者から同じ提案番号で応答する必要がありますか? (つまり、番号m ( nより小さい) の応答は、番号nの応答の過半数にはカウントされません)

raft コンセンサス アルゴリズムは、 MongoDB がプライマリを選択する際に他の要因 (優先度など) を考慮に入れるという事実以外に、MongoDB のプライマリ選択プロセスとどのように異なるのですか?

paxosアルゴリズムでは、wikiに説明があります：

フェーズ 2a: 要求を受け入れる

プロポーザーがアクセプターのクォーラムから十分なプロミスを受け取った場合、そのプロポーザルに値を設定する必要があります。いずれかのアクセプタが以前に提案を受け入れた場合、その値が提案者に送信されます。提案者は、その提案の値を、アクセプタによって報告された最大の提案番号に関連付けられた値に設定する必要があります。この時点までにどの Acceptor も提案を受け入れていない場合、Proposer はその提案に任意の値を選択できます。[17] Proposer は、Accept Request メッセージを、その提案に選択した値とともに、Acceptor の Quorum に送信します。

プロポーザーが Propose(4) を 5 つのアクセプターに送信し、Ack(abc, 2)、Ack(abc, 2)、Ack(xyz, 3) を受信したとします。Accept(xyz, 4) を送信する必要があります。

私の質問は:

1. 提案者が最後に Accept(xyz,4) を送信する必要がある場合、提案者が独自の値を使用して承認要求を送信するとき。受け入れる(qwe,n)?

2. Ack(xyz,3) を送信するアクセプタは、新しいアクセプトを確認したときに何をしますか?またその理由は?

ありがとう

いくつかの記事を読んで混乱しました。

意見 1: 2PC は非常に効率的であり、最小限の数のメッセージが交換され、待ち時間が短い。出典: http://highscalability.com/paper-consensus-protocols-two-phase-commit

意見 2: 分散トランザクションを高レベルにスケーリングすることは非常に難しく、さらにスループットが低下します。2PC保証のACIDとして 複雑な協調アルゴリズムのため負担が大きい。出典: http://ivoroshilin.com/2014/03/18/distributed-transactions-and-scalability-issues-in-large-scale-distributed-systems/

意見 3: 「一部の作成者は、2 フェーズ コミットがもたらすパフォーマンスや可用性の問題のために、サポートするにはコストがかかりすぎると主張しています。アプリケーション プログラマーは、トランザクションの不足を常にコーディングするよりも、ボトルネックが発生したときにトランザクションの過剰使用によるパフォーマンスの問題に対処する方がよいと考えています。Paxos で 2 フェーズ コミットを実行すると、可用性の問題が軽減されます。」ソース: http://courses.cs.washington.edu/courses/csep552/13sp/lectures/6/spanner.pdf

意見 4: 2PC コーディネーターは、重要なシステムには受け入れられない単一障害点でもあります。私は、2PC コーディネーターがコーディネーターであると信じています。ソース: http://www.addsimplicity.com/adding_simplicity_an_engi/2006/12/2pc_or_not_2pc_.html

最初の 3 つの意見は互いに矛盾しています。4番目が正しいと思います。何が間違っていて何が正しいのかを明確にしてください。それがなぜなのかという事実を与えることも素晴らしいでしょう。

実装 RAFT について次の質問があります。

次のシナリオ\実装を検討してください。

1. RAFT リーダーはコマンド エントリを受信し、エントリをメモリ内配列に追加します。次に、エントリをフォロワーに送信します (ハートビートを使用)。
2. フォロワーはエントリを受信し、それをメモリ内配列に追加してから、エントリを受信したという応答を送信します。
3. 次に、リーダーはエントリを永続的なストア (ファイル) に書き込むことでコミットします。リーダーは最新のコミット インデックスをハートビートで送信します。
4. 次にフォロワーは、エントリを永続ストア (ファイル) に保存することにより、リーダーのコミット インデックスに基づいてエントリをコミットします。

RAFT の実装の 1 つ (リンク: https://github.com/peterbourgon/raft/ ) は、このように実装しているようです。これでいいのか確認したかった。

エントリがコミットされるまで、リーダーとフォロワーによって「メモリ内」に維持されていても問題ありませんか? このシナリオはどのような状況で失敗する可能性がありますか?

以下の質問は、軽薄ではなく真剣であることを意図しています。分散システムの経験はありませんが、基本的な Paxos がどのように機能するか、およびリーダーの選択が役立つ理由は理解しています。残念ながら、私の理解は、以下の質問を理解するのに十分ではありません.

論文Consensus on Transaction Commitの 8 ページ (リンクされた PDF の 11 ページ) には、次のステートメントがあります。

一意のリーダーを選択することは、コンセンサス問題を解決することと同じです。

この声明が真実であり、コンセンサスを達成することが Paxos のまさに目的である場合、なぜ Paxos 自体が一般的にリーダー選挙に使用されないのでしょうか?

さらに、同じ論文は、Stable Leader Election論文で説明されているリーダー選出アルゴリズムを支持しています。

2 つの問題が同等であり、同じ論文が別のリーダー選出アルゴリズムを支持している場合、Paxos の代わりに一般的なコンセンサス問題を解決するために他のアルゴリズムを使用しないのはなぜですか?

紙が言うように：

選挙の安全性: 任期中に選出できるリーダーは最大 1 人です。§5.2

ただし、システムには複数のリーダーが存在する場合があります。Raft が約束できるのは、与えられたタームに 1 人のリーダーしかいないということだけです。では、複数のクライアントを持っている場合、異なるデータが得られるのではないでしょうか? これにより、Raft がコンセンサス アルゴリズムになるにはどうすればよいでしょうか?

ここで私が理解できないこと、誰かが説明できることはありますか?