比较Java中几种数据cache方式

现在很多网站一说到cache就想到memcached，memcached确实是非常优秀的系统，但是在某些场合，特别在不是分布式应用的场合，或者某些数据不需要分布式的访问，那它就未必是最佳的选择。 下面比较3种cache方式，用测试结果说话 Map，严格的说不能算cache，它适合本机访问，没有过期时间，不适合大容量，不能预计长度的数据，可能会使内存耗尽。 ehcache，可设过期时间，当超过指定内存数量，可设置淘汰算法，可输出到磁盘，可适合本机访问，也适合用作分布式缓存，分布式缓存配置和原理稍复杂，没有memcached直观，本测试未使用ehHcache分布式支持。 Memcached, 适合分布式缓存，可设过期时间 1. 环境 OS: Linux, Ubuntu 7.04 64-bit Memory: 4G CPU: Intel(R) Pentium(R) D CPU 2.66GHz SCSI DISK, ext3 file system libevent 1.3e Memcached 1.2.4 Java 1.6.0 2. 测试方法 Key: 数字,1~100万 数据：100字节字符串 // put 100 char Element e = new Element(String.valueOf(n), "blah.....blah... 100 chars..."); cache.put(e); Memcache的设置方法参看memcachedb的性能测试 3. ehcache 设置 <cache name="cache1" maxElementsInMemory="1000000" eternal="true" overflowToDisk="false" timeToIdleSeconds="36000" timeToLiveSeconds="36000" diskPersistent="false" diskExpiryThreadIntervalSeconds="120" memoryStoreEvictionPolicy="LRU" /> 4. 测试结果 类型 测试数据 平均速度(次/秒) 最大速度(次/秒) 占用内存 Thread(s) HashMap.put* 1千万 146,268 254,262 1344.18MB 1* Hashtable.put 1千万 128,752 253,911 1572.52MB 4 EHCache.put 1千万 118,399 381,601 1245.08MB 4 Memcached.put 1百万 16,515 19,942 118.20MB 4 * HashMap 不是线程安全，多线程测试无意义。 * 未比较GET测试结果，由于GET测试先要模拟一定数据，用空表去测试GET结果可能无意义。(但是GET比较可能更重要，有时间补上) 本文地址为：http://hi.baidu.com/jabber 参考资源：NP博士的文章PHP cache的比较 《大型》系列（三）——Cache & Buffer 补充： 写完几天之后无意在网上看到这两篇文章：一正一反， 正方：Comparing Memcached and Ehcache Performance说ehcache要快50～100倍 反方： Unfair Benchmarks of Ehcache vs Memcached，貌似国内访问不到，里面意思是说要用memcached的getmulti方式测试比较才公平。另外担心ehcache中LRU算法GC不能回收内存。 http://hi.baidu.com/jabber/blog/item/798413d5191270c051da4b95.html Memcache   Memcache的优势我觉得总结下来主要体现在： 1） 分布式。可以由10台拥有4G内存的机器，构成一个40G的内存池，如果觉得还不够大可以增加机器，这样一个大的内存池，完全可以把大部分热点业务数据保存进去，由内存来阻挡大部分对数据库读的请求，对数据库释放可观的压力。 2） 单点。如果Web服务器或App服务器做负载均衡的话，在各自内存中保存的缓存可能各不相同，如果数据需要同步的话，比较麻烦（各自自己过期，还是分发数据同步？），即使数据并不需要同步，用户也可能因为数据的不一致而产生用户体验上的不友好。 3） 性能强。不用怀疑和数据库相比确实是，根源上还是内存的读写和磁盘读写效率上几个数量级的差距。有的时候我们在抱怨数据库读写太差的情况下可以看看磁盘的IO，如果确实是瓶颈的话装啥强劲的数据库估计也档不了，强不强无非是这个数据库多少充分的利用了内存。 但是也不太建议在任何情况下使用Memcache替代任何缓存： 1） 如果Value特别大，不太适合。因为在默认编译下Memcache只支持1M的Value（Key的限制到不是最大的问题）。其实从实践的角度来说也不建议把非常大的数据保存在Memcache中，因为有序列化反序列化的过程，别小看它消耗的CPU。说到这个就要提一下，我一直觉得Memcache适合面向输出的内容缓存，而不是面向处理的数据缓存，也就是不太适合把大块数据放进去拿出来处理之后再放进去，而是适合拿出来就直接给输出了，或是拿出来不需要处理直接用。 2） 如果不允许过期，不太适合。Memcache在默认情况下最大30天过期，而且在内存达到使用限制后它也会回收最少使用的数据。因此，如果我们要把它当作static变量的话就要考虑到这个问题，必须有重新初始化数据的过程。其实应该这么想，既然是缓存就是拿到了存起来，如果没有必定有一个重新获取重新缓存的过程，而不是想着它永远存在。 在使用Memcache的过程中当然也会有一些问题或者说最佳实践： 1） 清除部分数据的问题。Memcache只是一个Key/Value的池，一个公共汽车谁都可以上。我觉得对于类似的公共资源，如果用的人都按照自己的规则来的话很容易出现问题。因此，最好在Key值的规范上上使用类似命名空间的概念， 每一个用户都能很明确的知道某一块功能的Key的范围，或者说前缀。带来的好处是我们如果需要清空的话可以根据这个规范找到我们自己的一批Key然后再去清空，而不是清空所有的。当然有人是采用版本升级的概念，老的Key就让它过去吧，到时候自然会清空，这也是一种办法。不过Key有规范总是有好处的，在统计上也方便一点。 2） Value的组织问题。也就是说我们存的数据的粒度，比如要保存一个列表，是一个保存在一个键值还是统一保存为一个键值，这取决于业务。如果粒度很小的话最好是在获取的时候能批量获取，在保存的时候也能批量保存。对于跨网络的调用次数越少越好，可以想一下，如果一个页面需要输出100行数据，每一个数据都需要获取一次，一个页面进行上百次连接这个性能会不会成问题。 那么Memcache主要用在哪些功能上呢？ 其实我觉得平时能想到在内存中做缓存的地方我们都可以考虑下是不是可以去适用分布式缓存，但是主要的用途还是用来在前端或中部挡一下读的需求来释放Web服务器App服务器以及DB的压力。