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做为缓存系统，到目前未知还没发现什么问题，运行非常良好。