ASP.NET InProc-кеширование и распределенный кеш

Question

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

Какое место лучше всего хранить в кеше? InProc или распространяется?

Answer 1

Использование кэша in-proc или out-proc зависит от приложения.

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

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

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

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

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

Answer 2

InProc и распределенное кэширование не являются взаимоисключающими или вашими единственными вариантами. Вы также можете получить distributed invalidation solutions.

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

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