活動方向很棒!
無論您使用的是 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中文網其他相關文章!