之前进行filter层的cache操作时，并不能完成对后端调用的续命操作，即每次的缓存都是被动触发。当存在调用频率很高的请求时，如果能在缓存快过期时主动地触发后端的重新请求，那就能保证前端的请求始终均为命中缓存层，在性能上会有大大地提高。相应的策略如下:
- 首次访问时缓存数据，首次调用时间，过期时间
- 每次命中缓存时判断是否应该进行缓存续命
- 如果续命，则在返回原有缓存数据的同时，使用异步线程模拟正常访问，以强制使用业务的调用以更新缓存
这里面的第3步，并没有直接将旧有缓存进行重新设置ttl，而是再次请求。主要的考虑在于潜在的旧缓存可能不一致的问题，并且因为使用了异步调用，因此对实际上的前端访问是没有任何影响的。
本文的主要思路参考于(原文为nginx+lua，这里同样适用):
https://segmentfault.com/a/1190000003874328
本文的缓存工作点为Filter层，因此对后端的访问也同样起始于此点，可以理解为从此处继续后续的流程。但如果直接调用 FilterChain.doFilter,则会因为之前的请求已经结束了，此调用将直接报 类似 NPE这种错误。即一个 filterChain 不能即返回前端数据，同时又在新线程时继续原来的处理逻辑。
这里使用了spring-test 中的 mockFilterChain来完成相应的处理。整个思路来源于 AutoConfigureMockMvc 中创建起mockMvc的处理过程。
本文只考虑 GET 请求的处理.