☰

RPCセマンティクスの目的は正確には何ですか？質問する

tag-icon • tag-icon networking rpc semantics
RPCセマンティクスの目的は正確には何ですか？質問する

RPC セマンティクス、少なくとも 1 回、最大で 1 回のセマンティクスを調べていたのですが、これらはどのように機能するのでしょうか?

実装の概念を理解できませんでした。

ベストアンサー1

どちらの場合も、目標は関数を 1 回呼び出すことです。ただし、違いは失敗モードにあります。「少なくとも 1 回」の場合、システムは関数が正常に呼び出されたことがわかるまで失敗時に再試行しますが、「最大 1 回」の場合は再試行しません (または再試行する前に呼び出しの否定応答があることを確認します)。

これらがどのように実装されるかはさまざまですが、疑似コードは次のようになります。

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 回請求することは避けたいでしょう)。一方、「少なくとも 1 回」の例としては、特定の値でデータベースを更新する場合などがあります (同じ値をデータベースに 2 回続けて書き込んでも、実際には何も影響しません)。変更しない (つまりべき等) 操作には、ほとんどの場合「少なくとも 1 回」を使用します。対照的に、変更操作のほとんど (または少なくとも、状態を段階的に変更し、変更を適用するときに現在の状態または以前の状態に依存する操作) には「最大 1 回」が必要になります。

付け加えておきますが、RPC 本体に一意に識別する識別子を含め、サーバー上でシステムが認識する各 ID が 1 回だけ処理されるようにすることで、「少なくとも 1 回」のシステムの上に「最大 1 回」のセマンティクスを実装することはかなり一般的です。TCP パケットのシーケンス番号 (パケットが 1 回、順番に配信されることを保証する) は、このパターンの特殊なケースと考えることができます。ただし、このアプローチは、同じ RPC の再試行が同じサーバー ソフトウェアを実行している 2 台の別々のコンピューターに到達する可能性がある分散システムで正しく実装するのがやや難しい場合があります。(これに対処する 1 つの手法は、RPC が受信されたトランザクションを記録し、その後、集中システムを使用してこれらのレコードを集約して重複を排除してから、システム内で要求を再配布してさらに処理することです。別の手法は、RPC を日和見的に処理しますが、サーバー間の同期で最終的にこの重複が検出されたときに状態を調整/復元/ロールバックすることです...このアプローチは支払いにはおそらく適さないでしょうが、フォーラムの投稿などの他の状況では役立ちます)。

おすすめ記事