【发布时间】：2009-10-28 05:18:32
【问题描述】：
出于性能原因，我必须在内存中缓存一个对象层次结构，这反映了一个包含列（ObjectID、ParentObjectID、Timestamp）的简单数据库表并查看 CurrentObjectHierarchy。我查询 CurrentObjectHierarchy 并使用哈希表来缓存每个对象的当前父对象，以便在给定任何对象 ID 的情况下快速查找父对象 ID。查询数据库表和构建缓存平均需要 77 毫秒的操作，理想情况下，这种刷新仅在调用我的数据库 API 中会更改层次结构（添加/删除/重新设置对象）的方法时发生。
如果必须由多个 ASP.NET Web 应用程序访问，并且可能运行在不同的应用程序池中，那么这种缓存的最佳位置在哪里？
最初，我将缓存存储在不同 Web 应用程序共享的 C# dll 中的静态变量中。当然，问题是虽然静态变量可以跨线程访问，但它们不能跨进程访问，当涉及多个 Web 应用程序（可能在单独的应用程序池中运行）时，这是一个问题。结果……在一个应用程序中对对象层次缓存进行同步的、线程安全的修改不会反映在其他应用程序中，即使它们使用相同的代码库。
所以我需要一个更全局的位置来存放这个缓存。我不能使用静态变量（正如我刚才解释的）、会话状态（基本上是每个用户的存储）和应用程序状态（需要跨应用程序访问）。
我一直在考虑的潜在地点是：
- IIS 本身内的某种全局对象存储，可从任何应用程序池中的任何应用程序中的任何线程访问（如果存在这样的地方。是吗？）
- 管理独占缓存的单独的自定义 Web 服务。
目前，我认为最好的解决方案是 SQL CLR 集成，因为：
- 我可以使用静态变量保留当前的设计
- 这是一个已经存在的独立服务，所以我不必编写自定义服务
- 它将在单个进程 (SQL Server) 中运行，因此现有的基于锁的同步可以正常工作
- 缓存将设置为尽可能接近它所代表的数据结构！
我会在 SQL CLR DLL 中嵌入层次遍历方法，这样我就可以在通常进行常规方法调用的地方进行单个 SQL 调用。这一切都取决于在单个进程中运行的 SQL Server 以及将 CLR 加载到该进程中，我认为是这种情况。你觉得这怎么样？你能看出我可能遗漏的这个想法有什么明显的错误吗？这不是一个很棒的主意吗？
编辑： 仔细观察后，似乎不同的 ASP.NET 应用程序实际上运行在同一个进程中，但被 AppDomains 隔离。如果我能找到一种跨 AppDomain 共享和同步数据的方法，那将非常有用。我正在阅读有关 .NET Remoting 的信息。
【问题讨论】：
-
每台机器都有缓存有问题吗，我认为这是最简单的方法？
-
只有一台机器......这就是我将缓存放在机器上的位置，这样任何网络应用程序都可以（快速/轻松/同步）访问缓存的单个实例.我真的很喜欢将它直接放在 SQL Server 中的想法，因为这样我就可以在直接修改表时触发缓存的同步刷新（即在 SS Management Studio 中，而不是通过调用我的数据库 API 中的方法）。跨度>
-
那里有一些分布式缓存框架，你可能想给他们一个尖峰：stackoverflow.com/search?q=ncache我没有尝试过任何一个，所以我没有关于这个主题的更多信息。
标签： performance sql-server-2008 iis-7 caching global