增加对JedisCluster的支持

Author: 邱家榆

README.md

@@ -8,30 +8,30 @@
 现在使用的缓存技术很多，比如*Redis*、 *Memcache* 、 *EhCache*等，甚至还有使用*ConcurrentHashMap* 或 *HashTable* 来实现缓存。但在缓存的使用上，每个人都有自己的实现方式，大部分是直接与业务代码绑定，随着业务的变化，要更换缓存方案时，非常麻烦。接下来我们就使用**AOP + Annotation** 来解决这个问题，同时使用**自动加载机制** 来实现数据“**常驻内存**”。
 
 
-###[设计思想及原理](./doc/idea.md)
+### [设计思想及原理](./doc/idea.md)
 
-###[使用方法](./doc/use.md)
+### [使用方法](./doc/use.md)
 
-###[注解（Annotation）说明](./doc/annotations.md)
+### [注解（Annotation）说明](./doc/annotations.md)
 
-###[表达式的应用](./doc/script.md)
+### [表达式的应用](./doc/script.md)
 
-###[缓存删除](./doc/deleteCache.md)
+### [缓存删除](./doc/deleteCache.md)
 
-###[注意事项](./doc/warning.md)
+### [注意事项](./doc/warning.md)
 
-###[缓存管理页面](./doc/admin.md)
+### [缓存管理页面](./doc/admin.md)
 
-###[与Spring Cache的区别](./doc/SpringCache.md)
+### [与Spring Cache的区别](./doc/SpringCache.md)
 
-###源码阅读
+### 源码阅读
 
 已经实现基于aspectj，代码在com.jarvis.cache.aop.aspectj.AspectjAopInterceptor。想通过阅读代码了解详细细节，可以以此为入口。
 
 
 ### [更新日志](./doc/changesLog.md)
 
-###未来计划：
+### 未来计划：
 希望未来能更好适应高并发的环境，更方便运维，欢迎有这方面经验的人能参与进来，让更多的人受益。
 
 在异步刷新缓存时，增加尝试多次去数据层加载数据，以适应解决有多个数据源，而其中部分数据源出问题情况。通过这种尝试机制，也许能获取到新的数据。

doc/ConcurrentHashMap.md

@@ -1,4 +1,4 @@
-###ConcurrentHashMap配置
+### ConcurrentHashMap配置
 
     <bean id="cacheManager" class="com.jarvis.cache.map.CachePointCut" init-method="start" destroy-method="destroy">
       <constructor-arg ref="autoLoadConfig" />

doc/JRedis.md

@@ -1,4 +1,4 @@
-####JRedis配置
+#### JRedis配置
 
 Redis配置
 

doc/Memcache.md

@@ -1,4 +1,4 @@
-###Memcache配置
+### Memcache配置
 
     <bean id="memcachedClient" class="net.spy.memcached.spring.MemcachedClientFactoryBean">
         <property name="servers" value="192.138.11.165:11211,192.138.11.166:11211" />

doc/changesLog.md

@@ -1,11 +1,11 @@
-##更新日志
+## 更新日志
 
-* ####4.14 修改说明
+* #### 4.14 修改说明
 
     * 使用Lombok来缩减代码,Lombok能帮助我们减少写get,set,hashCode,toString等没有技术含量的工作，而且在修改增加或删除java bean中的属性时，不需要去改hashCode，toString等方法，减少因为忘记修改而造成的错误。
     * 增加OGNL表达式引擎支持，经过测试它的性能要比SpringEL表达式还要优秀。测试代码在：com.test.script.ScriptTest
 
-* ####4.13 修改说明
+* #### 4.13 修改说明
 
     * com.jarvis.cache.clone.ICloner中的Object deepClone(Object obj) 改为 Object deepClone(Object obj, final Type type)，在能获得Type的情况下使用，能更好保证数据准备和效率
 
@@ -17,7 +17,7 @@
 
     * 修复DataLoader中，等待第一个请求获取数据后，又再去数据层获取数据的BUG，这个BUG是在4.11版本产生的，建议使用4.11和4.12的用户升级一下。
 
-* ####4.12 修改说明：
+* #### 4.12 修改说明：
 
     * fastjson deepClone 数组中有Map或Collection时，转换失败的问题
     * Fastjson深度复制优化：针对深度复制Method的arguments进行优化，通过method.getGenericParameterTypes() 来方便深度复制泛型参数。
