（转载）各种cache技术基本特性

首先，介绍一下我（作者）自己使用Cache的背景，以便读者更清楚地了解我下面要讲述哪些内容。

我主要是一个Cache实现者，而不是使用者。为了给一些ORM（比如JPA实现）提供Cache支持，我需要包装其它的OpenSourceCache，并考察它们的特性。

我对这些OpenSourceCache的一些工作原理，了解得比较多。具体配置和使用细节，了解的比较少。

本文主要讲述的也是Cache的特性和工作原理，而不是一个安装、配置、使用的入门手册。

本文简述Cache的一般特性，详述Cache的高级特性，比如，分布式Cache，关联对象的Cache，POJOCache等。

阅读本文需要具备基本的Cluster知识，ORM知识，数据库事务知识。本文不解释这些基本概念。

-------------------------------------------------------

CacheFeatures

首先，我们来浏览一下常见的Cache。

这个链接给出了常用的JavaOpenSourceCache。

http://java-source.net/open-source/cache-solutions

memcached，JBossCache，SwarmCache，OSCache，JCS，EHCache等开源项目的出镜率和关注率比较高。

memcached和其他几个不同，后面会详述。

JBossCache的特点是，功能大而全，可算是Cache集大成者，几乎什么都支持。

其余的几个都很轻量。SwarmCache，OSCache，JCS支持Cluster。EHCache不支持Cluster。

下面列出Cache的基本特性。

1.时间记录

数据进入Cache的时间。

2.timeout过期时间

Cache里面的数据多久过期

3.EvictionPolicy清除策略

Cache满了之后，根据什么策略，应该清除哪些数据。

比如，最不经常被访问的数据，最久没有访问到的数据。

4.命中率

Cache的数据被选中的比率

5.分级Cache

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

6.分布式Cache

分布在不同计算机上的Cache

7.锁，事务，数据同步

一些Cache提供了完善的锁，事务支持。

以上特性，大部分Cache都有相应的API支持。这些API很直观，也很简单，本文不打算展开讲述。

本文下面主要介绍，memcached和JBossCache这两个具有代表意义的Cache的高级特性，包括分布式Cache的支持。

-------------------------------------------------------

memcached

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

memcached是一个ClientServer结构的远程Cache实现。

Server是用C写的，提供了多种语言的客户端API，包括Java,C#,Ruby,Python,PHP,Perl,C等多种语言。

memcached主要使用在SharedNothingArchitecture中。应用程序通过客户端API，从memcachedserver存取数据。

典型的应用，比如，用memcached作为数据库缓存。

也常有这样的用法，用memcached存放HTTPSession的数据。具体做法是包装SessionInterface，截获setAttribute(),getAttribute()方法。

MemcachedSessionWrapper{

ObjectgetAttribute(key){

returnmemcachedClient.get(session.getId()+key);

}

voidsetAttribute(key,value){

memcachedClient.setObject(session.getId()+key,value);

}

}

不同计算机上的应用程序通过一个IP地址来访问memcahcedServer。

同一个key对应的数据，只存在于一台memcachedserver的一份内存中。

memcachedserver也可以部署在多台计算机上。Memcached通过key的hashcode来判断从哪台memcachedserver上存取数据数据。我们可以看到，同一个key对应的数据，还是只存在于一台memcachedserver的一份内存中。

所以，memcached不存在数据同步的问题。这个特性很关键，我们后面讲到ClusterCache的时候，就会涉及到数据同步的问题。

memcached由于是远程Cache，要求放到Cache的Key和Value都是Serializable。

远程Cache，最令人担心的网络通信开销。据有经验的人说，memcached网络通信开销很小。

memcached的API设计也是远程通信友好的，提供了getMulti()等高粒度的调用方法，能够批量获取数据，从而减少网络通信次数。

-------------------------------------------------------

JBossCache

http://www.jboss.org/products/jbosscache

有一个商业ClusterCache，叫做tangosol。

JBossCache是我唯一知道的能够和tangosol媲美的开源Cache。

ClusterCache的数据同步，需要网络通信，这就要求放到Cache的数据是Serializable。

