大型分布式系统下缓存应该怎么玩，才能用得高效

大家好，今天我们来聊一聊在大型分布式系统中，缓存应该怎么玩，从毕业到现在也有三年多了，大大小小的系统也经历了几十个，今天就从各个角度来讨论一下，我们的不同的缓存应该怎么玩，才能用的高效。

我们团队现在做的是直播类的产品，就拿抖音来说，比如说要开发一个榜一大哥、榜二大哥等各类大哥的排行榜单，要怎么开发，对于抖音这个dau十亿级别的产品，缓存的设计肯定是家常便饭。

对于一个百万、千万级别的接口调用，若是没有缓存的设计，直接打到数据持久层，那将是毁灭性的灾难。之前我就经历过，一个接口一天几百万次的调用，因为缓存的设计不严谨，缓存失效后，瞬间直接打在数据库层，幸好有告警，及时修复，差点就领了p0的故障。

大体来说缓存分为客户端缓存和服务端缓存，客户端缓存我们比较常见的就是浏览器缓存，也就是通过http进行控制的缓存。

客户端缓存

基于请求-应答模式下，在大多数场景下客户端都是通过https协议，请求后台获取数据，若是高频的接口一天几百万次的调用，即使短时间的客户端缓存也会带来高效的收益。

因为客户端到服务端要经过漫长的网络链路，多变的网络环境，数据包可能小的几十K到大的数据包几十M，这样就能够省去复杂多变的网络请求的时间。

客户端缓存减少了客户端到服务端之间的通信次数以及成本，只要缓存可用，就能够及时响应数据。

客户端缓存常见的也就是浏览器缓存，简而言之也就是http缓存，不知道大家在实际开发过程中有没有用过这段代码：

ResponseEntity.ok().cacheControl(CacheControl.maxAge(3, TimeUnit.SECONDS)).body()

看他的包，他就是属于springframework框架下http包下的一个工具类。

import org.springframework.http.CacheControl;
import org.springframework.http.ResponseEntity;

在浏览器缓存中，http协议header有这么个key-value字段进行控制，叫做Cache-Control：max-age=30，max-age标志该资源在客户端缓存多少秒。

假如max-age=0，表示不缓存数据，除了max-age可以控制数据的缓存状态，还有以下三个属性来控制缓存状态no_store、no_cache、must-revalidate。

1. no_store表示不缓存数据，每次都去服务器获取。
2. no_cache看起来也是不缓存的意思，但是它表示的意思是可以缓存的，只不过在使用缓存之前，都要去服务器验证数据是否有效，是否过期，是否是最新版本。
3. must-revalidate和no_cache有点类似，就是缓存不过期的话可以继续使用，过期了就需要去服务器验证一下。

除了Cache-Control可以使用客户端缓存，在http里面还有一个条件请求的header更加智能的使用客户端缓存。

条件请求是基于响应报文返回的“Last-modified”和“ETag”实现的。Last-modified资源最后的一次修改时间，ETag则表示资源的唯一标识，你可以理解为只要资源修改后都不一样了。

再次请求的时候在请求头里面就会带上"If-None-Match：ETag返回的值"，去验证资源是否有效。

假如有效的话，就会返回"304 Not Modified"，表示缓存资源有效还可以继续使用。

​但是这种方式我较少使用，基本上使用Cache-Control就够了，控制好实效的时间，一般的场景都是允许短暂的不一致。

除了客户端能够发送Cache-Control之外，客户端也能够发送Cache-Control两者进行协商使用客户端缓存的方案。

像我在浏览器访问一个连接，在输入框敲一下回车，Request的Headers里面就有Cache-Control：max-age = 0，表示不使用缓存，直接去后台获取数据。

​所以Cache-Control来控制客户端缓存也不太好控制，要两者协商好，但是Cache-Control有一个好处就是可以控制CDN缓存。

服务端缓存CDN缓存

上面聊到Cache-Control来控制客户端缓存，它也同时影响CDN缓存，告诉CDN客户缓存这个接口的数据。

CDN服务一般是由第三方提供的内容分发网络服务，主要是用于缓存静态的数据，比如：图片、音频、视频，这些数据，都是不不变的，那么命中率就很高。

不用回源获取数据，效率高，毕竟使用CDN的费用高，一般小公司也不会用，可能大公司采用。

CDN厂商花费大价钱在全国各地建立CDN的服务站点，用于用户的就近访问，减少响应时间。

所以这个对于应用层的来说是0开发的，一般只要在你的服