기간별 유사 이벤트 중복 제거

이벤트 오리엔테이션이 너무 좋아요!

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에 알림을 보낼 때마다) 먼저 두 키의 해시를 계산하고 일치하는 해시가 이미 전송되었는지 확인하고, 그렇다면 마지막 알림이 만료되었는지 확인합니다(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 중국어 웹사이트의 기타 관련 기사를 참조하세요!