Уведомления 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, чтобы предотвратить истекшие ключи, чтобы остаться на моем теге наборы навсегда (даже тогда, когда каждый элемент в кэше имеет набор ТТЛ по умолчанию, я не например, для хранения устаревших данных).

Эти варианты я рассматривающие:

1) Подписаться на все "истекло" события.

psubscribe '__keyevent@*:expired' 

За:

• только один абонент.

Минусов:

• Поскольку не все элементы содержат тег, я должен буду проверить MyKey: теги и если существует получить тег и удалить элемент из каждого набора тегов.
• Конкуренция по этому методу будет увеличиваться с количеством ключей в магазине.

2) Подписаться на все мероприятия для тех ключей, содержащих только теги.

psubscribe '__keyspace@*:mykey' 

Плюсов:

• Подписка будет создана для этих элементов только с тегами.

Против:

• Там должны быть накладные расходы, связанные с каждым абонентом.
• Число абонентов может расти довольно быстро в зависимости от количества помеченных элементов в магазине .

Вопросы:

1. Какой вариант я должен реализовать? Должен ли я беспокоиться о числе подписчиков на 2) или это утверждение на 1) более крупная сделка ? Я не мог найти никаких рекомендаций по этому вопросу.
2. Конечная игра заключается в том, чтобы реализовать это на кластере Редиса. Означает ли это добавление каких-либо дополнительных проблем для реализации?

Update 1:

Это общая реализация для мечения на вершине нашего кэша. На данный момент я не уверен, как мы это использовали.Это больше похоже на PoC, над которым я работаю. Некоторые номера пытается ответить на некоторые вопросы в комментариях:

• Объем: У нас есть десятки миллионов уникальных посетителей в день. Однако не все элементы, хранящиеся в кеше для каждого посетителя, имеют теги. Но это постоянно меняется.
• Теги:: Теги поддерживаются. В настоящее время существует пара десятков тегов. В будущем мы планируем использовать бесплатные текстовые теги.
• Я не тестировал ни один из двух подходов, которые я предлагаю здесь. Я надеялся, что один из вариантов было настолько плохо, что даже не вариант :)

Update 2:

После некоторых проб и ошибок, и еще несколько исследований я отбрасываюсь 2). Существует предел для клиентов redis, а также для выходных буферов, что делает эту опцию «нет». Вы можете найти дополнительную информацию here и here. Я пробовал 1), и он отлично работает. Я даже установил истечение ключей на 5 мс друг от друга, а код обработал его правильно. Это может быть альтернативой.

Другим вариантом может быть предложенный by the the the the_top. Я отмечаю этот ответ как принятый, но я также добавляю небольшую подсказку к его предложению: я не хочу выполнять техобслуживание в тегах при каждой операции с тегами, вместо этого я могу случайным образом определить, когда это сделать. Это достаточно хороший подход, который не использует сообщения pub/sub или keypace.

Answer 1

Возможно, слишком много накладных расходов, используя для этого уведомления о ключах.

Почему вы не выполняете очистку как запланированную или повторяющуюся задачу, или даже когда ключи извлекаются тегом?

Я работал над чем-то похожим на CachingFramework.Redis, где очистка может выполняться при извлечении ключей, связанных с тегом. Также тегом TTL является MAX (TTL) ключей, которые он содержит.