За 11 часов рассмотрели подобный вариант, для того чтобы можно было сбросить кэш пользователя из-за изменения рамки администратором. Кажется максимально правильным, но сомнения огромные:
Когда user:user_id попадает в Redis - делаем запись в:
frames:at_user:
user_id - отдельно сохранённый ID рамки пользователя.
frames:at_users:
frame_id - SET список с ID пользователей, у которых эта рамка есть.
Когда user:
user_id удаляется из Redis (del / expired), смотрим - существует ли frames:at_user:
user_id. Если существует, то удаляем и его, и удаляем ID пользователя из SET-а frames:at_users:
frame_id.
Итог:
При любом обновлении рамки, мы уже можем узнать у каких user-ов она есть (из тех кто в кэше) по SET-у frames:at_users:
frame_id и зачистить его параллельно кэшу каждого юзера.
----------------
Кажется что это максимально правильный вариант на тот момент, когда администратор обновит изображение рамки. Есть возможность составить точный список ключей, которые надо очистить. И это число не превысит кол-во юзеров в кэше.
Но тогда мы будем постоянно генерировать и оперировать кучей данных, которые возможно не пригодятся месяц или два. Администратор может играться с рамками по 50 раз на дню, а может забыть про них на месяцы.
Описанное после разделителя - скорее философский вопрос. И ко всему, это не решает изначальный затык с тем, что обновление рамки по итогу должно привести к инвалидации кэша выборки тикетов.
---------------
UPDATE
В целом, поковыряв ещё немного, решение в этом комментарии можно заменить используя RedisJSON и RediSearch. Накинуть индексы на поля пользователя, и потом вытянуть те ключи - которые нужно дропнуть.
FT.CREATE idx:user
ON JSON PREFIX
1 "users:id:"
SCHEMA
$.frame.id AS frame_id NUMERIC
FT.SEARCH idx:user "@frame_id:[13 13]"
В данный момент предполагаю что это решение можно применить для всей проблемы.
Простой
Простой
Простой