@@ -26,40 +26,40 @@
     * ICacheManager中的get和set方法中，增加Method method和 Object args[]两个参数，方便使用者根据情况进行扩展，比如：增加一些自定义的注解，来处理特殊业务逻辑（比如：增加本地缓存功能）
 
 
-* ####4.11 修改说明：
+* #### 4.11 修改说明：
 
     * 增加刷新缓存数据功能，如果不使用自动加载，则在缓存即将过期时，开启线程进行异步刷新数据，可以减少用户的等待，避免因缓存失效失效造成系统压力过大；
     * 在刷新缓存和自动加载缓存中，如果从数据层加载数据时，发生异常，则使用旧数据进行续租（如果有旧数据的话），达到提前预防缓存失效后，系统压力过大问题；
     * 解决使用fastjson进行深度复制数据组时，转换错误的问题；
     * 增加使用cloning进行深度复制，性能要比fastjson提高50%。相关的测试代码在：com.test.fastjson.CloningTest和com.test.fastjson.DeepCloneTest两个类中；
     * 将数据加载功能从AbstractCacheManager中移到DataLoader中，使得代码更加清晰易懂；
 
-* ####4.10 增加使用Fastjson进行序列化的支持，同时也增加了对比较大的数据进行压缩的工具。
+* #### 4.10 增加使用Fastjson进行序列化的支持，同时也增加了对比较大的数据进行压缩的工具。
 
-* ####4.9 去除默认的serializer和scriptParser，以便于与Spring 进行强解耦。
+* #### 4.9 去除默认的serializer和scriptParser，以便于与Spring 进行强解耦。
 
-* ####4.8 优化JavaScriptParser 中的代码，并根据JDK版本，使用javascript 还是nashorn 引擎。
+* #### 4.8 优化JavaScriptParser 中的代码，并根据JDK版本，使用javascript 还是nashorn 引擎。
 
-* ####4.7 修改说明：
+* #### 4.7 修改说明：
 
     * 修改缓存预警时间值，加入-10~10秒随机数，避免缓存集中失效
     * 实现表达式引擎的可扩展性，默认还是使用SpringEL表达式引擎（com.jarvis.cache.script.SpringELParser），但可以自己实际情况进行扩展。扩展方法：实现com.jarvis.cache.script.IScriptParser,然后通过配置把实现的实例注入到AbstractCacheManager中的scriptParser属性即可。使用不同表达式引擎时，注意表达式的语言的区别。
     * 增加了JavaScript 表达式引擎实现：com.jarvis.cache.script.JavaScriptParser。如果项目使用JDK1.8的，想用JavaScript的话，建议使用Nashorn 来实现，性能会比较好。
 
 
-* ####4.6 修改说明：
+* #### 4.6 修改说明：
 
     * @Cache中增加 expireExpression，实现通过表达式来动态获取expire 值；
     * @Cache 中增加 alarmTime。当缓存在alarmTime 时间内即将过期的话，会自动刷新缓存内容；
     * 解决 hessian2 无法序列化SoftReference 的bug；
 
-* ####4.5 修改说明：
+* #### 4.5 修改说明：
 
     * 调整CacheTask 中 Thread.sleep(0); 的位置；
     * 增加CacheChangeListener 接口，优化代码结构；
     * 使用SoftReference 管理Map中的缓存数据；
 
-* ####4.4 修改说明：
+* #### 4.4 修改说明：
 
     当遍历次数达到2000时，执行Thread.sleep(0); 触发操作系统立刻重新进行一次CPU竞争, 让其它线程获得CPU控制权的权力。
 
@@ -68,58 +68,58 @@
     * 增加属性：int unpersistMaxSize，允许不持久化变更数(当缓存变更数量超过此值才做持久化操作)
     * 增加属性: boolean copyValue;是否拷贝缓存中的值：true时，是拷贝缓存值，可以避免外界修改缓存值；false，不拷贝缓存值，缓存中的数据可能被外界修改，但效率比较高。
 
