注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

0与1构筑世界,程序员创造时代

软件架构设计 Java编程

 
 
 

日志

 
 

各种cache技术基本特性  

2008-01-18 14:13:43|  分类: Java |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
本文转载自互联网。

一、Cache Features
首先,我们来浏览一下常见的Cache。
这个链接给出了常用的Java Open Source Cache。
http://java-source.net/open-source/cache-solutions

memcached,JBoss Cache,SwarmCache,OSCache,JCS,EHCache等开源项目的出镜率和关注率比较高。
memcached和其他几个不同,后面会详述。
JBoss Cache的特点是,功能大而全,可算是Cache集大成者,几乎什么都支持。
其余的几个都很轻量。SwarmCache,OSCache,JCS支持Cluster。EHCache不支持Cluster。

下面列出Cache的基本特性。
1. 时间记录
数据进入Cache的时间。

2. timeout过期时间
Cache里面的数据多久过期

3. Eviction Policy 清除策略
Cache满了之后,根据什么策略,应该清除哪些数据。
比如,最不经常被访问的数据,最久没有访问到的数据。

4. 命中率
Cache的数据被选中的比率

5. 分级Cache
有些Cache有分级的概念。比如,几乎所有的Cache都支持Region分区的概念。可以指定某一类的数据存放在特定的Region里面。JBoss Cache可以支持更多的级别。

6. 分布式Cache
分布在不同计算机上的Cache

7. 锁,事务,数据同步
一些Cache提供了完善的锁,事务支持。

以上特性,大部分Cache都有相应的API支持。这些API很直观,也很简单,本文不打算展开讲述。
本文下面主要介绍,memcached和JBoss Cache这两个具有代表意义的Cache的高级特性,包括分布式Cache的支持。

二、memcached
http://www.danga.com/memcached/

memcached是一个Client Server结构的远程Cache实现。
Server是用C写的,提供了多种语言的客户端API,包括Java, C#, Ruby, Python, PHP, Perl, C等多种语言。
memcached主要使用在Shared Nothing Architecture中。应用程序通过客户端API,从memcached server存取数据。
典型的应用,比如,用memcached作为数据库缓存。
也常有这样的用法,用memcached存放HTTP Session的数据。具体做法是包装Session Interface,截获setAttribute(), getAttribute()方法。

MemcachedSessionWrapper {
Object getAttribute( key ){
return memcachedClient.get (session.getId() + key);
}
void setAttribute( key, value ){
memcachedClient.setObject(session.getId() + key, value);
}
}

不同计算机上的应用程序通过一个IP地址来访问memcahced Server。
同一个key对应的数据,只存在于一台memcached server的一份内存中。
memcached server也可以部署在多台计算机上。Memcached通过key的hashcode来判断从哪台memcached server上存取数据数据。我们可以看到,同一个key对应的数据,还是只存在于一台memcached server的一份内存中。
所以,memcached不存在数据同步的问题。这个特性很关键,我们后面讲到Cluster Cache的时候,就会涉及到数据同步的问题。
memcached由于是远程Cache,要求放到Cache的Key和Value都是Serializable。
远程Cache,最令人担心的网络通信开销。据有经验的人说,memcached网络通信开销很小。
memcached的API设计也是远程通信友好的,提供了getMulti()等高粒度的调用方法,能够批量获取数据,从而减少网络通信次数。

三、JBoss Cache
http://www.jboss.org/products/jbosscache

有一个商业Cluster Cache,叫做tangosol。
JBoss Cache是我唯一知道的能够和tangosol媲美的开源Cache。

