spring cache缓存之我见
最近需要学习一下cache的缓存，正好写篇博文
缓存
联系到我之前看到的队列文章，正好提到队列的数据接口用来进行缓存。
对于机器而言，每一次的访问，程序都会按照步骤去执行一遍。但是比如同一个请求，对于服务器而言每次反馈的内容都是一样的，为了避免这种资源的浪费，对于一些重复的操作，而且结果往往是稳定不变的，可以使用缓存。缓存操作就是将第一真实查询的结果进行存储，后续的操作，就直接返回结果，而不再去真正的查询。
这里其实还要提到一个概念，无状态。我们的互联网http请求就是无状态的。
·
无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后，服务器根据请求，会给我们发送数据过来，但是，发送完，不会记录任何信息。
所以为了避免这中傻瓜式无脑的重复请求，必须想个点子治治了
Caching让经常会用到的数据，变得立即可用。
spring缓存
spring现在的很多方式都是有两种的：
- 注解
- XML配置文件
注解，可以让很多的配置变得更加的简单，xml配置文件的好处是，让配置脱离代码，方便更改。
有几个内容：
- 缓存支持
- 配置缓存管理器
- 使用Ehcache缓存
- 使用Redis缓存
- 使用多个缓存管理器
- 为方法添加注解以支持缓存
- 填充缓存
- 将值放到缓存之中
- 自定义缓存Key
- 条件化缓存
- 移除缓存条目
- 填充缓存
- 使用XML声明缓存
- 配置缓存管理器
有个比较好的地方需要提一下，上文中说到的可以让配置文件和代码脱离，个人认为这是一个非常好的理念，配置和代码隔离开来。除开这样的提前分离，另外的一种方式是基于原有代码进行开发有着极大的好处和便利。（你总不能在源码上给每个想要缓存的代码方法添加一个注解！）
可以让我们很便利的通过切面之类的加上配置文件，在不修改源代码的情况下进行功能改造。
Spring填充缓存和移除缓存
到了今天要讲的主要内容了。
讲一下，spring提供的四个缓存注解
| 注解 | 描述 |
|---|---|
| @Cacheable | 表明Spring在调用方法之前，首先应该在缓存中查找方法的返回值。如果这个值能够找到，就会返回缓存的值。否则的话，这个方法就会被调用，返回值会被放到缓存之中 |
| @CachePut | 表明Spring应该将方法的返回值放到缓存中，在方法的调用之前不会去检查缓存中是否有对应的返回值，方法始终都会被调用 |
| @CacheEvict | 表明Spring应该在缓存中清除一个或者多个条目 |
| @Caching | 分组注解，能够同时应用多个其他的缓存注解 |
@Cacheable和@CachePut的共有属性
| 属性 | 类型 | 描述 |
|---|---|---|
| value | String[] | 要使用的缓存名称 |
| condition | String | SpEL表达式，如果得到的值是false的话，不会将缓存应用到方法调用上 |
| key | String | SpEL表达式，用来计算自定义的缓存key |
| unless | String | SpEL表达式，如果得到的值是true的话，返回值不会放到缓存中 |
重要的信息讲完了，现在讲一下理解它的思路和模式。
比如一个方法getUserNameById(int id)，根据用户ID获取用户名称，返回值固定不变。
ok给它带上@Cacheable的帽子，发现有个李二蛋的喜欢查自己的名字，那好针对这个小伙伴做缓存，每次他用自己的id110去查询用户名的时候，捕获。用condition，#id = 110 SpEL，然后给他一个key值，leg+#id,坐好。
第一次用户ID，110，发现满足缓存条件，在数据库查出来，他叫李二蛋，放到缓存中，缓存里有了{"leg110","李二蛋"}。
第二次查，直接在缓存根据leg110，把李二蛋拿出来。
。。。
第N次查，直接在缓存根据leg110，把李二蛋拿出来。
李二蛋受不了了，这名字太土了，他想变得更强，所以充值了10000，要改名字，给不给改。
当然给改，altNameById(int id)，给他一个帽子，@CachePut，坐好，条件但是针对贵族李二蛋的id，所以condition依然是#id = 110 ，key当然也没有变化。然后，执行方法，修改数据库的内容，拿到换回的值，放到缓存中，再去getUserName于是变成了
第一次查，用户ID，110，进行名称查询，发现满足缓存条件，在数据库查出来，他叫李二蛋，放到缓存中，缓存里有了{"leg110","李三强"}。
第二次查，直接在缓存里面拿出来。
。。。
第N次查，在缓存里面直接拿出来。
李三强还是不甘心，能不能变得更强，他觉得是缓存害了他，于是找关系，去掉缓存，ok，背后的人很强，如是，delCacheById(int id)给他一个帽子，@CacheEvict，可以去删除缓存，条件和key当然都不变，然后去掉李三强的缓存。
这时候再去getUserName
又变成了
第N+1次用户ID，110，发现满足缓存条件，在数据库查出来，他叫李二蛋，放到缓存中，缓存里有了{"leg110","李三强"}。
第N+2次查，直接在缓存根据leg110，把李三强拿出来。
。。。
第2N次查，直接在缓存根据leg110，把李三强拿出来。
就是这样。