2

我们有一个 ASP.NET 4.0 应用程序，它从数据库中提取一个复杂的数据结构，该结构需要 12 多个小时才能推送到内存中的数据结构（后来存储在 HttpRuntime.Cache 中）。数据结构的大小正在迅速增加，如果应用程序重新启动，我们不能继续等待 12 多个小时才能将其放入内存。如果您要更改 web.config 或导致重新启动的 Web 应用程序中的任何代码，这是一个主要问题 - 这意味着在应用程序可以使用之前等待很长时间，并阻碍开发或更新部署。

数据结构必须在内存中以使网站可用的速度工作。与 HttpRuntime.Cache 相比，在内存数据库（如 memcache 或 Redis）中，速度较慢，并且在我们的情况下不起作用（在内存中，数据库必须序列化 put/get，而且它们不能相互引用，它们使用作为查找的键- 性能下降，加上大量键，性能迅速下降）。性能在这里是必须的。

我们想做的是在应用程序结束之前（在重新启动时）快速将 HttpRuntime.Cache 转储到磁盘，并能够在应用程序再次启动时立即将其加载回来（希望在几分钟内而不是 12 小时或几天内） .

内存结构约为 50GB。

有针对这个的解决方法吗？

4

1 回答 1

8

与 HttpRuntime.Cache 相比，内存数据库（如 memcache 或 Redis）速度较慢

是的，但与 12 小时以上的启动相比，它们非常快。就个人而言，我认为您在强制加载 50 GB 结构时采取了错误的方法。只是一个建议，但我们使用 HttpRuntime.Cache 作为多层缓存策略的一部分：

  • 首先检查本地缓存等
  • 否则redis作为下一层缓存（比底层数据快，持久化，支持多个app服务器）（然后更新本地缓存）
  • 否则，底层数据库被命中（然后redis和本地缓存都被更新）

关键是，在加载时，我们不需要内存中的任何内容 - 它会根据需要填充，从那时起它很快。我们还使用 pub/sub（同样由 redis 提供）来确保及时缓存失效。最终结果：它在寒冷时足够快，而在温暖时非常快。

基本上，我会先看看任何避免需要 50GB 数据的东西，然后才能做任何事情。

如果此数据不是真正的缓存，而是您的数据，我会在适当的对象模型上查看序列化。我建议将 protobuf-net（我作为作者有偏见）作为一个强有力的候选者 - 非常快且输出非常小。

于 2011-09-17T08:48:34.913 回答