-* ####4.3 对 ConcurrentHashMap 缓存增加持久化功能。重启时会从本地磁盘加载缓存数据，避免因刚启动没有缓存数据，造成压力过大。
+* #### 4.3 对 ConcurrentHashMap 缓存增加持久化功能。重启时会从本地磁盘加载缓存数据，避免因刚启动没有缓存数据，造成压力过大。
 
 
-* ####4.2 改用JDK1.6进行编译；将isAutoload中的cache.expire() > 120 改为 cache.expire() >= 120；
+* #### 4.2 改用JDK1.6进行编译；将isAutoload中的cache.expire() > 120 改为 cache.expire() >= 120；
 
     AutoLoadHandler中排序线程增加sleep，以节约系统资源
 
-* ####4.1 提升缓存管理页的扩展性
+* #### 4.1 提升缓存管理页的扩展性
 
     将获取AOP配置信息功能从 AdminServlet 中抽取出来，并使用CacheManagerConfig接口来获取。
 
-* ####4.0 实现AOP的可扩展
+* #### 4.0 实现AOP的可扩展
 
     受网友Rekoe 将AutoLoadCache 和 nutz整合的启发([https://github.com/Rekoe/AutoLoadCache](https://github.com/Rekoe/AutoLoadCache))，将AutoLoadCache 中的AOP相关功能进行抽取，以达到可扩展
 
     * 把AOP拦截方法从AbstractCacheManager中抽取出来，并使用CacheAopProxyChain 和 DeleteCacheAopProxyChain 两个代理类进行封装拦截到的请求。
     * 实现了使用Aspectj进行AOP拦截：com.jarvis.cache.aop.aspectj.AspectjAopInterceptor
     * 升级时一定要注意配置文件的变化，可以参考[cache-example](https://github.com/qiujiayu/cache-example) 中的配置
 
-* ####3.7 细节优化：
+* #### 3.7 细节优化：
 
     * 调整 写缓存（writeCache）代码结构。
     * 将ShardedCachePointCut中hashExpire默认值设置为-1；
     * 解析SpEL表达式时，增加判断是否有返回值，避免在不能使用#retVal的地方，使用了#retVal
     * 将com.jarvis.cache.map.CachePointCut.shutDown() 改成  destroy()
 
-* ####3.6  对@ExCache相关代码进行调整，自动加载时也对@ExCache进行处理。对一些变量增加volatile 修饰符，以便于其它线程的读取到最新的值。
+* #### 3.6  对@ExCache相关代码进行调整，自动加载时也对@ExCache进行处理。对一些变量增加volatile 修饰符，以便于其它线程的读取到最新的值。
 
-* ####3.5  增加如下几个功能：
+* #### 3.5  增加如下几个功能：
 
     * 注册自定义Spring EL表达式函数
     * 如果ShardedCachePointCut 中的 hashExpire 小于0则使用@Cache中设置的expire值，替换hashExpire值。
     * 增加@ExCache，用于增强@Cache 设置缓存功能。应用场景举例：我们使用getUserByName时，返回User的对象，其实也可以设置给getUserById的缓存中的，反过也是同样的道理，通过getUserById方法返回的数据，也可以设置给getUserByName的缓存中​，这样可以减少与DAO的交互了。
 
 
-* ####3.4  使用管道来操作Redis 的哈希表，减少与Redis的交互次数。
+* #### 3.4  使用管道来操作Redis 的哈希表，减少与Redis的交互次数。
 
-* ####3.3  增加 Spring EL 表达式（Expression）缓存。
+* #### 3.3  增加 Spring EL 表达式（Expression）缓存。
 
 
-* ####3.2 进一步优化“拿来主义”机制
+* #### 3.2 进一步优化“拿来主义”机制
 
     使用当前的ProcessingTO来做同步锁，把锁粒度降到了最低，以提升并发性能；删除并发线程的计数器；如果第一个线程执行时出现异常，那等待中的线程，也直接抛出异常，因为此时去执行DAO的出错的可能性非常大，会造成服务器压力过大。
 
 
-* ####3.1 优化“拿来主义”机制
+* #### 3.1 优化“拿来主义”机制
 
     “拿来主义”机制指的是，当有多个请求去获取同一个数据时，我们先让其中一个请求先去DAO中获取数据，并放到缓存中，其它请求则等它完成后，直接去缓存中获取数据，通过这种方式减轻DAO中的并发。
 
     但经测试发现，刚往Reids中放的数据，立即去取是获取不到数据的（无法命中），测试代码已经放到[cache-example](https://github.com/qiujiayu/cache-example) 中。优化后的方案是，不从远程服务器获取，而是从本地内存中获取第一个请求返回的数据。减少并发的同时，还能减轻网络压力。
 
-* ####3.0 此版本做了大调整，有些功能已经不兼容老版本 
+* #### 3.0 此版本做了大调整，有些功能已经不兼容老版本 
 
     不再使用默认缓存Key，所有的缓存都必须自定义缓存Key；原来使用$hash()来调用hash函数，改为使用#hash()进行调用。
 
@@ -129,17 +129,17 @@
 
     如果需要在MyBatis Mapper中使用@Cache和@CacheDelete，则需要使用com.jarvis.cache.mybatis.CachePointCutProxy 来处理。
 
-* ####2.13 优化多线程并发等机制, 代码调整如下：
+* #### 2.13 优化多线程并发等机制, 代码调整如下：
 
     ![Alt 优化多线程并发等机制](wait.png "优化多线程并发等机制")
 
     由于我们这里要实现的功能是，当前的线程要等待前一个正在运行线程的结果，但我们不知道前一个线程的执行到哪一步。有可能在我们要执行wait时，已经完成notifyAll了。通过调整逻辑变得更加严谨。
 
-* ####2.12 解决jdk1.8之前中 java.lang.NoSuchMethodError: java.util.Map.putIfAbsent 错误。
+* #### 2.12 解决jdk1.8之前中 java.lang.NoSuchMethodError: java.util.Map.putIfAbsent 错误。
 
-* ####2.11 @CacheDeleteKey中keyType 设置default，以实现向下兼容。
+* #### 2.11 @CacheDeleteKey中keyType 设置default，以实现向下兼容。
 
-* ####2.10 修改记录： 
+* #### 2.10 修改记录： 
 
     * 优化ConcurrentHashMap 使用，将以下代码：
 
@@ -159,7 +159,7 @@
 
     * 放弃使用 @CacheDeleteKey中keyType， 直接使用它的value值来判断是自定义缓存Key，还是默认生成的缓存Key。所以keyType 变得多余了。
 
-* ####2.9 修复以下几个问题 
+* #### 2.9 修复以下几个问题 
 
     * @Cache(expire=0, waitTimeOut=500),当expire=0时，将设置为永久缓存；waitTimeOut 用于设置并发等待时间(毫秒)。
 
@@ -172,21 +172,21 @@
 
     * 优化AbstractCacheManager类的loadData方法中线程同步锁。
 
-* ####2.8 com.jarvis.lib.util.BeanUtil.toString()方法中增加反射缓存，提升反射效率
+* #### 2.8 com.jarvis.lib.util.BeanUtil.toString()方法中增加反射缓存，提升反射效率
 
-* ####2.7 当参数类型为 Class，自动生成的缓存Key会出问题。（感谢zhaopeng 提供的代码）
+* #### 2.7 当参数类型为 Class，自动生成的缓存Key会出问题。（感谢zhaopeng 提供的代码）
 
-* ####2.5 2.6 当autoload=true，缓存Key中没有加上命名空间，对1.9及以上版本有影响
+* #### 2.5 2.6 当autoload=true，缓存Key中没有加上命名空间，对1.9及以上版本有影响
 
-* ####2.4 Jedis更新到2.8
+* #### 2.4 Jedis更新到2.8
 
-* ####2.3 AdminServlet 增加登录用户名和密码；
+* #### 2.3 AdminServlet 增加登录用户名和密码；
 
 * ####2.2 解决Hessian不能正确序列化BigDecimal问题
 
-* ####2.1 对Kryo进行测试，发现问题问题比较多，所以删除Kryo 支持，用户可以根据自己的情况实现ISerializer接口。优化HessianSerializer，提升性能，并将HessianSerializer作为默认的序列化和反序列化工具。
+* #### 2.1 对Kryo进行测试，发现问题问题比较多，所以删除Kryo 支持，用户可以根据自己的情况实现ISerializer接口。优化HessianSerializer，提升性能，并将HessianSerializer作为默认的序列化和反序列化工具。
 
-* ####2.0 增加了Hessian 和 Kryo 序列化支持，还是使用JDK自带的处理方法。修改方法如下：
+* #### 2.0 增加了Hessian 和 Kryo 序列化支持，还是使用JDK自带的处理方法。修改方法如下：
 
         <bean id="jdkSerializer" class="com.jarvis.cache.serializer.JdkSerializer" />
         <bean id="hessianSerializer" class="com.jarvis.cache.serializer.HessianSerializer" />
@@ -199,4 +199,4 @@
 
     虽然Kryo效率比较高，但使用Kryo会出现的问题比较多，所以还是慎重使用，系统经常维护的就不太适合使用，经过测试，改变属性名称，或删除中间的属性等情况都可能反序列出错误的值，所以如果遇到有减少或修改的情况要及时清里缓存。如果是增加属性则会反序列化失败，这正符合我们的要求。
 
-* ####1.9 增加了命名空间，避免不同的系统之支缓存冲突
+* #### 1.9 增加了命名空间，避免不同的系统之支缓存冲突

doc/deleteCache.md

@@ -1,6 +1,6 @@
-##缓存删除
+## 缓存删除
 
-###通过删除缓存，实现数据实时性
+### 通过删除缓存，实现数据实时性
 
 下面商品评论的例子中，如果用户发表了评论，要所有涉及到的前端页面立即显示该如何来处理？
 
@@ -26,7 +26,7 @@
         }
     }
 
-###批量删除缓存
+### 批量删除缓存
 
   在一些用户交互比较多的系统中，使用程序删除缓存是非常常见的事情，当我们遇到一些查询条件比较复杂的查询时，我们没有办法通过程序，反向生成缓存key,也就无法精确定位需要删除的缓存，但我们又不希望把不相关的缓存给误删除时。这时就可以使用下面介绍的批量删除缓存功能。
 

doc/idea.md

@@ -1,4 +1,4 @@
-###设计思想及原理
+### 设计思想及原理
 
 如下图所示：
 ![Alt 缓存框架](FlowChart.png "缓存框架")
@@ -24,7 +24,7 @@ AutoLoadHandler（自动加载处理器）主要做的事情：当缓存即将
 
 如果将应用部署在多台服务器上，理论上可以认为自动加载队列是由这几台服务器共同完成自动加载任务。比如应用部署在A,B两台服务器上，A服务器自动加载了数据D，（因为两台服务器的自动加载队列是独立的，所以加载的顺序也是一样的），接着有用户从B服务器请求数据D，这时会把数据D的最后加载时间更新给B服务器，这样B服务器就不会重复加载数据D。
 
-##为什么要使用自动加载机制？
+## 为什么要使用自动加载机制？
 
 首先我们想一下系统的瓶颈在哪里？
 
@@ -35,22 +35,22 @@ AutoLoadHandler（自动加载处理器）主要做的事情：当缓存即将
 
 注：上面提到的两种异步刷新数据机制，如果从数据层获取数据时，发生异常，则会使用旧数据进行续租。
 
-##如何减少DAO层并发
+## 如何减少DAO层并发
 
 1. 使用缓存；
 2. 使用自动加载机制，因“写”数据往往比读数据性能要差，使用自动加载也能减少写缓存的并发。
 3. 从DAO层加载数据时，**增加等待机制**（拿来主义）
 
 
-##使用规范
+## 使用规范
 
 1. 将调接口或数据库中取数据，**封装在DAO层**，不能什么地方都有调接口的方法。
 2. 自动加载缓存时，**不能**在缓存方法内**叠加（或减）**查询条件值，但允许设置值。
 3. DAO层内部，没使用@Cache的方法，不能调用加了@Cache的方法，避免AOP失效。
 4. 对于比较大的系统，要进行**模块化设计**，这样可以将自动加载，均分到各个模块中。
 
 
-##为了能让更多人使用此项目，一直在为具有更好的扩展性而努力，在以下几个方法已实现可扩展：
+## 为了能让更多人使用此项目，一直在为具有更好的扩展性而努力，在以下几个方法已实现可扩展：
 
 1. 缓存：现在已经支持Memcache、Redis、ConcurrentHashMap三种缓存，用户也可以自己增加扩展；
 2. AOP：项目中已经实现了Spring AOP的拦截。在Nutz官方项目中也实现了相关的插件：https://github.com/nutzam/nutzmore/tree/master/nutz-integration-autoloadcache