Уведомления Redis Keyspace — количество подписчиков и конкуренция

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

Вот такие варианты я рассматриваю:

1) Подпишитесь на все события с истекшим сроком действия.

psubscribe '__keyevent@*:expired'

Плюсы:

  • Всего 1 подписчик.

Минусы:

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

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

psubscribe '__keyspace@*:mykey'

Плюсы:

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

Минусы:

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

Вопросы:

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

Обновление 1:

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

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

Обновление 2:

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

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


redis redis-cluster stackexchange.redis
person Raciel R.    schedule 14.03.2016    source источник
comment
@RyanVincent, ты прав. Все, что у меня есть до сих пор, это предположения. Надеялся, что между двумя вариантами, которые я рассматриваю, есть четкий путь.   -  person Raciel R.    schedule 14.03.2016

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

person thepirat000    schedule 14.03.2016
comment
Использование повторяющейся задачи обслуживания было вариантом, который я нашел здесь. Что мне не нравится в этом, так это тот факт, что вы используете KEYS или SCAN для циклического просмотра наборов тегов и удаления ключей с истекшим сроком действия. Я реализовал TTL для набора тегов точно так, как вы упомянули; но всегда есть шанс, что срок действия старого ключа истечет, а новые ключи оставят набор живым навсегда. В конце концов вы получите массу ключей с истекшим сроком действия. - person Raciel R.; 14.03.2016
comment
Я думаю, что быстро подошел к выводу, фактически не проверив ваш код. Передавая фактические теги, вам не нужно СКАНИРОВАНИЕ или КЛЮЧИ на ваших тегах. Это, вероятно, приемлемое решение, которое я могу использовать. Однако я не хочу делать это при КАЖДОЙ операции. Спасибо за вклад, пока оставлю это открытым. - person Raciel R.; 14.03.2016