现在一些.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 的子集节点上)。有人能告诉我这样做的效果吗?
一个被推荐的解决方案是不根据缓存项的关键字来生成哈希键值。这将允许开发人员能够让一个给定页面中需要的所有缓存项,尽量存放在同一个服务器上。可惜,基于数据保存的地方而不是基于缓存项自身的关键字来生成哈希键,很容易产生错误,需要仔细来实现(这个算法)。
你可以在 BSD 的许可协议下使用 Memcached 。针对 C#的客户端API ,以及Perl、Python、PHP、Java 和其他语言的宿主都需要单独安装。最后,这有一个 Win32 的移植版本,可以让 Memcached 运行在非 Linux 的机器上。
查看英文原文: Using memcached with ASP.NET
评论