期間ごとの類似イベントの重複除外

イベントオリエンテーションは素晴らしいです!

GCP Pub/Sub、Kafka、Kinesis、RabbitMQ、NATS JetStream、Redis Pub/Sub、または無数の代替手段のいずれを使用しているかに関係なく、学習したパターンはそれらすべてに適用されます。

期間ごとの類似イベントの重複除外

たとえ 1 回限りの配信を楽しんでいたとしても、実際には反応したくない同様のイベントが複数回発生することになります。

この好例は、実用的なアラートです。何かが初めて問題に気づいたときは、アクションが必要であることを誰かに知らせるためにエスカレーションすると効果的です。 700回目なんてただのノイズです

イベントを送信する場合、フィールド (JSON/protobuf/struct など) があり、必要なのは、期間ごとに同じバケットに並べ替えるために、どのフィールドでグループ化するかを特定することだけです。

これらのイベント フィールドの任意のセットのハッシュを取得し、それらのハッシュを計算して、永続化ソース (キー値ストレージ、SQL など) へのキーにすることができます。たとえば、Go では: https://go. dev/play/p/Ain8FIJiDit

次に、そのハッシュを有効期限タイムスタンプとともに保存します。有効期限のタイムスタンプより前に「同様の」イベントが発生した場合は、すでに誰かの注意を引いているため、無視してください。

実際の例

職場では学区とやり取りしており、学区から定期的に (毎晩) 同期される名簿が提供されます。しかし、学区の人間が名簿内の生徒全員を誤って削除してしまうなどの間違いを犯すこともあります。おっと！ただし、問題が解決していない場合は、実際には何度も通知を受け取る必要はありません。

地区、および地区を名簿に登録できなかった理由は、複合一意キーです。

JIRA チケットを提出する (または Slack にアラートを送信する) ときは、まずこれら 2 つのキーのハッシュを計算し、一致するハッシュがすでに送信されているかどうか、送信されている場合は最後のアラートの有効期限が切れているかどうかを確認します (24新しいものを送って古いものと交換する前に、数時間ほど）。したがって、たとえば、地区の名簿の失敗には、次のような一般的なものが含まれる可能性があります。

v := map[string]any{
        "district":  "00be2b9c-ef18-4c27-8fa9-087dd5f39f27",
        "attention": "rosterops",
        "reason": "roster change exceeds threshold",
    }

そして、その地区が再び名簿に登録されなかったということは、翌日になるまで聞かないでしょう。ただし、誰かが手動で同期しようとしたときに、その地区で別の種類の障害が発生した場合 (再実行すると、変更許容しきい値を超える代わりに「サービスが利用不可」になるようになりました:

v := map[string]any{
        "district":      "00be2b9c-ef18-4c27-8fa9-087dd5f39f27",
        "attention": "rosterops",
        "reason": "roster provider is unavailable",
    }

繰り返しになりますが、これらのフィールドの任意のセットのハッシュを取得し、それをアラート エンティティのインデックス付きデータストア フィールドにすることができます。 https://go.dev/play/p/Ain8FIJiDit

追加ボーナス

「ステータス」のような別のフィールドも永続化すると、誰かがすでにそのフィールドを処理しているかどうかを確認でき、任意のアラート システム用の優れたアクション アイテム トラッカーにできます。

以上が期間ごとの類似イベントの重複除外の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。