变通实现微服务的per request以提高IO效率(三)
效率
变通实现微服务的per request以提高IO效率(二)遗留一个问题，如何正确的释放存储在ThreadLocal中的缓存，最理由就是在我们请求的方法执行完成后去清除缓存。
Filter
由于我的项目是基于dubbo的，所以可以利用dubbo提供的Filter机制去完成这件事情，可以看下filter的地位：
最终的效果：
创建ThreadLocalCacheFilter
创建一个类让其实现Filter接口，就一个方法invoke,这个invoke方法的功能类似于AOP的Around方法，我们想清除缓存就有地方操作了，只需要在return的前面，invoker.invoke方法后面添加相应的清除逻辑即可达到目的。由于缓存是线程独有的，所以直接清空就可以。
由于Filter加载机制问题，在Filter中使用Spring的注解是有点问题的，暂时是通过手动获取Bean的方式来加载cacheManager,后面在看dubbo的filter加载机制时会有简单提到。大家如果有其它好的方案可以告诉我
@Activate
public class ThreadLocalCacheFilter implements Filter {
private Logger logger = LoggerFactory.getLogger(getClass().getName());
@Autowired
private CacheManager cacheManager;
private void clearCache(){
if(null==cacheManager){
ApplicationContext appCtx = ApplicationContextUtils.getApplicationContext();
cacheManager= appCtx.getBean(ThreadLocalCacheManager.class);
}
Collection<String> cacheNames= this.cacheManager.getCacheNames();
if(null!=cacheNames) {
for(String cacheName :cacheNames) {
this.cacheManager.getCache(cacheName).clear();
}
}
}
@Override
public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
Result result=invoker.invoke(invocation);
this.logger.info("release cache start");
this.clearCache();
this.logger.info("release cache end");
return result;
}
}
@Active注解
要想激活filter，我们需要在创建的自定义filter类上加载@Active注解,看下它的相关参数，也可以不配置
- group，条件之一，指定是服务端还是消费端
- value，条件之一，一般就是这个filter的英文名称，在dubbo配置文件中使用的
- before，排序的信息，比如排在哪些filter之前
- after，排序的信息，比如排在哪些filter之后
- order，排序的信息，应该是值越小排在最前面
加载Filter
编写的扩展filter，dubbo需要加载成功后才能使用，dubbo总共从resource下面的三个目录中加载filter
- META-INF/services/
- META-INF/dubbo/
- META-INF/dubbo/internal/
创建纯文件文件com.alibaba.dubbo.rpc.Filter放入对应的目录，然后写入需要使用的filter信息
threadLocalCacheFilter=com.filter.ThreadLocalCacheFilter
应用Filter
在dubbo配置文件中增加如下内容:
<dubbo:provider filter="threadLocalCacheFilter" />
Dubbo Filter
dubbo有这样一个类ProtocolFilterWrapper,它负责加载项目中所有的filter，并负责链式调用。
想学习设计模式的可以看看这个类是如何使用职责链模式的
这里只看一个方法就可以了：
- ExtensionLoader加载所以实现了Filter接口的类
- 根据过滤条件过滤filter，里面有排序
- 循环调用所有符合条件且经过排序的filter
注意变量next,当前方法在执行invoke方法时，将调用传递到了next。这里应该会有最后一个终结器来处理实际方法的执行。
private static <T> Invoker<T> buildInvokerChain(final Invoker<T> invoker, String key, String group) {
Invoker<T> last = invoker;
List<Filter> filters = ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl(), key, group);
if (filters.size() > 0) {
for (int i = filters.size() - 1; i >= 0; i --) {
final Filter filter = filters.get(i);
final Invoker<T> next = last;
last = new Invoker<T>() {
public Class<T> getInterface() {
return invoker.getInterface();
}
public URL getUrl() {
return invoker.getUrl();
}
public boolean isAvailable() {
return invoker.isAvailable();
}
public Result invoke(Invocation invocation) throws RpcException {
return filter.invoke(next, invocation);
}
public void destroy() {
invoker.destroy();
}
@Override
public String toString() {
return invoker.toString();
}
};
}
}
return last;
}
总结
结过三篇笔记，从最初的Context问题，到缓存的释放，基本可以非常方便的使用请求级的缓存了。这里需要注意的是需要明确哪些方案是适合做请求级缓存的。比如查询用户，有些操作中先插入用户然后再查询，如果查询的是被标记了请求级缓存的方法就会有问题。
