イベント配信、冪等性、重複処理
ネットワーク経由でイベントを送信すると、プロデューサーが完全には観察できない可能性のある結果が生じます。タイムアウトは、サーバーがリクエストを受信する前、リクエストの処理中、またはイベントを受け入れた後、応答が呼び出し元に届く前に発生する可能性があります。再試行すると配信が向上しますが、重複行が作成される可能性もあります。
配信ポリシーは、付随的な SDK 設定ではなく、イベント コントラクトの一部として扱います。
すべての論理イベントに安定したアイデンティティを与える
作成する event_id 申請結果が判明したとき。同じ結果を表すネットワーク試行ごとにその識別子を再利用します。再試行ループ内で新しい識別子を生成しないでください。
const eventId = crypto.randomUUID();
const event = {
event_id: eventId,
job_id: job.id,
status: "failed",
error_type: "provider_timeout",
attempt: job.attempt,
};
await sendWithBoundedRetry("job_completed", event);
アン event_id 重複を検出可能にします。それ自体では、ストレージがすべての重複を拒否することを保証するものではありません。ビジネス ワークフローで 1 回限りのエフェクトが必要な場合は、そのエフェクトを所有するシステムでその要件を強制します。 Telemetry は、支払い、権利付与、またはデータベース変更のトランザクション コーディネーターになるのではなく、結果を説明する必要があります。
どの失敗が再試行可能かを決定する
接続エラーなどの一時的な容量とトランスポートの失敗を再試行します。 429, 502, 503、そして 504。尊重する Retry-After 応答がそれを提供するとき。ジッターを伴う指数バックオフを使用し、試行回数と合計経過時間の両方を制限します。
変更されていないものを再試行しないでください 400 リクエスト。無効な JSON、テーブル名、フィールド タイプ、またはスキーマにはプロデューサーの変更が必要です。不足している資格情報または取り消された資格情報を次の後に置き換えます 401;必要なスコープのキーを使用してください 403.
の レート制限と API エラーのリファレンス 応答クラスと再試行ルールが含まれます。
デフォルトでテレメトリをクリティカル パスから遠ざける
通常の製品および運用分析の場合、一時的なテレメトリの失敗によって、成功した顧客リクエストがエラーになることはありません。テレメトリのタイムアウトを制限し、安全な診断カテゴリを報告し、製品の障害ポリシーに従って続行します。
一部のワークフローでは、より強力な配信が必要です。
- 請求調整に役立つ使用記録。
- 承認されたコントロールに必要なセキュリティ監査イベント。
- 他に真実の情報源がない、取り返しのつかないビジネス結果。
このような場合は、ビジネス変更と同じトランザクションで、永続的なアプリケーション所有の送信ボックスに結果を書き込みます。ワーカーは元のイベントを保持したまま、後でイベントを配信できます。 event_id、発生時刻、スキーマのバージョン。
重複配信と欠落配信を測定する
を使用します。 重複したイベント ID SQL レシピ 複数の行が保存されている識別子を検索します。重複をプロデューサー、リリース、および再試行の理由ごとに分類して、修正のターゲットが実際の配信パスになるようにします。
以下も監視します:
- プロデューサーごとに受け入れられたイベントと拒否されたイベントの数。
- 最も古い未配信の送信トレイ レコードの経過時間。
- 論理イベントごとの試行。
- 再試行バジェットを過ぎると永続的な失敗が発生します。
- 間の遅延
occurred_atそしてtimestamp_utc.
すべてのクエリを重複排除すると、壊れたプロデューサーが隠れてしまう可能性があります。 下流レポートが1件につき1行だけを選ぶ場合でも、重複率の監視は残してください: event_id.
曖昧なケースをテストする
成功、明確な拒否、配信前の接続失敗、およびサーバーがイベントを受け入れた後のタイムアウトを実行します。再試行でイベント ID が再利用され、アプリケーションの応答が文書化された失敗ポリシーに従っていることを確認します。
続けて イベント取り込みのトラブルシューティング, スキーマの進化、そして テレメトリのコスト管理.