目前，我正在ASP.net上使用C3.5的项目管理应用程序中进行工作。为了减少对数据库的访问，我使用静态变量来缓存很多信息。例如，用户列表以静态类的形式保存在内存中。该类在启动时会从数据库中读取所有信息，并且每当进行更改时都会更新数据库，但是它永远不需要从日期数据库中读取。

该类在写入数据库的同时，使用更新的信息对其他Web服务器(如果存在)执行ping操作。 ping机制是Windows服务，缓存对象使用随机可用端口向其注册。它也用于其他用途。

数据量不是很好。目前，我仅使用它来缓存用户(密码哈希，权限，名称，电子邮件等)。它只是保存了对数据库的大量调用。

我想知道这种方法是否有陷阱，或者是否有更好的方法来缓存数据？

解决方案

嗯..."经典"方法将是应用程序缓存，但前提是我们从不更新静态变量，或者如果我们不了解则不了解锁定问题，并且我们了解它们可以随时随appdomain重新启动而消失，那么我不会真的看不到使用静电的危害。

一个陷阱：每个应用程序域的作用域都是一个静态字段，并且增加的负载将使服务器在池中生成更多的应用程序域。如果我们仅从静态变量中读取数据，这并不一定是问题，但是我们将在内存中获得重复的数据，并且每次创建或者回收应用程序域时都会受到打击。

最好将Cache对象用于这样的事情。

编辑：事实证明，我对AppDomains错误(如注释中所指出)，将在负载下生成更多应用程序实例，但它们都将在同一AppDomain中运行。 (但是我们仍然应该使用Cache对象！)

只要我们可以期望缓存永远不会增长到大于可用内存量的大小，就可以了。另外，请确保每个数据库只有一个该应用程序实例，否则该应用程序不同实例中的缓存可能"不同步"。

在我工作的地方，我们有一个自己开发的O / RM，我们所做的事情与我们对某些预期不会增长或者更改太多的表所做的事情类似。因此，我们正在做的事情并非史无前例，事实上，在我们的系统中，这是经过尝试和真实的。

我们必须考虑的另一个陷阱是线程安全。所有应用程序请求都在同一个AppDomain中运行，但可能来自不同的线程。访问静态变量必须说明它是从多个线程访问的。可能比我们想要的要多一些开销。缓存对象更适合于此目的。

我建议我们研究为应用程序分配分布式缓存的方法。我们可以看看NCache或者indeXus.Net

我建议这样做的原因是因为我们采用了自己的临时方式来更新要缓存的信息。静态变量/引用很好，但是它们不更新/刷新(因此我们必须自己处理老化)，并且似乎具有分布式设置。