JBossCache提出了POJOCache的概念，意思是数据不是Serializable，一样能够在Cluster中同步。

JBossPOJOCache通过AOP机制，支持对象同步，支持对象属性的同步，支持关联对象的Cache，支持继承，集合，Query，并支持不同级别的事务，俨然一个小型内存数据库级别的数据存储系统。

下面进行解释。

最令人迷惑不解的是这个POJO的Cluster同步如何实现。

JBossPOJOCache采用AOP来照管了POJO的通信和传播工作。天下没有免费的午餐，POJO不支持序列化，框架本身就要做这个工作——MarshalandUnmarshal，比如通过把Java对象翻译成XML，传播出去，对方收到XML，再翻译成Java对象。

上面说了，JBossPOJOCache很像一个小型存储容器，JBossPOJOCache的对象管理也非常类似Hibernate，JDO，JPA等ORM工具，同样有Detach和Attach的概念。

Attach就是put，把对象放入到Cache中。Detach就是remove，把对象从Cache中删除。为啥要多起个名？

原因是，put的时候，放进去的是个干干净净的POJO，出来的时候，就是EnhancedObject，里面夹杂了很多Interceptor代码，监听对象的方法。

你操作这个对象的时候，JBossAOP框架就获得了相应的通知，能够做出相应的反应，比如数据同步等。

JBossPOJOCache支持对集合类型的AOP。同样需要把集合Attach（Put）进Cache，然后get出来，然后对集合进行操作，就可以被JBossAOP截获了。

JBossPOJOCache的基础是JBossTreeCache。这个TreeCache类似于一个XMLDOM树形数据结构。

JBossCache采用FullQualifiedName作为CacheKey，类似于XPath。比如，a/b/c/d。

当你删除a/b的时候，a/b/c，a/b/c/d等所有属于a/b的Key和对应数据，都被删除。

JBossCache的findObjects方法能够找出一串对象。比如，findObjects根据a/b/c/d能够找出a,b,c,d等4个对象，放在一个Map中返回。

具体用法要参见API详细说明，因为JBossPOJOCache提供了很多行为模式。

这种分级的Cache功能很有用，实现起来也不难。只是，我觉得，还是不够强大。既然支持了类似于XPath的Key，不如索性支持XPath的条件查询。比如，a[name=”n”]/b/c。当然，实现这种功能的代价非常大，需要遍历整个CacheTree，正如XPath需要遍历整个DOM节点一样。

最后，JBossCache和tangosol一样，都支持了一个我认为如同鸡肋一般的功能，锁机制和事务支持。这个事务支持的意思是，Cache本身实现了类似于数据库的4种事务隔离级别。

在我看来，这种支持无疑是为了赚取眼球。Cache不当做Cache来用，搞些歪门邪道，大而不当。想当作数据库来用，那还不如把主要功夫花在上述提到的那种精确批量查询功能上。

-------------------------------------------------------

Cluster同步

Cluster之间的Cache同步有多种实现方法。比如，JMS，RMI，ClientServerSocket等方法，用的最多的，支持最广的方法是JGroups开源项目实现的Multicast。配置ClusterCache，通常就相当于配置JGroups，需要阅读JGroups配置文档。

Cache的操作通常有4个，get，put，remove，clear。

对于ClusterCache来说，读操作（get）肯定是Local方法，只需要从本台计算机内存中获取数据。Remove/clear两个写操作，肯定是Remote方法，需要和Cluster其他计算机进行同步。Put这个写方法，可以是Local，也可以是Remote的。

RemotePut方法的场景是这样，一台计算机把数据放到Cache里面，这个数据就会被传播到Cluster其他计算机上。这个做法的好处是Cluster各台计算机的Cache数据可以及时得到补充，坏处是传播的数据量比较大，这个代价比较大

LocalPut方法的场景是这样，一台计算机把数据放到Cache里面，这个数据不会被传播到Cluster其他计算机上。这个做法的好处是不需要传播数据，坏处是Cluster各台计算机的Cache数据不能及时得到补充，这个不是很明显的问题，从Cache中得不到数据，从数据库获取数据是很正常的现象。

