每个周期的类似事件重复数据删除

活动方向很棒！

无论您使用的是 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中文网其他相关文章！