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=<seconds>

这个指令指定了当前的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: <etag_value> 当前资源内容的唯一标识符

将请求发送给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