LocalPut比起RemotePut的优势很明显，所以，通常的ClusterCache都采用LocalPut的策略。各Cache一般都提供了LocalPut的配置选项，如果你没有看到这个支持，那么请换一个Cache。VeryHappy

-------------------------------------------------------

CentervsCluster

Memcached可以看作是CenterCache。

CenterCache和ClusterCache的特性比较如下：

CenterCache没有同步问题，所以，remove/clear的时候，比较有优势，不需要把通知发送到好几个计算机上。

但是，CenterCache的所有操作，get/put/remove/clear都是Remote操作。而ClusterCache的get/put都是Local操作，所以，ClusterCache在get/put操作上具有优势。

Localget/put在关联对象的组装和分拆方面，优势比较明显。

关联对象的分拆是这个意思。

比如，有一个Topic对象，下面有几个Post对象，每个Post对象都有一个User对象。

Topic对象存放到Cache中的时候，下面的关联对象都要拆开来，分成各自的EntityRegion来存放。

TopicRegion->TopicID->TopicObject

PostRegion->PostID->PostObject

UserRegion->UserID->UserObject

这个时候，put的动作可能发生多次。RemotePut的开销就比较大。

Get的过程类似，也需要get多次，才能拼装成一个完整的Topic对象。

-------------------------------------------------------

过期数据

Cache可以用在任何地方，比如，页面缓存。但Cache的最常用场景是用在ORM中，比如，Hibernate，JDO，JPA中。

ORMCache的使用方法有个原则——不要把没有Commit的修改数据放入到缓存中。这是为了防止ReadDirty。

数据库事务分为两种，一种是读事务，不修改数据，一种是写事务，修改数据。

写事务的操作流程如下：

db.commt();

cache.remove(key);//这一步操作，清除了Cache数据，也记录了一个时间removeTime。

读事务的操作流程如下：

readTime=currenttime;

data=cache.get(key);

if(dataisnull){

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);这两步调用之间，有很小的可能发生另外的事务。这段极小的时间内，可能无法保证ReadCommitted，可能出现很短期的过期数据。

为什么说很短期，因为紧接着的Cache.remove就会清理过期数据。

如果偏执到这种程度，这么短期的几乎不可能发生的小概率事件，都不能容忍，那么可以，db.commt()之前，给Cache加一个悲观锁，不让别的事务，把数据Put进入Cache，就可以防止这个小概率、微影响的事件。

JBossCache和Tangosol就提供了这类鸡肋一般的悲观锁机制。典型的开发资源配置不当，有用的需要的不做，没用的功能使劲做。

ORMQueryCache

ORMCache一般分为两种。一种是IDCache（ORM文档中称为二级Cache），用来存放EntityID对应的Entity对象；一种是QueryCache，用来存放一条查询语句对应的查询结果集。

IDCache非常直观，如同上述讲述的，一般是一个EntityClass对应一个Region，Entity存放到对应的Region里面。

QueryCache比较复杂，而且潜在作用很大，值得仔细讲解。

现有的ORM对QueryCache的支持并不是很理想。

比如，Hibernate把整个结果集直接放在QueryCache中。这样，有任何风吹草动，发生了任何数据库的写操作，QueryCache都需要清空。

有一种比较好的做法，把IDList存放在QueryCache中，每次获取的时候，先获取IDList，然后根据IDList获取EntityList。QueryCache根据Query涉及到的TableName来进行清理，一旦发生对这些TableName的修改操作，就可以根据不同情况，清理QueryCache。

比如，selectt2.*fromt1,t2wheret1.id=t2.foreign_idandt1.name=‘a’

那么insertintot1,deletefromt1,insertintot2,deletefromt2都会清除这条QueryCache。

同样的updatet1set这样的语句也会清除这条QueryCache。

Hibernate为什么不这么做，因为QueryCache的情况比较复杂。也许选择的结果集并不是只有一个Entity类型，也许只是几个字段。

这个地方，如果细分，还是有很多功夫可以做的。而且也很值得花功夫做，因为QueryCache对于性能的提高，有很大作用。

-------------------------------------------------------

ORMQueryCache

