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

活動方向很棒！

無論您使用的是 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中文網其他相關文章！