ASP .NET Core: как кэшировать данные, которые зависят от пользовательского ввода?

Question

Мы создаем новый базовый веб-сервис ASP.Net, который будет предоставлять данные из существующей базы данных.

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

Я нашел это для кэширования в ASP.Net Core: https://docs.microsoft.com/en-us/aspnet/core/performance/caching/memory?view=aspnetcore-2.2 То, что кажется, путь.В статье также говорится: Не используйте внешний ввод в качестве ключей кэша

Моя проблема сейчас заключается в том, что в основном все данные зависят от пользователя или пользовательского ввода.

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

Также есть некоторые общие компоненты, которые разделяют многие пользователи, но какие компоненты возвращаются, зависит от того, что запрашивается.

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

Спасибо и наилучшие пожелания, Марк

Answer 1

Я думаю, что вы недоразумение.Предостережение против использования внешнего пользовательского ввода в качестве кеша ключей .Другими словами, вы не должны принимать какой-либо ввод от пользователя и устанавливать что-то в кеше через это:

_cache.SetString(userInput, "foo");

Речь не идет о настройке ввода пользователя как значение , т.е.:

_cache.SetString("my cache key", userInput);

Это также не говорит о разделении кеша по пользователю:

_cache.SetString($"cache key for user {userId}", "foo");

Оба последних сценария хороши.Просто то, что пользователь может сам установить ключ, открывает себя для таких вещей, как потенциальные атаки с использованием SQL-инъекций, в зависимости от вашего хранилища кэша.

Также обратите внимание, что в основном речь идет о неанизированном пользователе.вход.Если это что-то вроде перечисления, в котором пользователь может выбирать только из набора определенных значений, то все в порядке.Или, если вы иначе знаете, что ввод не будет вызывать проблемы.Например, проверенный почтовый индекс содержит только цифры и, возможно, одну черту.Злоумышленник ничего не может с этим поделать, так что все в порядке.Однако текстовое поле произвольной формы, например «Имя», по меньшей мере, было бы проблематичным.

Answer 2

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

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

Можно также рассмотреть внешнюю службу кэширования, такую ​​как Memcached , где вы можете использовать дополнительные серверы в качестве кэша.Это позволит вам кэшировать гораздо больше значений и снизить нагрузку на БД.