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

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

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

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

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

Спасибо!

2 ответа

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

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

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

Источник о состоянии сеанса: 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 в свой собственный, внести необходимые изменения, отменить регистрацию оригинала и зарегистрировать замену.

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

Другие вопросы по тегам