Кэширование ASP.NET InProc против распределенного кеша

Использование кеша в процессе или вне процесса зависит исключительно от приложения.

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

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

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

Вы также можете использовать гибридное решение для кэширования Inproc и OutProc, например, предоставленное NCache, где вы может иметь распределенный кластерный кеш (содержащий все кэшированные данные) и локальный кэш внутрипроцессов (содержащий подмножество данных, часто используемых этим сервером приложений). Это даст вам преимущества обоих методов кэширования.

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

InProc и распределенное кэширование не являются взаимоисключающими и вашими единственными вариантами. У вас может быть распределенное признание недействительности решения.

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

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