Redis Keyspace通知 - 订阅者与争用的数量

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）订阅所有＆＃34;已过期＆＃34;事件

psubscribe '__keyevent@*:expired'

优点：

• 只有1位订阅者。

缺点：

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

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

psubscribe '__keyspace@*:mykey'

优点：

• 将为仅包含标签的商品创建订阅。

缺点：

• 必须有与每个订户相关的开销。
• 根据号码，订户数量可以快速增长 商店中标记的商品。

问题：

1. 我应该实施哪个选项？我应该关心 2）上的订户数量或者争论1）更大 应对？我无法找到有关此主题的任何建议。
2. 最终游戏是在Redis Cluster上实现这一点。这会增加吗？ 任何额外关注的实施？

更新1：

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

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

更新2：

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

另一个选项可以是@thepirat000建议的选项。我将此答案标记为已接受的答案，但我也在他的建议中添加了一些调整：我不想在每个标签操作中对标签进行维护，而是我可以随机确定什么时候做这是一个很好的方法，它不使用pub / sub和键空间通知。

Answer 1

使用Keyspace Notifications可能会产生太多的开销。

为什么不将清理作为计划任务或重复任务执行，或者甚至在通过标记检索密钥时？

我在CachingFramework.Redis上做了类似的事情，在检索与标签相关的密钥时，可选择运行清理。标签集TTL也是它包含的密钥的MAX（TTL）。