rpc セマンティクス、少なくとも 1 回と最大 1 回のセマンティクスについて調べていましたが、どのように機能しますか?
それらの実装の概念を理解できませんでした。
rpc セマンティクス、少なくとも 1 回と最大 1 回のセマンティクスについて調べていましたが、どのように機能しますか?
それらの実装の概念を理解できませんでした。
どちらの場合も、目的は関数を 1 回呼び出すことです。ただし、違いは障害モードにあります。「at-least-once」では、システムは関数が正常に呼び出されたことを認識するまで失敗時に再試行しますが、「at-most-once」では再試行を試みません (または、関数の否定応答があることを確認します)。再試行する前の呼び出し)。
これらがどのように実装されるかはさまざまですが、疑似コードは次のようになります。
At least once:
request_received = false
while not request_received:
send RPC
wait for acknowledgement with timeout
if acknowledgment received and acknowledgement.is_successful:
request_received = true
At most once:
request_sent = false
while not request_sent:
send RPC
request_sent = true
wait for acknowledgement with timeout
if acknowledgment received and not acknowledgement.is_successful:
request_sent = false
「最大 1 回」を実行したい例としては、支払いのようなものがあります (誰かのクレジット カードに誤って 2 回請求したくない場合)。特定の値でデータベースを更新するようなものです (データベースに同じ値を 2 回続けて書き込んでも、実際には何の影響もありません)。ほとんどの場合、非変更 (冪等) 操作には「少なくとも 1 回」を使用します。対照的に、ほとんどの変更操作 (または少なくとも状態を段階的に変更するため、変更を適用するときに現在/前の状態に依存する操作) では、「最大 1 回」が必要です。
「少なくとも 1 回」のシステムの上に「最大で 1 回」のセマンティクスを実装することはかなり一般的であることを付け加えておく必要があります。システムによって一度だけ処理されます。TCP パケットのシーケンス番号 (パケットが 1 回だけ順番に配信されることを保証する) は、このパターンの特殊なケースと考えることができます。ただし、このアプローチは、同じ RPC の再試行が同じサーバー ソフトウェアを実行している 2 台の別々のコンピューターに到達する可能性がある分散システムに正しく実装するのがやや難しい場合があります。(これに対処する 1 つの手法は、RPC を受信したトランザクションを記録することです。ただし、その後の処理のためにシステム内でリクエストを再配布する前に、集中型システムを使用してこれらのレコードを集約および重複排除します。別の手法は、RPC を日和見的に処理することですが、サーバー間の同期が最終的にこの重複を検出したときに状態を調整/復元/ロールバックすることです...このアプローチはおそらく支払いには向かないでしょうが、フォーラムの投稿などの他の状況では役立ちます) .