したがって、前述のメッセージ フローで 1 つのメッセージが失われたことが、トランザクションが失敗するか、黙って破棄されることを意味する場合、この状況では、すべてのボイラープレートで at-least-once 配信を EVERYWHERE で使用することを実装に強制するのでしょうか? これにより、コード ベースの保守がややこしくなるのではないでしょうか? コードの保守性と全体的なシステム パフォーマンスのバランスの観点から、この種の状況を効率的に処理するにはどうすればよいでしょうか。安全な方法で少なくとも 1 回の配信の使用を一般的に最小限に抑える方法は?<
あなたは決してこれをしません。銀行システムでは、俳優を見つけることはほとんどありません。銀行システムでは、各取引が確実に行われるようにするために、2 つまたは 3 つのレベルの実装があります。
少なくとも1回のアプローチと最大1回のアプローチは、基本的にタイムアウトとメッセージについての考え方の違いです。せいぜい 1 つがスループットを最大化しようとしています (何かがうまくいかない場合、低レベルで開始するタイムアウトがあります)。
少なくとも 1 回は別のルートを使用します (基になる実装によって異なります)。ここでは、応答時間を短縮することを目指します。優先的に 3 つのサーバーに送信し、最速の応答を取得する可能性がはるかに高くなります。
請求サービスと検索サービスについて考えてみてください。請求サービスでは、応答時間をそれほど気にせず、請求が一度だけ行われるようにしたいと考えています。そのため、別のノードに引き継いで請求を行うように依頼する前に、プロセスを終了させたいと考えています。検索サービスの場合、応答時間を短縮する必要があります。したがって、たとえば 3 つのサーバーに検索要求を送信すると、これらのサーバーは並行して検索し、任意の (!) サーバーから報告された最初の結果を取得します。
それが理由です。少なくとも 1 回、多くても 1 回は、正しさと応答についてです。（少なくともそれが私たちがそれを学んだ方法です）。
[アップデート]
実際のパフォーマンスを測定し、サーバーの応答が 25 ミリ秒以内に 75%、75 ミリ秒以内に 95% であることがわかった場合、少なくとも 1 回の実装では 25 ミリ秒待機し、リクエストを別のサーバーに送信して、さらに 50 ミリ秒待機します。 3 番目の要求を送信します。したがって、これを使用すると、予想される応答時間を 75% 25 ミリ秒、95% から 50 ミリ秒、99% から 75 ミリ秒に短縮するために 30% (単なる推測) を追加するだけです (理想的な世界では、各要求は同じ計算時間を必要とし、処理時間はアーキテクチャに依存する (または単一ノードに依存する) ものであり、ネットワークに依存するものではありません (高負荷時など)。