非同期の内部通信を処理するためのベストプラクティス？

最近、クレジットカード処理を扱うプロジェクトを完了しました。私が直面した問題の1つは、通知メッセージの遅延/起こりうる失敗の処理でした。最も複雑な例は次のとおりです。

• 支払い要求を送信する外部システム
• 私のシステムはその要求を支払いゲートウェイへの要求に変えます
• ユーザーをゲートウェイに送信する
• ユーザーが支払いを実行するのを待っています
• ユーザーがシステムに戻ったが、システムが成功/失敗の通知を受け取るまで保留される
• 失敗に応じてユーザーを外部システムに送り返す

さらに困難だったのは、通知の送信に失敗すると、ゲートウェイは15分ごとに何時間も通知を送信しようとすることでした。

保留中のトランザクションのデータベースレコードを使用して解決し、リターンからの成功と失敗に加えて、通知とトランザクション処理のための時限遅延リスナーを検出しました...

かなり難しい！

しかし、これは何億回も前に解決されたに違いないので、ベストプラクティスは何ですか？

私の将来は、これらすべてのシステム間の処理を記述し、時間遅延と起こりうるネットワーク障害を管理することになるので、ベストプラクティスに従いたいと思います。

本/記事の推奨事項は素晴らしいでしょう。

前もって感謝します！

分散システムを構築する場合、「同期」システムと「非同期」システムの違いは次のとおりです。同期システムには、計算時間とメッセージ配信時間に既知の上限があります。つまり、特定のイベントにこれらの既知の上限がない非同期システムがあります。それをどのように扱いますか？

1. これらの非同期プロセスに確率的な上限がある場合は、タイムアウトを使用して、システムを部分的に同期したシステムのように動作させることができます。支払いゲートウェイの98パーセンタイル応答時間が5秒の場合、5秒のタイムアウトにより、98％のリクエストが成功し、他の2％は失敗します。これは、このプロセスが成功または失敗するまでにかかる時間の既知の上限があることを意味します。この確率論的障害検出は、非同期システムを同期システムに変えるための重要なツールです。

2. システム障害が発生した場合にシステム状態を回復できるように、これらのイベントの永続的な記録を保管してください。ペイメントゲートウェイハンドラーがこれらのイベントを揮発性メモリに保持しているときにクラッシュすると、失敗します。

3. 各複雑なトランザクションは、本質的に、システム内でのメッセージ（イベント）の送受信に基づく一連の状態変換です。「保留中のトランザクションの記録」を使用してこれを非公式にモデル化しているようですが、さらに進めることをお勧めします。管理する必要があるトランザクションごとに、それを記述する正式な状態マシンを作成し、現在の状態の永続的な記録を保持します。これらのステートマシンは理解しやすく、テストも簡単で、あなたとユーザーの両方にとってこれらのプロセスに必要な可視性を提供します。

システムの非同期性が高まるほど、これらの複雑なイベント状態変換を管理するときに、より正式かつ明示的になる必要があります。ここでは、タイムアウト、永続的なイベントロギング、およびステートマシンがベストプラクティスです。そのため、Erlang OTPは、アプリケーションの動作の多くを、たとえばステートマシンモデルに基づいています。

参考までに、私は信頼できる安全な分散プログラミングの概要より優れたものを見つけていません。同期システムと非同期システムの両方を第一原理から理解するための強力なアルゴリズムの基礎を提供します。