java web开发缓存方案,ehcache和redis哪个更好

如题所述

这里就不再逐个讨论了,我将会在一个实际应用程序开发场景中介绍其中的一些。使用Redis作为一个缓存解决方案我之前提到过,Redis可轻易地用作一个缓存解决方案,碰巧我现在正好需要这样一个!在该应用程序示例中,我将Redis集成到我基于定位的移动Web服务中,称之为Magnus。如果您没有关注本系列,那么我会先使用Play框架实现Magnus,从那时起我就已经在各种实现中开发和重构它了。Magnus是一个简单服务,可以通过HTTPPUT请求使用JSON文档。这些文档描述了特定帐号的位置,表示持有移动设备的人。现在,我想要将缓存集成到Magnus,也就是说我想要通过将不常更改的数据存储在内存中以减少I/O流量。Magnus缓存!在清单5中的第一步中,可以通过get调用了解新引入的帐户名称(一个键)是否为REdis中的一个键。get调用可以将帐户ID作为一个值返回,或者将返回null。如果返回一个值,我将用其作为我的acctId变量。如果返回的是null(表明该帐户名称不是Redis中一个键),那么我将在MongoDB查找该帐户值,并通过set命令将其添加到Redis。这里的优势是速度:接下来,被请求的帐户将提交一个位置,这样我就能够从Redis中获取其ID(作为内存缓存),而不是转到MongoDB并带来额外读取I/O成本。清单5.使用Redis作为内存缓存"/location/:account"{put{defjacksonMapper=newObjectMapper()defjson=jacksonMapper.readValue(request.contentText,Map.class)defformatter=newSimpleDateFormat("dd-MM-yyyyHH:mm")defdt=formatter.parse(json['timestamp'])defres=[:]try{defjedis=pool.getResource()defacctId=jedis.get(request.parameters['account'])if(!acctId){defacct=Account.findByName(request.parameters['account'])jedis.set(request.parameters['account'],acct.id.toString())acctId=acct.id}pool.returnResource(jedis)newLocation(acctId.toString(),dt,json['latitude'].doubleValue(),json['longitude'].doubleValue()).save()res['status']='success'}catch(exp){res['status']="error${exp.message}"}response.json=jacksonMapper.writeValueAsString(res)}}注意,清单5中的aMagnus实现(使用Groovy编写)仍然使用一个NoSQL实现作为数据模型存储;它仅仅使用Redis作为一个缓存实现用于查询数据。因为我的主要帐户数据位于MongoDB中(事实上,它驻留在MongoHQ.com中),而我的Redis数据存储在本地运行。在随后查找帐户ID时,Magnus速度将显著提升。可是等等!我为什么同时需要MongoDB和Redis?难道我就不能单独使用一个吗?ORM的Node.js很多项目均提供ORM类映射用于Redis,其中包括一个极富影响力的基于Ruby的备用方案,称为Ohm。我检查了该项目基于Java的派生产品(称为JOhm),但是最终决定使用一个为Node编写的派生产品。Ohm及其派生项目的妙处在于他们允许您将一个对象模型映射到一个基于Redis的数据结构。因此,您的模型对象是持久性的,同时在大多数情况下其读取速度也非常之快。有了Nohm,我便能够使用JavaScript快速重写我的Magnus应用程序并能立即持久化Location对象。在清单6中,我已定义了一个Location模型,该模型包括3个属性。(注意,我通过将timestamp设置为一个字符串而不是一个真实的时间戳,从而简化我的示例。)清单6.Node.js中的RedisORMvarLocation=nohm.model('Location',{properties:{latitude:{type:'float',unique:false,validations:[['notEmpty']]},longitude:{type:'float',unique:false,validations:[['notEmpty']]},timestamp:{type:'string',unique:false,validations:[['notEmpty']]}}});Node的Express框架使NohmLocation对象的使用变得十分简单。在我的应用程序PUT实现中,我可以捕获正在进入的JSON值,并通过Nohm的p调用将其导入到一个Location实例。然后我再检查该示例是否有效,如果有效,我会对其进行持久化。清单7.在Node的Express.js中使用Nohmapp.put('/',function(req,res){res.contentType('json');varlocation=newLocation;location.p("timestamp",req.body.timestamp);location.p("latitude",req.body.latitude);location.p("longitude",req.body.longitude);if(location.valid()){location.save(function(err){if(!err){res.send(JSON.stringify({status:"success"}));}else{res.send(JSON.stringify({status:location.errors}));}});}else{res.send(JSON.stringify({status:location.errors}));}});正如清单7所示,可以轻易地将Redis构建成一个极其快速的内存数据存储。在一些案例中,它甚至是一个比memcached更好的缓存!结束语Redis对于许多数据存储场景非常有用,因为它可以将数据持久化到磁盘(还因为它支持一个丰富的数据集),有时候,它是memcached的有力竞争对手。有些情况下,对于您的领域也是很有意义的,您可以使用Redis作为数据模型和队列的一个备份存储。Redis客户端实现几乎可被移植到任何编程语言中。Redis不是RDMBS的完全替代品,也不是一个重量级存储,但是和MongoDB一样拥有丰富的功能。然而,在很多情况下,它可与这些技术共存。
温馨提示:答案为网友推荐,仅供参考
第1个回答  2016-04-23
Ehcache
在java项目广泛的使用。它是一个开源的、设计于提高在数据从RDBMS中取出来的高花费、高延迟采取的一种缓存方案。正因为Ehcache具有健壮性(基于java开发)、被认证(具有apache 2.0 license)、充满特色(稍后会详细介绍),所以被用于大型复杂分布式web application的各个节点中。
1. 够快
Ehcache的发行有一段时长了,经过几年的努力和不计其数的性能测试,Ehcache终被设计于large, high concurrency systems.
2. 够简单
开发者提供的接口非常简单明了,从Ehcache的搭建到运用运行仅仅需要的是你宝贵的几分钟。其实很多开发者都不知道自己用在用Ehcache,Ehcache被广泛的运用于其他的开源项目
比如:hibernate
3.够袖珍
关于这点的特性,官方给了一个很可爱的名字small foot print ,一般Ehcache的发布版本不会到2M,V 2.2.3 才 668KB。
4. 够轻量
核心程序仅仅依赖slf4j这一个包,没有之一!
5.好扩展
Ehcache提供了对大数据的内存和硬盘的存储,最近版本允许多实例、保存对象高灵活性、提供LRU、LFU、FIFO淘汰算法,基础属性支持热配置、支持的插件多
6.监听器
缓存管理器监听器 (CacheManagerListener)和 缓存监听器(CacheEvenListener),做一些统计或数据一致性广播挺好用的
如何使用?
够简单就是Ehcache的一大特色,自然用起来just so easy!