Cluster Cache的数据同步,需要网络通信,这就要求放到Cache的数据是Serializable。
JBoss Cache提出了POJO Cache的概念,意思是数据不是Serializable,一样能够在Cluster中同步。
JBoss POJO Cache通过AOP机制,支持对象同步,支持对象属性的同步,支持关联对象的Cache,支持继承,集合,Query,并支持不同级别的事务,俨然一个小型内存数据库级别的数据存储系统。
下面进行解释。
最令人迷惑不解的是这个POJO的Cluster同步如何实现。
JBoss POJO Cache采用AOP来照管了POJO的通信和传播工作。天下没有免费的午餐,POJO不支持序列化,框架本身就要做这个工作——Marshal and Unmarshal,比如通过把Java对象翻译成XML,传播出去,对方收到XML,再翻译成Java对象。
上面说了,JBoss POJO Cache很像一个小型存储容器,JBoss POJO Cache的对象管理也非常类似Hibernate,JDO,JPA等ORM工具,同样有Detach和Attach的概念。
Attach就是put,把对象放入到Cache中。Detach就是remove,把对象从Cache中删除。为啥要多起个名?
原因是,put的时候,放进去的是个干干净净的POJO,出来的时候,就是Enhanced Object,里面夹杂了很多Interceptor代码,监听对象的方法。
你操作这个对象的时候,JBoss AOP框架就获得了相应的通知,能够做出相应的反应,比如数据同步等。
JBoss POJO Cache支持对集合类型的AOP。同样需要把集合Attach(Put)进Cache,然后get出来,然后对集合进行操作,就可以被JBoss AOP截获了。

JBoss POJO Cache的基础是JBoss Tree Cache。这个Tree Cache类似于一个XML DOM树形数据结构。
JBoss Cache采用Full Qualified Name作为Cache Key,类似于XPath。比如,a/b/c/d。
当你删除a/b的时候,a/b/c,a/b/c/d等所有属于a/b的Key和对应数据,都被删除。
JBoss Cache的findObjects方法能够找出一串对象。比如,findObjects根据a/b/c/d能够找出a,b,c,d等4个对象,放在一个Map中返回。
具体用法要参见API详细说明,因为JBoss POJO Cache提供了很多行为模式。
这种分级的Cache功能很有用,实现起来也不难。只是,我觉得,还是不够强大。既然支持了类似于XPath的Key,不如索性支持XPath的条件查询。比如,a[name=”n”]/b/c。当然,实现这种功能的代价非常大,需要遍历整个Cache Tree,正如XPath需要遍历整个DOM节点一样。

最后,JBoss Cache和tangosol一样,都支持了一个我认为如同鸡肋一般的功能,锁机制和事务支持。这个事务支持的意思是,Cache本身实现了类似于数据库的4种事务隔离级别。
在我看来,这种支持无疑是为了赚取眼球。Cache不当做Cache来用,搞些歪门邪道,大而不当。想当作数据库来用,那还不如把主要功夫花在上述提到的那种精确批量查询功能上。

四、Cluster同步
Cluster 之间的Cache同步有多种实现方法。比如,JMS,RMI,Client Server Socket等方法,用的最多的,支持最广的方法是JGroups开源项目实现的Multicast。配置Cluster Cache,通常就相当于配置JGroups,需要阅读JGroups配置文档。
Cache的操作通常有4个,get,put,remove,clear。
对 于Cluster Cache来说,读操作(get)肯定是Local方法,只需要从本台计算机内存中获取数据。Remove/clear两个写操作,肯定是Remote方法,需要和Cluster其他计算机进行同步。Put这个写方法,可以是Local,也可以是Remote的。
Remote Put方法的场景是这样,一台计算机把数据放到Cache里面,这个数据就会被传播到Cluster其他计算机上。这个做法的好处是Cluster各台计算机的Cache数据可以及时得到补充,坏处是传播的数据量比较大,这个代价比较大。
Local Put方法的场景是这样,一台计算机把数据放到Cache里面,这个数据不会被传播到Cluster其他计算机上。这个做法的好处是不需要传播数据,坏处是Cluster各台计算机的Cache数据不能及时得到补充,这个不是很明显的问题,从Cache中得不到数据,从数据库获取数据是很正常的现象。
Local Put比起Remote Put的优势很明显,所以,通常的Cluster Cache都采用Local Put的策略。各Cache一般都提供了Local Put的配置选项,如果你没有看到这个支持,那么请换一个Cache。Very Happy

