Redis 键空间通知 - 订阅者数量与争用

Question

我正在尝试使用 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")
...

我打算使用 Redis Keyspace Notifications以防止过期键永远保留在我的标记集上(即使缓存中的每个项目都设置了默认 TTL，我也不喜欢保留过时的数据)。

这些是我正在考虑的选项:

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

psubscribe '__keyevent@*:expired'

优点:

• 只有 1 个订阅者。

缺点:

• 因为不是所有的项目都包含标签，我将不得不检查 mykey:tags 如果存在，则获取标签并从每个标签集中删除该项目。
• 这个方法的竞争会随着 key 的数量增加而增加 在店里。

2) 订阅那些只包含标签的键的所有事件。

psubscribe '__keyspace@*:mykey'

优点:

• 将为那些只有标签的项目创建订阅。

缺点:

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

问题:

1. 我应该实现哪个选项？我应该担心 2) 上的订户数量或 1) 上的争用更大 交易？我找不到关于这个主题的任何建议。
2. 最终目标是在 Redis 集群上实现它。这是否添加 对实现有任何额外的关注吗？

更新 1:

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

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

更新 2:

经过反复试验和更多研究后，我放弃了 2)。 Redis 客户端和输出缓冲区都有限制，这使得该选项无法使用。您可以找到更多信息here和 here . 我尝试了 1) 并且效果很好。我什至将 key 的到期时间设置为 5 毫秒，并且代码可以正确处理它。这可以作为替代方案。

另一个选项可以是@thepirat000 建议的选项。我将这个答案标记为已接受的答案，但我也对他的建议做了一点调整:我不想在每个标签操作中都对标签进行维护，而是我可以随机确定何时进行维护。这是一种足够好的方法，它既不使用发布/订阅，也不使用键空间通知。

Answer 1

为此使用键空间通知可能会产生太多开销。

为什么不将清理作为计划任务或重复任务，甚至在通过标签检索 key 时进行清理？

我在 CachingFramework.Redis 上做过类似的事情在检索与标签相关的键时，可以选择运行清理。此外，标签集 TTL 是它包含的键的 MAX(TTL)。