现在一些。NET开发人员开始放弃ASP.NET内置的缓存机制，转而使用Memcached——一种分布式的内存缓存系统，其最初是由Danga Interactive公司为LiveJournal网站而开发。
存的一个基础性问题就是如何处理过时数据。当运行在单独的Web服务器上，你可以很容易地清除一个已经确认被改变了的缓存。可惜，ASP.NET没有一个很好的方法来支持多服务器。每个服务器上的缓存都对其他缓存的改变一无所知。
ASP.NET允许通过基于文件系统和数据库表的触发器来作废一个缓存。然而，这也存在问题，比如数据库触发器需要使用昂贵的轮询，以及触发器本身冗长的编程。但是，我们还是有其他的选择的。
不像ASP.NET内置的缓存机制，Memcached是一个分布式的缓存系统。任何Web服务器都能更新或删除一个缓存项，并且所有其他的服务器都能在下次访问这些缓存项的时候自动获取到更新的内容。这是通过把这些缓存项存储在一个或者多个缓存服务器上来实现的。每一个缓存项都根据它的关键字的哈希值来分配到一个服务器上。
表面看来，Memcached针对ASP.NET的API就像和内置的API一样。这让开发人员很容易地转换到Memcached上，仅仅通过在代码中查找和替换即可实现。
然而仅仅只是让其运行起来还不够，如果要在大型Web Farms（译者注：大型站点）正确地使用还需要注意一些问题。Richard Jones写到：
当我们添加很多节点后，get_multi函数的有用性在降低——这可能是由于单独的页面，需要访问几乎所有的Memcached实例。我在某处读到 Facebook（译者注：现在很火的校园社交网站）把他们的Memcached集群进行分割以提高get_multi的性能（例如，所有用户的数据都放置在名为mc的子集节点上）。有人能告诉我这样做的效果吗？
一个被推荐的解决方案是不根据缓存项的关键字来生成哈希键值。这将允许开发人员能够让一个给定页面中需要的所有缓存项，尽量存放在同一个服务器上。可惜，基于数据保存的地方而不是基于缓存项自身的关键字来生成哈希键，很容易产生错误，需要仔细来实现（这个算法）。