五、Center vs Cluster
Memcached可以看作是Center Cache。
Center Cache和Cluster Cache的特性比较如下:
Center Cache没有同步问题,所以,remove/clear的时候,比较有优势,不需要把通知发送到好几个计算机上。
但是,Center Cache的所有操作,get/put/remove/clear都是Remote操作。而Cluster Cache的get/put都是Local操作,所以,Cluster Cache在get/put操作上具有优势。

Local get/put在关联对象的组装和分拆方面,优势比较明显。
关联对象的分拆是这个意思。
比如,有一个Topic对象,下面有几个Post对象,每个Post对象都有一个User对象。
Topic对象存放到Cache中的时候,下面的关联对象都要拆开来,分成各自的Entity Region来存放。
Topic Region -> Topic ID -> Topic Object
Post Region -> Post ID -> Post Object
User Region -> User ID -> User Object
这个时候,put的动作可能发生多次。Remote Put的开销就比较大。
Get的过程类似,也需要get多次,才能拼装成一个完整的Topic对象。

六、过期数据
Cache可以用在任何地方,比如,页面缓存。但Cache的最常用场景是用在ORM中,比如,Hibernate,JDO,JPA中。
ORM Cache的使用方法有个原则——不要把没有Commit的修改数据放入到缓存中。这是为了防止Read Dirty。
数据库事务分为两种,一种是读事务,不修改数据,一种是写事务,修改数据。
写事务的操作流程如下:
db.commt();
cache.remove(key); // 这一步操作,清除了Cache数据,也记录了一个时间removeTime。

读事务的操作流程如下:
readTime = current time;
data = cache.get(key);
if(data is null){
data = db.load(key);
cache.put(key, data, readTime); // 这里要readTime传进去
}

这里需要注意的是put的时候,需要readTime这个参数。
这个readTime要和上一次的removeTime进行比较。
如果readTime > removeTime,这个put才能成功,数据才能够进入缓存。
这是为了保证不把过期数据放入到Cache中,及时反映数据库的变化。

另外,需要注意的是,cache.remove(key); 这个事件需要传播到Cluster其他计算机,通知它们清理缓存。
为什么需要这个通知?
一定要注意,这不是为了避免并发修改冲突。并发修改冲突的避免需要引入乐观锁版本控制机制。
有可能存在这样的误解,认为有了乐观锁版本控制机制,就不需要Cache.remove通知了。这是不对的。
Cache.remove通知的主要目的是,保证缓存能够及时清理过期数据,反映数据的变化,保证大部分时间内,应用程序显示给用户的不是过期数据。
另外,db.commt(); cache.remove(key); 这两步调用之间,有很小的可能发生另外的事务。这段极小的时间内,可能无法保证Read Committed,可能出现很短期的过期数据。
为什么说很短期,因为紧接着的Cache.remove就会清理过期数据。
如果偏执到这种程度,这么短期的几乎不可能发生的小概率事件,都不能容忍,那么可以,db.commt()之前,给Cache加一个悲观锁,不让别的事务,把数据Put进入Cache,就可以防止这个小概率、微影响的事件。
JBoss Cache和Tangosol就提供了这类鸡肋一般的悲观锁机制。典型的开发资源配置不当,有用的需要的不做,没用的功能使劲做。
ORM Query Cache
ORM Cache一般分为两种。一种是ID Cache(ORM文档中称为二级Cache),用来存放Entity ID对应的Entity对象;一种是Query Cache,用来存放一条查询语句对应的查询结果集。
ID Cache非常直观,如同上述讲述的,一般是一个Entity Class对应一个Region,Entity存放到对应的Region里面。
Query Cache比较复杂,而且潜在作用很大,值得仔细讲解。
现有的ORM对Query Cache的支持并不是很理想。
比如,Hibernate把整个结果集直接放在Query Cache中。这样,有任何风吹草动,发生了任何数据库的写操作,Query Cache都需要清空。
有 一种比较好的做法,把ID List存放在Query Cache中,每次获取的时候,先获取ID List,然后根据ID List获取Entity List。Query Cache根据Query涉及到的Table Name来进行清理,一旦发生对这些Table Name的修改操作,就可以根据不同情况,清理Query Cache。
比如,select t2.* from t1, t2 where t1.id = t2.foreign_id and t1.name = ‘a’
那么insert into t1, delete from t1, insert into t2, delete from t2都会清除这条Query Cache。
同样的 update t1 set 这样的语句也会清除这条Query Cache。
Hibernate为什么不这么做,因为Query Cache的情况比较复杂。也许选择的结果集并不是只有一个Entity类型,也许只是几个字段。
这个地方,如果细分,还是有很多功夫可以做的。而且也很值得花功夫做,因为Query Cache对于性能的提高,有很大作用。

