前言
- 缓存是一种很好的程序设计思路,大范围应用在计算机科学的各个领域,比如Redis, Http,JVM(缓存一致性)等等。所以我们可以把它当做一种思维模型来学习
- 本文仅针对Http1.1及以后的协议,且只对http中缓存的应用做解释
缓存解决的问题
- 加速程序的运行速度,提高效率
缓存带来的问题
使用缓存会给程序带来一定的复杂性,大概总结几个缓存带来的问题如下
- 缓存失效时机如何确定?
- 缓存失效后的如何更新?
- 缓存的线程安全问题?
- 缓存击穿后如何处理?
- 如果有多级缓存如何配合?
Http的缓存是一种相对简单的缓存模型,主要存在的问题是缓存失效时机,下面我们直接上图分析

图解:可以看到http其实有两层缓存(只针对get请求),一层是客户端缓存,一层是服务端缓存,那么带来了两个问题,客户端和服务端的缓存何时失效?如何控制客户端和服务端缓存的存在?
总的来说http缓存控制是通过Cache-Control这个字段来实现的
先回答第一个问题
- 如何判断客户端缓存失效?
答:用第一次请求的响应报文的max-age字段判断
- 如何判断服务端缓存失效?
答:客户端缓存失效之后,请求服务端,服务端通过请求报文中的If-Modified-Since字段(文件的最后修改时间)来判断要下发给客户端的文件是否过期? 但是这样的判断方式不严谨,判断一个请求资源是否失效,通过修改时间不是充分必要条件(它只能判断是否过期,不能判断是否失效),还需要有请求资源的hashcode,此时会通过请求报文中的If-None-Match字段与请求资源的hashcode比较去判断是否失效。其中If-None-Match字段是第一次请求的时候的响应报文中的eTag的值。
这里涉及到字段比较多,总结下

然后第二个问题:
- 通过no-cache与no-store去控制,no-cache表明不用客户端缓存,no-store表明两个缓存都无效。如果客户端想使用max-age缓存,在请求报文上加上字段,如果你用的retrofit,可以这么加
kotlin
@Headers("Cache-Control:max-age=120")
@GET("/xxx")
fun getJson(): Response<String>
总结

- 客户端请求一个2分钟的客户端缓存
- 服务端返回max-age = 120, 指定客户端失效时间为2分钟
- 再两分钟后,缓存失效,请求服务端,此时比较文件和eTag == If-None-match是否一致,一直使用缓存,不一致走服务端