强大的Spring缓存技术(中)(转)
好,到目前为止,我们的 spring cache 缓存程序已经运行成功了,但是还不完美,因为还缺少一个重要的缓存管理逻辑:清空缓存.
当账号数据发生变更,那么必须要清空某个缓存,另外还需要定期的清空所有缓存,以保证缓存数据的可靠性。
为了加入清空缓存的逻辑,我们只要对 AccountService2.java 进行修改,从业务逻辑的角度上看,它有两个需要清空缓存的地方
-
当外部调用更新了账号,则我们需要更新此账号对应的缓存
-
当外部调用说明重新加载,则我们需要清空所有缓存
我们在AccountService2的基础上进行修改,修改为AccountService3,代码如下:
import com.google.common.base.Optional;
import com.rollenholt.spring.cache.example1.Account;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.cache.annotation.CacheEvict;
import org.springframework.cache.annotation.Cacheable;
import org.springframework.stereotype.Service;
/**
* @author wenchao.ren
* 2015/1/5.
*/
@Service
public class AccountService3 {
private final Logger logger = LoggerFactory.getLogger(AccountService3.class);
// 使用了一个缓存名叫 accountCache
@Cacheable(value="accountCache")
public Account getAccountByName(String accountName) {
// 方法内部实现不考虑缓存逻辑,直接实现业务
logger.info("real querying account... {}", accountName);
Optional<Account> accountOptional = getFromDB(accountName);
if (!accountOptional.isPresent()) {
throw new IllegalStateException(String.format("can not find account by account name : [%s]", accountName));
}
return accountOptional.get();
}
@CacheEvict(value="accountCache",key="#account.getName()")
public void updateAccount(Account account) {
updateDB(account);
}
@CacheEvict(value="accountCache",allEntries=true)
public void reload() {
}
private void updateDB(Account account) {
logger.info("real update db...{}", account.getName());
}
private Optional<Account> getFromDB(String accountName) {
logger.info("real querying db... {}", accountName);
//Todo query data from database
return Optional.fromNullable(new Account(accountName));
}
}
我们的测试代码如下:
import com.rollenholt.spring.cache.example1.Account;
import org.junit.Before;
import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class AccountService3Test {
private AccountService3 accountService3;
private final Logger logger = LoggerFactory.getLogger(AccountService3Test.class);
@Before
public void setUp() throws Exception {
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("applicationContext2.xml");
accountService3 = context.getBean("accountService3", AccountService3.class);
}
@Test
public void testGetAccountByName() throws Exception {
logger.info("first query.....");
accountService3.getAccountByName("accountName");
logger.info("second query....");
accountService3.getAccountByName("accountName");
}
@Test
public void testUpdateAccount() throws Exception {
Account account1 = accountService3.getAccountByName("accountName1");
logger.info(account1.toString());
Account account2 = accountService3.getAccountByName("accountName2");
logger.info(account2.toString());
account2.setId(121212);
accountService3.updateAccount(account2);
// account1会走缓存
account1 = accountService3.getAccountByName("accountName1");
logger.info(account1.toString());
// account2会查询db
account2 = accountService3.getAccountByName("accountName2");
logger.info(account2.toString());
}
@Test
public void testReload() throws Exception {
accountService3.reload();
// 这2行查询数据库
accountService3.getAccountByName("somebody1");
accountService3.getAccountByName("somebody2");
// 这两行走缓存
accountService3.getAccountByName("somebody1");
accountService3.getAccountByName("somebody2");
}
}
在这个测试代码中我们重点关注testUpdateAccount()方法,在测试代码中我们已经注释了在update完account2以后,再次查询的时候,account1会走缓存,而account2不会走缓存,而去查询db,观察程序运行日志,运行日志为:
01:37:34.549 [main] INFO c.r.s.cache.example3.AccountService3 - real querying account... accountName1
01:37:34.551 [main] INFO c.r.s.cache.example3.AccountService3 - real querying db... accountName1
01:37:34.552 [main] INFO c.r.s.c.example3.AccountService3Test - Account{id=0, name='accountName1'}
01:37:34.553 [main] INFO c.r.s.cache.example3.AccountService3 - real querying account... accountName2
01:37:34.553 [main] INFO c.r.s.cache.example3.AccountService3 - real querying db... accountName2
01:37:34.555 [main] INFO c.r.s.c.example3.AccountService3Test - Account{id=0, name='accountName2'}
01:37:34.555 [main] INFO c.r.s.cache.example3.AccountService3 - real update db...accountName2
01:37:34.595 [main] INFO c.r.s.c.example3.AccountService3Test - Account{id=0, name='accountName1'}
01:37:34.596 [main] INFO c.r.s.cache.example3.AccountService3 - real querying account... accountName2
01:37:34.596 [main] INFO c.r.s.cache.example3.AccountService3 - real querying db... accountName2
01:37:34.596 [main] INFO c.r.s.c.example3.AccountService3Test - Account{id=0, name='accountName2'}
我们会发现实际运行情况和我们预估的结果是一致的。
如何按照条件操作缓存
前面介绍的缓存方法,没有任何条件,即所有对 accountService 对象的 getAccountByName 方法的调用都会起动缓存效果,不管参数是什么值。
如果有一个需求,就是只有账号名称的长度小于等于 4 的情况下,才做缓存,大于 4 的不使用缓存
虽然这个需求比较坑爹,但是抛开需求的合理性,我们怎么实现这个功能呢?
通过查看CacheEvict注解的定义,我们会发现:
/**
* Annotation indicating that a method (or all methods on a class) trigger(s)
* a cache invalidate operation.
*
* @author Costin Leau
* @author Stephane Nicoll
* @since 3.1
* @see CacheConfig
*/
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface CacheEvict {
/**
* Qualifier value for the specified cached operation.
* <p>May be used to determine the target cache (or caches), matching the qualifier
* value (or the bean name(s)) of (a) specific bean definition.
*/
String[] value() default {};
/**
* Spring Expression Language (SpEL) attribute for computing the key dynamically.
* <p>Default is "", meaning all method parameters are considered as a key, unless
* a custom {@link #keyGenerator()} has been set.
*/
String key() default "";
/**
* The bean name of the custom {@link org.springframework.cache.interceptor.KeyGenerator} to use.
* <p>Mutually exclusive with the {@link #key()} attribute.
*/
String keyGenerator() default "";
/**
* The bean name of the custom {@link org.springframework.cache.CacheManager} to use to
* create a default {@link org.springframework.cache.interceptor.CacheResolver} if none
* is set already.
* <p>Mutually exclusive with the {@link #cacheResolver()} attribute.
* @see org.springframework.cache.interceptor.SimpleCacheResolver
*/
String cacheManager() default "";
/**
* The bean name of the custom {@link org.springframework.cache.interceptor.CacheResolver} to use.
*/
String cacheResolver() default "";
/**
* Spring Expression Language (SpEL) attribute used for conditioning the method caching.
* <p>Default is "", meaning the method is always cached.
*/
String condition() default "";
/**
* Whether or not all the entries inside the cache(s) are removed or not. By
* default, only the value under the associated key is removed.
* <p>Note that setting this parameter to {@code true} and specifying a {@link #key()}
* is not allowed.
*/
boolean allEntries() default false;
/**
* Whether the eviction should occur after the method is successfully invoked (default)
* or before. The latter causes the eviction to occur irrespective of the method outcome (whether
* it threw an exception or not) while the former does not.
*/
boolean beforeInvocation() default false;
}
定义中有一个condition描述:
Spring Expression Language (SpEL) attribute used for conditioning the method caching.Default is “”, meaning the method is always cached.
我们可以利用这个方法来完成这个功能,下面只给出示例代码:
@Cacheable(value="accountCache",condition="#accountName.length() <= 4")// 缓存名叫 accountCache
public Account getAccountByName(String accountName) {
// 方法内部实现不考虑缓存逻辑,直接实现业务
return getFromDB(accountName);
}
注意其中的 condition=”#accountName.length() <=4”,这里使用了 SpEL 表达式访问了参数 accountName 对象的 length() 方法,条件表达式返回一个布尔值,true/false,当条件为 true,则进行缓存操作,否则直接调用方法执行的返回结果。
如果有多个参数,如何进行 key 的组合
我们看看CacheEvict注解的key()方法的描述:
Spring Expression Language (SpEL) attribute for computing the key dynamically. Default is “”, meaning all method parameters are considered as a key, unless a custom {@link #keyGenerator()} has been set.
假设我们希望根据对象相关属性的组合来进行缓存,比如有这么一个场景:
要求根据账号名、密码和是否发送日志查询账号信息
很明显,这里我们需要根据账号名、密码对账号对象进行缓存,而第三个参数“是否发送日志”对缓存没有任何影响。所以,我们可以利用 SpEL 表达式对缓存 key 进行设计
我们为Account类增加一个password 属性, 然后修改AccountService代码:
@Cacheable(value="accountCache",key="#accountName.concat(#password)")
public Account getAccount(String accountName,String password,boolean sendLog) {
// 方法内部实现不考虑缓存逻辑,直接实现业务
return getFromDB(accountName,password);
}
注意上面的 key 属性,其中引用了方法的两个参数 accountName 和 password,而 sendLog 属性没有考虑,因为其对缓存没有影响。
accountService.getAccount("accountName", "123456", true);// 查询数据库
accountService.getAccount("accountName", "123456", true);// 走缓存
accountService.getAccount("accountName", "123456", false);// 走缓存
accountService.getAccount("accountName", "654321", true);// 查询数据库
accountService.getAccount("accountName", "654321", true);// 走缓存
如何做到:既要保证方法被调用,又希望结果被缓存
根据前面的例子,我们知道,如果使用了 @Cacheable 注释,则当重复使用相同参数调用方法的时候,方法本身不会被调用执行,即方法本身被略过了,取而代之的是方法的结果直接从缓存中找到并返回了。
现实中并不总是如此,有些情况下我们希望方法一定会被调用,因为其除了返回一个结果,还做了其他事情,例如记录日志,调用接口等,这个时候,我们可以用 @CachePut 注释,这个注释可以确保方法被执行,同时方法的返回值也被记录到缓存中。
@Cacheable(value="accountCache")
public Account getAccountByName(String accountName) {
// 方法内部实现不考虑缓存逻辑,直接实现业务
return getFromDB(accountName);
}
// 更新 accountCache 缓存
@CachePut(value="accountCache",key="#account.getName()")
public Account updateAccount(Account account) {
return updateDB(account);
}
private Account updateDB(Account account) {
logger.info("real updating db..."+account.getName());
return account;
}
我们的测试代码如下
Account account = accountService.getAccountByName("someone");
account.setPassword("123");
accountService.updateAccount(account);
account.setPassword("321");
accountService.updateAccount(account);
account = accountService.getAccountByName("someone");
logger.info(account.getPassword());
如上面的代码所示,我们首先用 getAccountByName 方法查询一个人 someone 的账号,这个时候会查询数据库一次,但是也记录到缓存中了。然后我们修改了密码,调用了 updateAccount 方法,这个时候会执行数据库的更新操作且记录到缓存,我们再次修改密码并调用 updateAccount 方法,然后通过 getAccountByName 方法查询,这个时候,由于缓存中已经有数据,所以不会查询数据库,而是直接返回最新的数据,所以打印的密码应该是“321”
@Cacheable、@CachePut、@CacheEvict 注释介绍
-
@Cacheable 主要针对方法配置,能够根据方法的请求参数对其结果进行缓存
-
@CachePut 主要针对方法配置,能够根据方法的请求参数对其结果进行缓存,和 @Cacheable 不同的是,它每次都会触发真实方法的调用
-@CachEvict 主要针对方法配置,能够根据一定的条件对缓存进行清空