七、ORM Query Cache
Cache可以用在任何地方,比如,页面缓存。但Cache的最常用场景是用在ORM中,比如,Hibernate,JDO,JPA中。
ORM Cache一般分为两种。一种是ID Cache(ORM文档中称为二级Cache),用来存放Entity ID对应的Entity对象;一种是Query Cache,用来存放一条查询语句对应的查询结果集。
ID Cache非常直观,如同上述讲述的,一般是一个Entity Class对应一个Region,Entity存放到对应的Region里面。
Query Cache比较复杂,而且潜在作用很大,值得仔细讲解。
现有的ORM对Query Cache的支持并不是很理想。
比如,Hibernate把整个结果集直接放在Query Cache中。这样,有任何风吹草动,发生了任何数据库的写操作,Query Cache都需要清空。
有 一种比较好的做法,把ID List存放在Query Cache中,每次获取的时候,先获取ID List,然后根据ID List获取Entity List。Query Cache根据Query涉及到的Table Name来进行清理,一旦发生对这些Table Name的修改操作,就可以根据不同情况,清理Query Cache。
比如,select t2.* from t1, t2 where t1.id = t2.foreign_id and t1.name = ‘a’
那么insert into t1, delete from t1, insert into t2, delete from t2都会清除这条Query Cache。
同样的 update t1 set 这样的语句也会清除这条Query Cache。
Hibernate为什么不这么做,因为Query Cache的情况比较复杂。也许选择的结果集并不是只有一个Entity类型,也许只是几个字段。
这个地方,如果细分,还是有很多功夫可以做的。而且也很值得花功夫做,因为Query Cache对于性能的提高,有很大作用。

八、Query Key
Query Cache的性能需要考虑几个方面。比如,Query Key。Query Key一般由2个部分组成:Query String部分,SQL, HQL, EQL, or OQL;参数部分。
寻找Query Key的对应数据的时候,Query Key的比较有两个步骤,先hash,然后equals。所以,Query Key的hashcode和equals两个方法很重要。尤其是equals方法。
equals 方法需要比较很长的Query String。如果没有命中,Query String不相等,那么开销很小,因为通常来说,不相等的String长度都不同,或者前面的字符串都不相同。开销最大的是命中的时候,Query String相等,那么需要把String从头比到尾。
我们可以采取一些方法来提高String的比较速度。比如,大部分的情况属于静态查 询,我们可以采用Singleton String。相同reference的String之间的比较速度很快。对于ORM来说,最好直接使用最外面的HQL, EQL, OQL作为Query Key,而不是采用生成的SQL结果。因为生成的SQL结果每次都是一个新String,具有不同的reference,Cache命中的时候,需要比较整个字符串。
动态拼装的Query String的性能提高比较难办。因为最终的结果,都是一个新String。我采用的一种方式是,动态拼装的结果是一个String[]。两个 String[]如果相等,那么里面的元素String的reference都是相等的,这是由JVM对一个Class内部的String常量进行优化的结果。
比如,
String[] a = {
    “select * from t where”
    “a = 1”
    “and b = 2”
};

String[] b = {
    “select * from t where”
    “a = 1”
    “and b = 2”
};

那么a和b的比较只需要3次String reference的比较。

<正文结束>


  评论这张
 
阅读(1583)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017