一个月前，fcicq邮件给我提供了一个Windows平台下的 memcached 类型的缓存软件 Cacheman。这是由微软旗下的 Popfly 项目组成员 Sriram Krishnan 的作品。是他用业余时间开发的。于是开始关注这个缓存项目。
最新的情况是，微软的 Popfly 网站已经“悄悄地”的做了更新，就是采用了 Krishnan 的 Cacheman，更新了缓存机制。该项缓存技术更新带来的性能提升非常显著，根据Popfly团队中的 John Montgomery 的说法：加载一个已有的Mashup应用时，可以带来2到6倍的性能提升。
这些说法也得到了 Krishnan 本人的确认 。他提到这是 Cacheman 的第一次的实际应用，并自豪的说 Cacheman 不费吹灰之力就拿下了 Popfly 的全部访问量。
有意思的是 Montgomery 说他很开心这玩意儿运行正常，特别在缓存的多层分布式方面考虑周到，然后他又画蛇添足的补充了一句“至少现在如此”，然后 Krishnan 调侃说“我喜欢你说‘至少现在如此’的方式”。
简单介绍一下 Cacheman 这个项目。资料主要来源于 Krishnan的博客对Cacheman的介绍。
Cacheman是一个基于Windows平台的快速分布式哈希表。是由纯托管代码实现。中间搁置了有几个月，直到最近(似乎是今年1月低2月初)才开始重新上马这个项目，极可能就是因为Popfly项目需要的缘故才开始着手的。
Krishnan本人对 memcached 很感兴趣，于是创建了 Cacheman。Cacheman上有很多 memcached 的影子，比如与memcached相似的文本通讯协议。Cacheman的通讯协议公开，任何人可以根据自己偏爱的语言环境写客户端。 Krishnan 在自己家用电脑（2.4GHz Intel Core 2 带2GB内存）上进入测试，达到了每秒16000次左右的请求，并且还是服务器与客户端都是在同一台服务器下完成的。
现这款产品还不太完善，作者自身也提到：在Cacheman做指定key的GET/SET/DELETE操作时，客户端需要弄清需要与哪一台Cacheman服务器通讯，为此要对该key做一个快速FNV哈希然后求余得到应该和几台服务器中的哪台服务器通讯。但该法的缺点在于新增或删除一个服务器节点时，缓存节点需要大规模迁移。修复该问题需要一致性的哈希算法，作者表示还没有时间解决此事。作者提出了采用中心架构的“主缓存服务器”的解决办法，让客户端轮询主缓存服务器来获取应该与那个缓存服务器通讯，但他也觉的这样做增加了复杂性，会带来些新问题。
可以感觉到，由于 Cacheman 这个个人项目已经介入到 Popfly 这个正式产品中，可能很快就会被微软吸纳为正式产品，因此如果有人采用这个产品做自己缓存的解决方案的话，应该不必太担心后续的产品升级及文档支持服务，它的未来前途值的期待。说不定 Krishnan 会从 Popfly 项目脱身出来专职负责这个 Cacheman 项目。
目前最新的版本是0.0.2版 下载：http://www.sriramkrishnan.com/projects/cacheman/Cacheman_0_0_2.zip 。虽然有人希望作者把它作为一个开源项目，遗憾的很，似乎作者并无此意，目前仅提供了二进制文件。
Microsoft’s answer to Memcached: Velocity