cache

context

随着APP的用户访问量越来越多，我们的APP接收的请求也就越多，也就意味着我们的APP和DB所做的计算也越来越多。

但是我们的APP的资源是有限的，DB的吞吐量也是有限的，那么如何优化你的APP，使得其在有限的资源下拥有更大的吞吐量呢？

有一个好办法就是引入缓存缓存，使得每一个环节的请求都可以从缓存中直接获取目标数据并返回，这样做的好处：

减少APP的计算量或者DB的访问量
减少请求时间
提高APP的吞吐量

What is cache?

cache是一种可以存储资源备份，并且在请求的时候将这个备份的资源返回的一种技术。

当web缓存中存储了某一个请求的资源的备份，那么浏览器会拦截请求并返回其副本，而不是从原始服务器重新下载。

对于网站来说，缓存是提升performance的一个主要组件，但是并非所有的资源都是不变的，因此使用cache的同时需要正确的配置cache，避免取到outdated的cache。

缓存可以出现在任何一个环节,

image.png

根据cache所在的不同缓解，我们把cache可以分成几大类：

浏览器缓存(HTTP Cache/browser cache)
每一个浏览器都拥有的本地缓存，但是这种cache只能被一个用户使用
proxy cache
是一种shared cache，可以被多个用户使用，用于减少网络延迟以及和网络负载。因此此类的cache通常会离用户比较近，比如常见的CDN
gateway cahce
也是shared cache，非常类似于proxy cache，但是通常出现在server side，比如右图中3，常见的比如Redies，为了提升server的吞吐量

因此cache基本分成两类：

private cache
这种cache只能被一个用户使用
shared cache
这种cache可以被多个user使用

image.png

这边文章中，我们主要介绍两种cache：

Private browser caches
浏览器会缓存所有通过HTTP load回来的文档，只能被当前的用户使用，会在看那些已经浏览过的网站上其作用。
Shared proxy caches
shared cache存储的response可以被多个用户使用。

Note
我们通常只会cache http response，而且只会cache GET请求的response，这种cache的key通常是请求的URI

因此接下来我们主要聊一聊HTTP Response的cache简称HTTP cache。

How to Controll cache

我们通常可以使用HTTP header来定义对当前请求的Response的cache policy。

常见的用于定义cache policy的header有：

Cache-Control header

如果想要某一个http请求的response被缓存，可以通过在http request header中设置Cache-Control field, 这个field有很多不能的value：

不cache

Cache-Control: no-store

Cache-Control的value是no-store，也就意味着不要在任何地方存储该请求的response，也就是不cache

cache但是需要验证

Cache-Control: no-cache

Cache-Control的value是no-cache，并不意味着说不要cache，

第一次发送请求的时候浏览器或者CDN可以cache住response，
但是随后的请求，即使这个cache可以被hit，也要先给server发送一个验证请求，询问是否使用当前命中的cahce

因此也就意味着，每一个request都得发送给server先做一次cache的validate，再决定是否使用cache

Private and public caches

Cache-Control: private
Cache-Control: public

我们知道cache其实可以被分成两大类：

private cache
shared cache

区别就是cache只能被一个人使用还是多个人，private和 public cache顾名思义也是同理.

private value意味着只能被一个用户使用，也就是意味着response不能存储在CDN上，通常指示的是，这个reponse只能被cache在浏览器。

public value意味着当前的reponse可以被任何类型的cache存储，比如CDN浏览器等。 request headre中设置了这个value，也能让一些本来不能被cache的response，现在变成cacheable response。

cacheable response
顾名思义 cacheable response 指的就是可以被cache的http response。并非所有的HTTP response都可以被cache，通常取决于request method，response code，http response headers.

比如常见的GET、HEAD请求的response都是cachable，比如PUT、DELETE就不是cachable。

cache alive time

Cache-Control: max-age=31536000
// max-age=

这个指令指定了当前的response能被cache的最大时间，也就是cached valid的时间，这里只是一个时长，从request发出作为时间的起点。

也可以使用Expires header设置cache alive的时间：

Expires: Wed, 21 Oct 2015 07:28:00 GMT

这个指令可以直接设置一个cache过期时间。

Note

当时需要注意的是， Cache-Control: max-age=的优先级高于Expires，也就是header中如果同时存在这个两个value，那么Cache-Control: max-age=会起作用

Validation

Cache-Control: must-revalidate

Freshness

一旦资源被存储在cache中，理论上就会永久留在cache中。但是cache的存储空间并不是无限，因此cache中的资源会周期性的被移除，这种过程被称为cache eviction（缓存驱逐）。当然如果一直在缓存中keep某种资源也是有风险的，因为该资源可能在服务器端已经改变了，理论上我们需要更新该资源，但是由于HTTP是一个client-server协议，服务器并不能在资源改变的时候主动联系client或者CDN修改cache，为了解决该问题，需要在资源被cache之前，提前商量好资源的过期时间（expiration time）。

因此，在过期时间之前，cache中的该资源就是fresh(新鲜的)，在过期时间之后，cache中的该资源就是stale(过时的)，

请注意
cache中过时的资源，并不会被驱逐或忽略。当cache收到一个请求过时资源的request，那么cache会加上请求头

If-None-Match:  当前资源内容的唯一标识符

将请求发送给server，去检查当前从cache中拿出的过时资源是否是新鲜的。如果是，那么server会返回304（Not Modified），并且response中不会带有资源，让你直接使用cache中该资源。如果不是，那么server会返回最新的资源

image.png

如何检测cache是否fresh

根据请求的header中的两个字段Cache-Controll或者Expires 来决定，但是Cache-Controll的优先级高于Expires。

如果Cache-Controll的value设置的是max-age=N，也就是cache最长存活的秒数。需要获取第一次请求的时间，和max-age进行对比，计算出是否过时
如果Cache-Control的max-age不存在，那么需要检查Expires header，Expires的value指的是cache过期的时间

Expires: Wed, 21 Oct 2015 07:28:00 GMT

浏览器会取出当前response中的date字段，使用date字段（当前时间）减去expires中的时间，决定当前的cache是否过期。

但是如果cache control max age存在的话，这个字段会被直接忽略

如果cache control以及expires都没有设置，那么我就会使用一种叫做启发式算法（heuristic）计算。

首先找到header中是否存在Last-Modified字段，如果存在，那么cache的expireTime就可以通过下面的方式计算出来：


freshnessLifetime = (date(header) - Last-Modified)/10
expirationTime = responseTime + freshnessLifetime - currentAge

Cache validation

有一些cache由于种种原因，可能无法被直接使用，需要被服务器通过某一种方式验证有效之后才能被使用。

因此对于这类cache，在你使用之前：

你需要带上该cache的相关信息给服务器发送请求。
服务器验证该cache的可用性
- 如果cache可用，服务器会直接只返回304，浏览器会直接使用之前的cache
- 如果cache不可用，服务器会返回真实的资源以及该资源相关的cache信息，浏览器会使用新的资源，并存储该资源以及和该资源一同返回的cache信息

什么情况下cache需要被服务器validaiton后才能使用？

cache的response header中设置了Cache-Control: must-revalidate
浏览器可以专门设置，在每次加载时对使用的cache强制进行验证。
cache的response header中设置了ETags字段，
cache的response header中设置了Last-Modified字段

当服务器接收到了一个validation request，服务器可能会做出两种反应：

服务器直接忽略validation，将这个请求当做是一个正常的请求，直接返回200加response
服务器验证cache之后发现可用，返回304和空response，示意浏览器直接使用现有的cache