Redis密钥空间通知-订阅服务器数与争用数

我正在尝试使用Redis实现标记。这就是它的样子：

mykey (my item)
mykey:tags (a set with the tags associated to that item)
tags:tag1 (a set with references to all items tagged with "tag1")
...

我计划使用，以防止过期的密钥永远留在我的标记集上（即使缓存中的每个项都有一个默认的TTL集，我也不喜欢保留过时的数据）

以下是我正在考虑的选项：

1）订阅所有“过期”事件。

psubscribe '__keyevent@*:expired'

psubscribe '__keyspace@*:mykey'

优点：

• 只有1个订户

缺点：

• 由于并非所有项目都包含标记，因此我必须检查mykey:标记 如果存在，则获取标记并从每个标记集中删除该项
• 此方法上的争用将随着密钥数量的增加而增加 在商店里

2）订阅仅包含标签的密钥的所有事件。

psubscribe '__keyevent@*:expired'

psubscribe '__keyspace@*:mykey'

优点：

• 将仅为带有标记的项目创建订阅

缺点：

• 每个订户都必须有相关的开销
• 订阅者的数量可以根据数量快速增长 商店中的标签物品数量

问题：

我应该实施哪个选项？我应该关心这个问题吗 2）上的订户数还是1）上的争用更大 处理我找不到关于这个问题的任何建议

最终的游戏是在Redis集群上实现这一点。这是否增加了 对实施有任何额外的关注吗

更新1:

这是一个在缓存顶部进行标记的通用实现。在这一点上，我不确定我们最终是如何使用它的。这更像是我正在做的PoC。一些数字试图回答评论中的一些问题：

• 数量：我们每天有数千万独立访客。不过，并不是每个访问者缓存中存储的所有项目都有标签。但这是不断变化的
• 标记：管理标记。目前有几十个标签。我们正在考虑将来支持自由文本标签
• 我在这里建议的两种方法我都没有测试过。我希望其中一个选项是如此糟糕，甚至不是一个选项：）

更新2:

经过一些尝试、错误和更多的研究，我放弃了2）。redis客户端和输出缓冲区都有一个限制，这使得此选项无法使用。您可以找到更多信息和信息。 我试过1），效果很好。我甚至将密钥的过期时间设置为相隔5毫秒，代码可以正确处理。这可能是另一种选择

---

另一个选项可以是@thepirat000建议的选项。我将这个答案标记为可接受的答案，但我也对他的建议做了一些调整：我不想在每个标记操作中对标记进行维护，相反，我可以随机决定何时进行维护。这是一种很好的方法，它既不使用pub/sub，也不使用键空间通知。

为此使用键空间通知可能会有太多的开销

为什么不按计划或定期任务进行清理，甚至在通过标记检索密钥时也不进行清理

---

我做过类似的工作，在检索与标记相关的键时，可以选择运行清理。此外，标记集TTL是它包含的密钥的最大值（TTL）。

@RyanVincent你说得对。到目前为止，我所拥有的只是猜测。我希望在我考虑的两个选项之间有一条清晰的道路。使用定期维护任务是我实际找到的一个选项。我不喜欢的是，您必须使用密钥或扫描来循环遍历标记集并删除过期的密钥。我为标记集实现了TTL，正如您所提到的那样；但总有一种可能，旧密钥过期，而新密钥会使设备永远保持活力。。最终你会得到一大堆过期的密钥。我想我很快得出了一个结论，没有检查你的代码。通过传递实际的标签，您不必扫描标签或在标签上键入键。这可能是我可以使用的一个可接受的解决方案。但我不想每次手术都这么做。感谢您的贡献，我们将暂时保持开放状态。