Cache可以用在任何地方，比如，页面缓存。但Cache的最常用场景是用在ORM中，比如，Hibernate，JDO，JPA中。

ORMCache一般分为两种。一种是IDCache（ORM文档中称为二级Cache），用来存放EntityID对应的Entity对象；一种是QueryCache，用来存放一条查询语句对应的查询结果集。

IDCache非常直观，如同上述讲述的，一般是一个EntityClass对应一个Region，Entity存放到对应的Region里面。

QueryCache比较复杂，而且潜在作用很大，值得仔细讲解。

现有的ORM对QueryCache的支持并不是很理想。

比如，Hibernate把整个结果集直接放在QueryCache中。这样，有任何风吹草动，发生了任何数据库的写操作，QueryCache都需要清空。

有一种比较好的做法，把IDList存放在QueryCache中，每次获取的时候，先获取IDList，然后根据IDList获取EntityList。QueryCache根据Query涉及到的TableName来进行清理，一旦发生对这些TableName的修改操作，就可以根据不同情况，清理QueryCache。

比如，selectt2.*fromt1,t2wheret1.id=t2.foreign_idandt1.name=‘a’

那么insertintot1,deletefromt1,insertintot2,deletefromt2都会清除这条QueryCache。

同样的updatet1set这样的语句也会清除这条QueryCache。

Hibernate为什么不这么做，因为QueryCache的情况比较复杂。也许选择的结果集并不是只有一个Entity类型，也许只是几个字段。

这个地方，如果细分，还是有很多功夫可以做的。而且也很值得花功夫做，因为QueryCache对于性能的提高，有很大作用。

-----------------------------------------------------------

QueryKey

QueryCache的性能需要考虑几个方面。比如，QueryKey。QueryKey一般由2个部分组成：QueryString部分，SQL,HQL,EQL,orOQL；参数部分。

寻找QueryKey的对应数据的时候，QueryKey的比较有两个步骤，先hash，然后equals。所以，QueryKey的hashcode和equals两个方法很重要。尤其是equals方法。

equals方法需要比较很长的QueryString。如果没有命中，QueryString不相等，那么开销很小，因为通常来说，不相等的String长度都不同，或者前面的字符串都不相同。开销最大的是命中的时候，QueryString相等，那么需要把String从头比到尾。

我们可以采取一些方法来提高String的比较速度。比如，大部分的情况属于静态查询，我们可以采用SingletonString。相同reference的String之间的比较速度很快。对于ORM来说，最好直接使用最外面的HQL,EQL,OQL作为QueryKey，而不是采用生成的SQL结果。因为生成的SQL结果每次都是一个新String，具有不同的reference，Cache命中的时候，需要比较整个字符串。

动态拼装的QueryString的性能提高比较难办。因为最终的结果，都是一个新String。我采用的一种方式是，动态拼装的结果是一个String[]。两个String[]如果相等，那么里面的元素String的reference都是相等的，这是由JVM对一个Class内部的String常量进行优化的结果。

比如，

String[]a={

“select*fromtwhere”

“a=1”

“andb=2”

};

String[]b={

“select*fromtwhere”

“a=1”

“andb=2”

};

那么a和b的比较只需要3次Stringreference的比较

引用

EHCache不支持Cluster

这个是不正确得，ehcache1.2之后就支持cluster了，

还有一点就是关于querycache描述也不是很正确，

1querycache其实应该是一个很大得范畴，不应该只用在orm那一层，也不局限把sql语句作为key，orm里这样使用定义querycache只是情况之一。

2查询结果集也可以被缓存。只有当经常使用同样的参数进行查询时，这才会有些用处。在查询缓存中，它并不缓存结果集中所包含的实体的确切状态；它只缓存这些实体的标识符属性的值、以及各值类型的结果。需要将打印sql语句与最近的cache内容相比较，将不同之处修改到cache中，所以查询缓存通常会和二级缓存一起使用。而querycache虽然能提高性能，但是按照hibernateinaction的话来说适用场景较少。

而如果我们放大query cache的概念，那么对于实时性要求不是很高的数据，它就能极大的提高性能，比如说主页，如果主页更新的时间为5分钟，那么query cache就能发挥其所长了。