使用 MockFilterChain 来完成从入口层对业务服务的执行调用

之前进行filter层的cache操作时,并不能完成对后端调用的续命操作,即每次的缓存都是被动触发。当存在调用频率很高的请求时,如果能在缓存快过期时主动地触发后端的重新请求,那就能保证前端的请求始终均为命中缓存层,在性能上会有大大地提高。相应的策略如下:

  1. 首次访问时缓存数据,首次调用时间,过期时间
  2. 每次命中缓存时判断是否应该进行缓存续命
  3. 如果续命,则在返回原有缓存数据的同时,使用异步线程模拟正常访问,以强制使用业务的调用以更新缓存

这里面的第3步,并没有直接将旧有缓存进行重新设置ttl,而是再次请求。主要的考虑在于潜在的旧缓存可能不一致的问题,并且因为使用了异步调用,因此对实际上的前端访问是没有任何影响的。

本文的主要思路参考于(原文为nginx+lua,这里同样适用):
https://segmentfault.com/a/1190000003874328

本文的缓存工作点为Filter层,因此对后端的访问也同样起始于此点,可以理解为从此处继续后续的流程。但如果直接调用 FilterChain.doFilter,则会因为之前的请求已经结束了,此调用将直接报 类似 NPE这种错误。即一个 filterChain 不能即返回前端数据,同时又在新线程时继续原来的处理逻辑。

这里使用了spring-test 中的 mockFilterChain来完成相应的处理。整个思路来源于 AutoConfigureMockMvc 中创建起mockMvc的处理过程。
本文只考虑 GET 请求的处理.

继续阅读“使用 MockFilterChain 来完成从入口层对业务服务的执行调用”