redis
redis是在memcache之后编写的,大家经常把这两者做比较,如果说它是个key-value store 的话但是它具有丰富的数据类型,我想暂时把它叫做缓存数据流中心,就像现在物流中心那样,order、package、store、classification、distribute、end。现在还很流行的LAMP PHP架构 不知道和 redis+mysql 或者 redis + mongodb的性能比较(听群里的人说mongodb分片不稳定)。
先说说reidis的特性

1. 支持持久化
redis的本地持久化支持两种方式:RDB和AOF。RDB 在redis.conf配置文件里配置持久化触发器,AOF指的是redis没增加一条记录都会保存到持久化文件中(保存的是这条记录的生成命令),如果不是用redis做DB用的话还会不要开AOF ,数据太庞大了,重启恢复的时候是一个巨大的工程!
2.丰富的数据类型
redis 支持 String 、Lists、sets、sorted sets、hashes 多种数据类型,新浪微博会使用redis做nosql主要也是它具有这些类型,时间排序、职能排序、我的微博、发给我的这些功能List 和 sorted set 的强大操作功能息息相关
3.高性能
这点跟memcache很想象,内存操作的级别是毫秒级的比硬盘操作秒级操作自然高效不少,较少了磁头寻道、数据读取、页面交换这些高开销的操作!这也是NOSQL冒出来的原因吧,应该是高性能
是基于RDBMS的衍生产品,虽然RDBMS也具有缓存结构,但是始终在app层面不是我们想要的那么操控的。
4.replication
redis提供主从复制方案,跟mysql一样增量复制而且复制的实现都很相似,这个复制跟AOF有点类似复制的是新增记录命令,主库新增记录将新增脚本发送给从库,从库根据脚本生成记录,这个过程非常快,就看网络了,一般主从都是在同一个局域网,所以可以说redis的主从近似及时同步,同事它还支持一主多从,动态添加从库,从库数量没有限制。 主从库搭建,我觉得还是采用网状模式,如果使用链式(master-slave-slave-slave-slave·····)如果第一个slave出现宕机重启,首先从master 接收 数据恢复脚本,这个是阻塞的,如果主库数据几TB的情况恢复过程得花上一段时间,在这个过程中其他的slave就无法和主库同步了。

5.更新快
这点好像从我接触到redis到目前为止 已经发了大版本就4个,小版本没算过。redis作者是个非常积极的人,无论是邮件提问还是论坛发帖,他都能及时耐心的为你解答,维护度很高。有人维护的话,让我们用的也省心和放心。目前作者对redis 的主导开发方向是redis的集群方向。

所以如果希望简单就用ehcache,如果开发任务比较复杂,希望得到比较多的支持什么的就redis
第2个回答  2016-04-23
我们的项目中,ehcache、redis同时使用,另外还用bdb做cache本回答被网友采纳
相似回答