实现我自己的 session 状态提供程序是不是一个坏主意，该提供程序根据 key 在 redis session 提供程序和 inproc session 提供程序之间有条件地切换？
我在一个非常大的遗留 asp.net 应用程序中工作，该应用程序当前使用 inproc session 提供程序。我们正在迁移到 Redis 作为 session 状态提供者，以便它持久部署，但是应用程序充满了 session 滥用(例如，太大的对象，不可序列化的对象，我出于某种原因在那里看到了一个线程？)。
我们计划慢慢纠正这些滥用行为，但在全部纠正之前，我们无法真正迁移到 Redis。我希望我们可以慢慢开始将可序列化安全 key 迁移到 Redis 中，而滥用行为仍保留在内存中，直到我们解决它们。
有人对此有什么建议吗？或者从进程中迁移到进程外的替代建议？
谢谢!
最佳答案
在 ASP.NET Web Form 和 MVC 中，使用 Redis 作为 Session State 只是在 Web.config 中修改几行。然后将 SerializableAttribute 添加到类中。 有 no side effects of applying it to a class .
根据我几年前迁移到 Azure 的经验，Session State 不值得慢慢迁移。
缓存是另一回事。它需要更改代码，因此我们最终实现了两个类 - MemoryCacheManager 和 RedisCacheManager，并在运行时在 IoC 容器中注册。然后将ICacheManager注入(inject)依赖类。
关于asp.net - 我如何从进程中慢慢迁移到使用 Redis 作为 session 状态提供程序？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52338316/