Лучший способ создать ключ кеша, уникальность которого определяется 6 свойствами

Question

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

sku

канал

подканал

план

дата

В настоящее время кэш структурирован следующим образом:

product1_channel1_subchannel1:  {sku_1:  {plan1: {2019-03-18: 2000}}}

API обслуживает запросы на несколько продуктов, skus и все вышеперечисленные факторы.Поэтому они решили запросить все данные на уровне product_channel_subchannel и отфильтровать данные в приложении, что очень медленно.Также они решили, что при промахе кеша они построят кеш для всего скуса на 90 дней данных.Таким образом, только один запрос будет встречен гневом, в то время как другие получат выгоду от него (только подвох в том, что мы чаще используем кеш, который также приводит к снижению производительности системы)

Недостаток использования всех этих факторовв ключах будет слишком много ключей.На бал-парк есть 400 продуктов, каждый из которых состоит из 20 скусов с 20 каналами, 200 подканалов, 3 типа планов и 400 дней цен.Чтобы избежать этих многочисленных ключей в каком-то месте, мы должны сгруппировать данные.

Система в настоящее время получает около 10 об / с и должна ответить в течение 100 мс.

Вопрос:

Хорошо ли описанная выше структура кэша?Или как нам сгладить эту структуру?

Как кэши хранятся в системах ценообразования в целом.Я чувствую, что это очень тривиальная задача, тем не менее, мне очень трудно обосновать свои подходы

Можно ли пожертвовать одним запросом, чтобы нагреть кеш для большой части данных?Или лучше иметь стратегию разогрева кеша?

Answer 1

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

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

Можно ли пожертвовать одним запросом, чтобы нагреть кеш для большей части данных? Или лучше иметь стратегию разогрева кеша?

зависит от того, как ваши пользователи будут запрашивать данные и сколько времени займет пропуск кеша. Если запросы, как правило, группируются вокруг определенного скуса или определенных дат предсказуемым образом, то вам следует использовать эту информацию, чтобы помочь направлять попадания и пропуски кэша.

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

Вот несколько рекомендаций, которые я бы порекомендовал при использовании redis для кэширования:

1. Если узким местом является отправка данных из Redis в API, то подумайте об использовании сценариев lua для простой обработки до того, как какие-либо данные покинут Redis. Но будьте осторожны, чтобы не сделать скрипты слишком сложными, так как долго выполняющийся скрипт lua может блокировать все остальные части redis

2. Похоже, вы используете простые ключи get / set для хранения ваших данных. Подумайте об использовании чего-то более сложного:

   а. используйте отсортированные наборы (zsets), если вы хотите иметь лучший доступ к данным по дате (используйте дату в качестве балла). б. используйте хэш-наборы, чтобы получить более детальный доступ к skus

3. Судя по вашему вопросу, похоже, у вас будет около 1,6 млн ключей. Это не очень большое количество, но вам нужно убедиться, что у redis достаточно памяти для хранения всего в оперативной памяти без какой-либо записи на диск. Это то, что нам пришлось выучить трудным путем. Если вы запускаете свой экземпляр Redis в Linux, вы должны установить системную перестановку в 0, чтобы своп никогда не использовался.

Но, самое главное, вам нужно экспериментировать со всем, пока не найдете хорошее решение.