活动方向很棒!
无论您使用的是 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中文网其他相关文章!