前言
- 缓存是一种很好的程序设计思路，大范围应用在计算机科学的各个领域，比如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是否一致，一直使用缓存，不一致走服务端