memcached

做过的项目中Hibernate都是直接采用ehcache做为缓存,ehcache是一个好东西,采用内 存+文件系统结合可以胜任大多数情况,而且Hibernate和ehcache简直就是天造地设的一对,配合非常之默契。

但是在集群环境下缓存不同步的问题日益凸显,尽管最新版本的ehcache已经支持通过multicast来实现不同进程的缓存数据同步的功能,这样的结构在集群的节点很多的时候性能下降得厉害,而且也不清楚其稳定性如何,因此ehcache暂且搁下。

对memcached早有耳闻,它是一种采用客户端服务器工作模式的集中式缓存系统,在很多非常大的网站中被采用。之前试过Java版的客户端API,发现问题多多容易出错,由于同步的问题导致性能也超级差。最近Java的客户端API发布了新的版本,再次试用已不可同日而语,于是开始在项目中编写Memcached的CacheProvider供Hibernate使用,使用过程中碰到一些问题,现在把这些问题的中心思想写出来,希望对大家有所帮助。

首先ehcache和memcached的结构是完全不相同的。一个ehcache缓存系统可以同时定义多个cache,每个cache使用key-value方式存储数据,而memcahced只有key-value,它是一个大的哈希表。因此当我们在Hibernate配置了多个缓存的时候在memcached就会出现问题,这些问题具体表现出来的异常是ClassCastException,因为不同的对象使用同一个key进行缓存数据的读写。这在ehcache中是没有问题的,因为这就是ehcache的结构。由此,为了让Hibernate使用memcached缓存系统,我们需要在Provider这个级别上对缓存的key进行包装,我们可以将Hibernate传递过来的缓存名跟key结合起来生成一个新的key,读写缓存数据都是用这个key,这样就不会发生缓存数据冲突导致的异常。

还有另外一个问题是关于查询的缓存,当我们执行一个稍微复杂点的HQL语句并对这个语句的执行禁果进行缓存的时候可能会出错,这些错误的原因就是key的内容包含某些memcached通讯协议上定义的字符导致memcached在解析协议的时候出现异常,因此还是使用前面提到的方法,对key进行二次包装。做法不外乎两种:直接将key转成hashcode然后把hashcode做为新的key;如果担心生成的hashcode可能会重复(事实上这个可能性微乎其微),那还可以用MD5算法生成新的字符串来做为key,这样就不用担心我们的key存在一些memcached保留的字符而导致错误。

经过如此改造后,直接将DLOG4J改为memcached做为缓存系统,到目前未知还没发现什么问题,运行非常良好。

相关推荐