Eventorientierung ist großartig!
Ob Sie GCP Pub/Sub, Kafka, Kinesis, RabbitMQ, NATS JetStream, Redis Pub/Sub oder eine der unzähligen Alternativen verwenden, die Muster, die Sie lernen, gelten für sie alle.
Selbst wenn Sie die genau-einmalige Zustellung genießen, werden Sie immer noch ähnliche Ereignisse erhalten, auf die Sie nicht wirklich mehrmals reagieren möchten.
Ein gutes Beispiel hierfür sind umsetzbare Warnungen. Wenn etwas zum ersten Mal ein Problem bemerkt, ist es großartig, es zu eskalieren, um jemanden darauf aufmerksam zu machen, dass eine Aktion erforderlich ist. Das 700. Mal ist nur Lärm.
Wenn Sie ein Ereignis senden, haben Sie Felder (sei es JSON/protobuf/struct was auch immer), und Sie müssen nur identifizieren, nach welchen Feldern Dinge gruppiert werden sollen, um sie für Ihren Zeitraum in denselben Bucket zu sortieren.
Sie können einen Hash eines beliebigen Satzes dieser Ereignisfelder nehmen und daraus einen Hash berechnen, der der Schlüssel zu einer Persistenzquelle (Schlüsselwertspeicher, SQL, was auch immer) ist. Zum Beispiel in Go: https://go. dev/play/p/Ain8FIJiDit
Dann speichern Sie diesen Hash mit einem Ablaufzeitstempel und. Wenn Sie vor dem Ablaufzeitstempel auf weitere „ähnliche“ Ereignisse stoßen, ignorieren Sie diese, da sie bereits jemandem zur Kenntnis gebracht wurden.
Bei der Arbeit haben wir mit Schulbezirken zu tun, und sie stellen uns ihre Dienstpläne zur Verfügung, die regelmäßig (abends) synchronisiert werden. Aber manchmal macht ein Mitarbeiter im Schulbezirk einen Fehler, zum Beispiel, indem er versehentlich alle Schüler aus seiner Liste streicht. Hoppla! Wenn das Problem jedoch nicht behoben wurde, müssen wir eigentlich nicht mehr als einmal daran erinnert werden.
Der Bezirk und der Grund, warum wir ihn nicht eintragen konnten, sind die zusammengesetzten eindeutigen Schlüssel.
Immer wenn wir ein JIRA-Ticket einreichen (oder eine Benachrichtigung an Slack senden), berechnen wir zunächst den Hash dieser beiden Schlüssel und prüfen, ob bereits ein passender Hash gesendet wurde, und wenn ja, ob die letzte Benachrichtigung abgelaufen ist (24 Stunden oder so), bevor Sie ein neues senden und das alte ersetzen. So könnte beispielsweise ein Dienstplanfehler für einen Bezirk etwas Generisches haben wie:
v := map[string]any{ "district": "00be2b9c-ef18-4c27-8fa9-087dd5f39f27", "attention": "rosterops", "reason": "roster change exceeds threshold", }
Und Sie würden erst am nächsten Tag erfahren, dass dieser Bezirk nicht wieder in den Kader aufgenommen wird. Wenn jedoch jemand manuell versucht hat, eine Synchronisierung durchzuführen, und in diesem Bezirk ein Fehler anderer Art aufgetreten ist (eine erneute Ausführung ergibt jetzt „Dienst nicht verfügbar“, anstatt den Änderungstoleranzschwellenwert zu überschreiten:
v := map[string]any{ "district": "00be2b9c-ef18-4c27-8fa9-087dd5f39f27", "attention": "rosterops", "reason": "roster provider is unavailable", }
Auch hier können wir einen Hash eines beliebigen Satzes dieser Felder nehmen und daraus ein indiziertes Datenspeicherfeld für eine Alarmentität machen. https://go.dev/play/p/Ain8FIJiDit
Wenn Sie auch ein anderes Feld wie „Status“ beibehalten, können Sie sehen, ob jemand es bereits bearbeitet, und daraus einen netten Aktionspunkt-Tracker für jedes beliebige Alarmsystem machen.
Das obige ist der detaillierte Inhalt vonÄhnliche Ereignisdeduplizierung pro Periode. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!