Как я могу медленно перейти на использование Redis в качестве поставщика состояния сеанса из в процессе?

Question

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

Я работаю в очень большом устаревшем приложении asp.netкоторый в настоящее время использует поставщика сеанса inproc.Мы переходим на Redis в качестве поставщика состояния сеанса, чтобы он продолжал развертываться, однако приложение переполнено злоупотреблениями сеансами (например, слишком большие объекты, не сериализуемый объект, я видел поток там по какой-то причине?).

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

У кого-нибудь есть какие-либо советы по этому поводу?Или, возможно, альтернативные предложения по переходу из процесса в процесс?

Спасибо!

Answer 1

Источник для состояния сеанса: https://github.com/Microsoft/referencesource/blob/master/System.Web/State/ Документы: https://docs.microsoft.com/en-us/dotnet/api/system.web.sessionstate?view=netframework-4.7.2

Я бы начал с проверки справочного источника, чтобы вы могли искать в базе кода.Один интерфейс выглядит как потенциально интересный. IPartialSessionState (При реализации в типе возвращает список из нуля или более ключей сеанса, которые указывают поставщику состояния сеанса, какие элементы состояния сеанса должны быть получены.) Источник здесьhttps://docs.microsoft.com/en-us/dotnet/api/system.web.sessionstate.ipartialsessionstate?view=netframework-4.7.2

Я наткнулся на https://www.wiktorzychla.com/2007/06/wrapped-inprocsessionstatestore.html через ASPNET: переключение между поставщиками состояний сеанса? .
Теоретически эту технику можно использовать и с поставщиком Redis.,Вам нужно будет либо сохранить список ключей, пригодных для хранения в Redis, либо попытаться сериализовать / перехватить / кэшировать результат, типы которого можно сериализовать, и адаптивно использовать поведение InProc.Вы должны иметь возможность использовать HttpContext.Current.Items для передачи информации между событиями в конвейере обработки запросов.

SessionStateModule (модуль, отвечающий за получение сеанса, блокировку, сохранение, разблокировку и т. Д.), Кажется, обрабатываетInProc как особенный в нескольких местах.Найдите его код для InProc.По сути, вы пытаетесь подключить волшебный провайдер, который является Custom, но все еще имеет всю семантику InProc, применяемую одним-единственным SessionStateModule.Вы не сможете /, вероятно, не захотите модифицировать этот модуль, но вы можете подключить другой, смежный с ним, который подключается к связанным событиям в конвейере запросов и делает все, что нужно сделать, либоIn-Proc или пользовательские.Вы, вероятно, столкнетесь с внутренними / частными методами, для которых вам нужно будет использовать рефлексию.Не уверен, как лицензирование работает с эталонным источником (я думаю, MS-PL), но другой вариант - скопировать и вставить код из SessionStateModule в свой собственный, внести необходимые изменения, отменить регистрацию оригинала и зарегистрировать замену.

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

Answer 2

В ASP.NET Web Form и MVC использование Redis для состояния сеанса - это всего лишь пара строк модификации в Web.config. Затем добавьте SerializableAttribute к классам. Нет никаких побочных эффектов применения его к классу .

Исходя из моего опыта перехода на Azure несколько лет назад, состояние сеанса не стоит переносить медленно.

Кэширование - это отдельная история. Это требует изменения кода, поэтому в итоге мы реализуем два класса - MemoryCacheManager и RedisCacheManager и регистрируемся во время выполнения в контейнере IoC. Затем введите ICacheManager в зависимые классы.