50GB HttpRuntime.Cache持久性可能吗？
我们有一个ASP.NET 4.0应用程序，它从数据库中提取一个复杂的数据结构，需要12个多小时才能进入内存数据结构（后来存储在HttpRuntime.Cache中）。 数据结构的大小正在迅速增加，如果应用程序重新启动，我们无法继续等待12个多小时才能将其存入内存。 如果要更改web.config或Web应用程序中导致重新启动的任何代码，这是一个主要问题 – 这意味着在使用应用程序之前需要等待很长时间，并阻碍开发或更新部署。
数据结构必须在内存中以使网站可用的速度工作。 在内存数据库中，例如memcache或Redis，与HttpRuntime.Cache相比速度较慢，并且在我们的情况下不起作用（在内存中db必须序列化put / get，加上它们不能互相引用，它们使用的是查找键 – 降低性能，加上大量密钥，性能迅速下降）。 性能是必须的。
我们想要做的是在应用程序结束之前（重启时）快速将HttpRuntime.Cache转储到磁盘，并且能够在应用程序再次启动时立即将其加载回来（希望在几分钟内而不是12小时或几天） 。
内存结构大约为50GB。
这个问题有方法解决吗？
在内存数据库中，例如memcache或Redis，与HttpRuntime.Cache相比速度较慢
是的，但与12小时以上的旋转相比，它们非常快。 就个人而言，我认为你在这里采取了错误的方法来强制加载50 GB的结构。 只是一个建议，但我们使用HttpRuntime.Cache作为多层缓存策略的一部分：
- 首先检查本地缓存等
- 否则redis被用作下一层缓存（比底层数据更快，持久，并支持许多应用服务器）（然后更新本地缓存）
- 否则，命中底层数据库（然后更新redis和本地缓存）
关键是，在加载时我们不需要内存中的任何东西 – 它在需要时填充，从那时起就很快。 我们还使用pub / sub（再次由redis提供）来确保缓存失效是及时的。 最终结果：冷时足够快，暖时速度很快。
基本上，我会先查看任何可以避免需要50GB数据的内容，然后才能执行任何操作 。
如果这个数据不是真正的缓存 ，而是你的数据 ，我会看一下正确的对象模型的序列化。 我建议protobuf-net（我作为作者有偏见）作为一个强有力的候选人 – 非常快和非常小的输出。