Multi-Paxosアルゴリズムでは、アクセプターの観点からこのメッセージフローを検討します。
受信：準備（N）
返信：Promise（N、null）
受信：受け入れる！（N、V1）
返信：承認済み（N、V1）
受信：承認！（N + 1、V2）
返事： ？
プロトコルによると、この場合、アクセプターの反応はどうあるべきですか？Accepted（N + 1、V2）で応答する必要がありますか、それとも2番目のAccept！を無視する必要がありますか？
このケースは、2番目の提案者がオンラインになり、彼がリーダーである（そして常にそうであった）と信じているときにMulti-Paxosで発生する可能性があると思います。したがって、彼は準備せずにAcceptを送信します。または、彼の準備が単にアクセプターに到達しなかった場合。このケースが発生しない可能性がある場合、その理由を説明できますか？
私は他の両方の答えに同意しません。
Multi-Paxosは、リーダーが唯一の提案者であるとは言っていません。これにより、システムに単一障害点が発生します。ネットワークパーティション中であっても、システムが進行できない場合があります。Multi-Paxosは、単一のノード（リーダー）がいくつかの準備フェーズをスキップできるようにする最適化です。他のノードは、リーダーが死んでいると考えて、彼女に代わってインスタンスを続行しようとする場合がありますが、それでも完全なBasic-Paxosプロトコルを使用する必要があります。
受け入れメッセージを削除すると、Paxosアルゴリズムに違反します。アクセプターは、受け入れないことを約束していない限り、すべての値を受け入れる必要があります。（無視することは許可されていますが、お勧めしません。ドロップされたメッセージが許可されているからです。）
これにはエレガントな解決策もあります。問題はリーダーのラウンド数（質問のN + 1）にあります。
ここにいくつかの仮定があります：
これらの仮定により、解決策は非常に簡単です。リーダーは、最初の承認フェーズで非常に低いラウンドIDを選択するだけです。このID（私はこれをINITIAL_ROUND_IDと呼びます）は、すべてのノードのラウンドIDよりも小さい限り、何でもかまいません。id選択スキームに応じて、-1、0、またはInteger.MIN_VALUEのいずれかが機能します。
別のノード（私は彼をスチュワートと呼びます）が何かを提案するために完全なPaxosプロトコルを通過する必要があり、彼のラウンドIDは常にINITIAL_ROUND_IDより大きいため、これは機能します。考慮すべき2つのケースがあります。リーダーの承認メッセージがスチュワートの準備メッセージが到達したノードのいずれかに到達したかどうかです。
リーダーの承認フェーズがどのノードにも到達していない場合、スチュワートはどのPromiseでも値を取り戻さず、通常のBasic-Paxosと同じように続行できます。
そして、リーダーの承認フェーズがノードに到達すると、スチュワートは、Basic-Paxosの場合と同様に、アルゴリズムを続行するために使用するpromiseの値を返します。
いずれの場合も、スチュワートのラウンドIDはINITIAL_ROUND_IDより大きいため、ノードがリーダーから受信する遅いAcceptメッセージは、常にNackになります。
アクセプターにもスチュワートにも特別なロジックはありません。そして、リーダーの最小限の特別なロジック（Viz。本当に低いINITIAL_ROUND_IDを選択します）。
OPの質問を1文字変更すると、OPの自己回答は正しいことに注意してください：Nack。
しかし、現状では、彼の答えはPaxosアルゴリズムを破っています。それは受け入れるべきです！
Multi-Paxosの正確さは、リーダー（つまり、提案者）が連続するPaxosインスタンス間で変更されないという要件を条件としています。非常勤議会セクション3.1（複数政令議会の議定書）から：
論理的には、議会プロトコル[別名Multi-Paxos]は、法令番号ごとに完全なSynodプロトコル[別名Paxos]の個別のインスタンスを使用していました。ただし、 これらすべてのインスタンスに対して1人の大統領[別名提案者/リーダー]が選ばれ、彼はプロトコルの最初の2つのステップを1回だけ実行しました。
[追加された強調は私のものです。]
したがって、Multi-Paxosは、2番目の提案者がオンラインになり、彼がリーダーである（そして常にそうであった）と信じている場合、あなたが説明するケースは決して起こらないと想定しています。このような場合は、Multi-Paxosを使用しないでください。2番目の可能性（2番目の提案者Prepareがアクセプターに到達しなかった場合）に関して、2番目の提案者がすでに送信したという事実は、Accept!以前にアクセプターの定足数によるものを送信したPrepareことを意味します。Promisedアクセプターはラウンドで最初の提案者にすでに約束しているのでN、2番目の提案者Prepareはラウンドの前に送信されている必要がありますN。したがって、ファイナルAccept!(N+1,V2)のカウンターは。未満で Nある必要があります。
編集：このバージョンのプロトコルはビザンチン障害に対してロバストではないことにも注意する必要があります：
[パクソン議会の議定書]は、恣意的で悪意のある失敗を容認せず、制限された時間の応答を保証しません。
— <em>パートタイム議会、セクション4.1
おそらく、より簡単な答えは、Prepare（N + 1）コマンドが、問題のアクセプターを含まない多数派によって受け入れられた場合であることに注意することです。
詳細：リーダーは、一部の過半数がPromised（N + 1）であることを知ると、Accept（N + 1、x）をすべてのアクセプターに送信します。他の過半数のアクセプターがAccepted（N + 1）で応答した場合でも、コンセンサスに達しました。
これはそれほど珍しいシナリオではありません。
（私自身の質問に答えます。）
私の現在の理解では、N + 1の値を受け入れるべきではない（つまり、まったく応答しない、またはNACKを送信しない）ため、リーダーは準備で別のラウンドを開始する必要があります（大多数がまだコンセンサスに達していない場合） 。Prepare（N + 2）を受け取ったら、Promise（N + 2、V1）で返信し、通常どおり続行します。