【今日完成】

今天看了一遍Spring实战中关于Redis的部分。

关于Redis缓存，可以有两种方式来实现，一种是注解，一种是用Xml配置。

先来看看注解：

可以看到这是个典型的配置类，@configuration表示它是配置类，而@EnableCaching表示启用了缓存。

Spring里面有四个注解来声明缓存规则。

我们可以看到，@Cacheable和@CachePut注解都可以填充缓存，
但是它们的工作方式略有差异。
@Cacheable首先在缓存中查找条目，如果找到了匹配的条目，那么
就不会对方法进行调用了。如果没有找到匹配的条目，方法会被调用
并且返回值要放到缓存之中。而@CachePut并不会在缓存中检查匹
配的值，目标方法总是会被调用，并将返回值添加到缓存之中。

@CacheEvict并不会往缓存中添加任何东西。相反，如果带
有@CacheEvict注解的方法被调用的话，那么会有一个或更多的条
目会在缓存中移除。

那么在什么场景下需要从缓存中移除内容呢？当缓存值不再合法时，
我们应该确保将其从缓存中移除，这样的话，后续的缓存命中就不会
返回旧的或者已经不存在的值，其中一个这样的场景就是数据被删除
掉了。

===================================================================

说完了注解，来看看Xml配置文件来配置缓存：

cache命名空间定义了在Spring XML配置文件中声明缓存的配置元素。

下面是一个小例子：

我们首先看到的是<aop:advisor>，它引用ID
为cacheAdvice的通知，该元素将这个通知与一个切点进行匹配，
因此建立了一个完整的切面。在本例中，这个切面的切点会在执
行SpittleRepository的任意方法时触发。如果这样的方法被
Spring应用上下文中的任意某个bean所调用，那么就会调用切面的通
知。
在这里，通知利用<cache:advice>元素进行了声明。
在<cache:advice>元素中，可以包含任意数量的<cache:caching>元素，这些元素用来完整地定义应用的缓存规
则。在本例中，只包含了一个<cache:caching>元素。这个元素又
包含了三个<cache:cacheable>元素和一个<cache:cacheput>
元素。
每个<cache:cacheable>元素都声明了切点中的某一个方法是支
持缓存的。这是与@Cacheable注解同等作用的XML元素。具体来
讲，findRecent()、findOne()和findBySpitterId()都声明
为支持缓存，它们的返回值将会保存在名为spittleCache的缓存
之中。
<cache:cache-put>是Spring XML中与@CachePut注解同等作用
的元素。它表明一个方法的返回值要填充到缓存之中，但是这个方法
本身并不会从缓存中获取返回值。在本例中，save()方法用来填充
缓存。同面向注解的缓存一样，我们需要将默认的key改为返回
Spittle对象的id属性。
最后，<cache:cache-evict>元素是Spring XML中用来替代
@CacheEvict注解的。它会从缓存中移除元素，这样的话，下次有
人进行查找的时候就找不到了。在这里，调用remove()时，会将缓
存中的Spittle删除掉，其中key与remove()方法所传递进来的ID
参数相等的条目会从缓存中移除。

在这个过程中，我们讨论了缓存实际上是一种面向切面的行为。
Spring将缓存实现为一个切面。在使用XML声明缓存规则时，这一点
非常明显：我们必须要将缓存通知绑定到一个切点上。

【今日收获】

看了一遍Spring实战的重点章节，看懂了很多以前看不懂的东西，这应该就叫做温故而知新吧。

【明日计划】

在程序中正式使用Redis缓存

【任务进度】

这两天就会结束，已经是最后的步骤了。

http://task.ptteng.com/zentao/project-burn-268.html