首頁 > 後端開發 > Golang > 主體

每個週期的類似事件重複資料刪除

WBOY
發布: 2024-09-06 22:30:03
原創
815 人瀏覽過

Similar Event De-duplication per Period

活動方向很棒!

無論您使用的是 GCP Pub/Sub、Kafka、Kinesis、RabbitMQ、NATS JetStream、Redis Pub/Sub 或任何無數的替代方案,您學到的模式都適用於它們。

每個週期的相似事件重複資料刪除

即使您享受一次性交付,您仍然會遇到類似的事件,而您並不想多次對其做出反應。

一個很好的例子就是可操作的警報。當第一次發現問題時,最好升級以引起某人的注意,需要採取行動。第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中文網其他相關文章!

來源:dev.to
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板