前几天，我们讲到了为何引入缓存且应该什么时候引入，并且讲到了我们生产中缓存的读写策略是什么，忘记了的可以自行去文章列表看下，同时又单独深入讲解了redis哨兵机制（Redis 哨兵机制以及底层原理深入解析，这次终于搞清楚了）和缓存穿透问题的解决方案（烦人的缓存穿透问题，今天教就你如何去解决）。至此，我们现在的系统架构已经是这样子的了

于架构图我们可以看出，我们现在使用了分布式缓存来加速动态请求的各种数据，但是，我们的系统中其实还有很多的静态资源的，并且请求量也是超级大的。例如：

移动端APP，有很多的图片，小视频以及流媒体等。
对于网站来说，不仅有上面那些资源之外，还有大量的HTML 文件，css文件以及Javascript文件等。

现在我们的一个商城里面，有很多的商品图片，并且详情页还有产品介绍视频，目前这些静态资源均是放在Nginx服务器上的，请求量很大，并且这些文件对于访问速度要求极高，并且占据很高的带宽。这里就会很有可能出现访问速度变慢，将带宽占满从而影响我们后端动态请求。这个时候我们就需要考虑该怎么去对这些静态资源做加速了。

如何思考加速

首先我们想一下可不可以也用分布式缓存来存储达到加速的目的呢？答案肯定是不行的，因为：

图片或者视频文件大小都不小，在几兆到几百兆之间。
我们的用户是遍地全国各地的甚至还有国外用户，需要让用户能很快的得到相应，即就近访问，我们不能全国各地都建机房去部署缓存，不现实。
图片或视频信息文件很大，访问量又极高，这样，如果自建机房带宽肯定是会面临极大的风险。

因此，我们不能自建机房来加速静态资源，我们需要在我们的应用服务器外层加一层静态资源处理的组件，并且还能遍地全国各地让用户能就近访问，还能让这些缓存命中率很高，以至于尽量减少回源到我们自己的业务服务器，这种技术就是我们下面要说的CDN。

CDN核心技术

CDN 其实就是网络分发的一种技术，它将我们的静态资源分发到各个地理位置不同的机房服务器上，这样就能实现用户就近访问的问题，且加快静态资源的访问速度。

你可能会说，cdn这玩意我们开发又用不到，不用去掌握的吧，其实不然，建议你不要只是将自己一直放在只是开发的位置，你要有掌控全局的决心，很多cdn排查的工作都是需要资深工程师才能干的，所以你要了解这门技术，现在假如让你来配置cdn和排查CDN问题，你可能就会因为自身技术壁垒而感到束手无策。

首先，我们来看看搭建一个CDN系统需要考虑的两个关键点：

怎样才能让用户请求先映射到CDN服务器上，这应该是最基本的了。
怎样根据用户所处的地理位置，选出离他最近的CDN节点给用户访问。

接下来，我们就基于上面考虑点来一起来看看CDN技术是怎么实现静态资源的加速。

如何将用户请求落到CDN服务器上

12306网站我们应该都不陌生，它是有很多的cdn节点来让我们就近访问提供静态资源加速的，而我们输入的网址就是12306自己家的网址，并不是cdn的ip。这是为什么呢？因为如果直接提供给用户cdn 节点IP的话，如果IP改变怎么办，那所有的静态资源都得改变地址，这种是很不靠谱的，所以都是直接给我们服务的自己家域名，然后隐藏住CDN 的IP，那这种机制该怎么做呢？其实大家应该能猜得到，就是运用DNS 进行域名映射。

DNS（Domain Name System）就是一个存储域名和 IP 映射的分布式数据库，其中域名解析返回的结果有两种：

直接返回域名对应的 IP 地址。
返回另一个域名，即将当前域名解析到另一个域名，会跳转到另一个域名解析上，现在我们就是通过这种方式来解决上面域名映射问题

下面我们就来看看具体的是怎么操作的。

假设我们的一级域名为 a.com ，那么我们就可以将图片服务域名定义为“img.a.com”，然后将这个域名的解析结果配置到CDN提供的域名上。例如，ucoud提供一个这样的域名“78f98.cdn.ucloud.com.cn”，我们的系统图片地址是这个样子"img.a.com/100.jpg"。

用户在请求100.jpg 地址的时候，DNS服务器就会将这个域名解析到78f98.cdn.ucloud.com.cn 域名上，然后再将这个域名解析到CDN的IP地址，这样就得到了CDN上资源数据了。

我们知道其实DNS解析是有个问题的就是，因为域名解析过程是分好几个级别的，每一级有专门的域名服务器承担其解析的职责，所以，域名的解析过程有可能需要跨越公网做多次 DNS 查询，在性能上是比较差的。

经过了向多个 DNS 服务器做查询之后，整个 DNS 的解析的时间有可能会到秒级别，那我们应该解决这个问题呢？

这里，我就将我们在做数据抓取的时候是怎么解决这个性能问题告诉大家，希望给遇到同样问题的朋友一点思路。即如果是APP的项目话，我们就在APP启动的时候，对需要的域名进行预解析，然后将解析结果缓存到一个LRU缓存中，LRU缓存算法可以看前面的文章哈（LRU缓存淘汰算法实现方案，这次没人再说你不会开发）。这样，如果我们使用这个域名的时候，就先从缓存中获得对应的 IP ，如果没有的话，就再走整个DNS 的查询过程。这个时候缓存中解析结果可能会变更，这样就会缓存数据失效，我们可以起一个定时任务，去定期的更新缓存中的数据就行了。这种方案在解析性能上还是提升不少的，基本控制在200ms以内。

通过上面我们已经知道了用户的请求是怎么到达CDN服务器的，并且针对DNS的解析进行了相关的讲解同时对于性能问题也给出了自己开发中的建议，现在我们再来看看它的整体架构图，来整体回顾下。

怎么才能找到离用户最近的CDN节点

现在，我相信大家肯定都掌握了如何让用户的请求怎么请求到CDN上了，接下来我们就要看另一个问题了，就是我们应该怎么将最近的CDN节点分给用户。

GSLB（Global Server Load Balance）这个组件就是对于部署在不同地理位置的服务器做负载均衡，其下面也可能管理了很多的本地负载均衡组件，主要有两个作用：

是负载均衡器，这个不用多少，就是分摊流量的。
保证流量流经的服务器与流量的源头在地理上是很接近的。

GSLB它可以通过多种策略，来保证返回的CDN 服务器与用户尽量保证在同一个地理区域。例如可以通过将用户的 IP 分为n多不同的地理区域，然后将CDN 服务器对应到各个区域里，这样就可以根据用户所在的区域来返回相应的CDN节点。现在再来看看其现在的架构图：

当然，是否能够从 CDN 节点上获取到资源还取决于 CDN 的同步延时，一般在使用CDN时是这样的流程：

我们先通过CDN厂商提供的接口将静态资源写到CDN的其中一个节点上。
CDN 自己内部会将静态资源同步到各个节点。

我们知道其实只要有同步，肯定是会有延时的，一旦我们无法从选定的 CDN 节点上获取到数据，我们就不得不从源站获取数据，而用户网络到源站的网络可能会跨越多个主干网，这样不仅性能上有损耗，也会消耗源站的带宽，带来更高的研发成本。所以，我们在使用 CDN 的时候需要关注 CDN 的命中率和我们自身服务器的带宽情况。

总结，今天我们学习了使用CDN技术对我们的静态资源进行加速，主要有两个核心知识，一个是如何将用户请求落到CDN节点上，另一个则是怎么才能选择用户最近的CDN节点给用户。CDN技术并不是运维的专属，我们开发人员应该要掌握其核心知识，这样我们在遇到这方面问题时才不会显得那么不专业，希望对你有帮助，谢谢。

下一篇预告：讲讲分布式调度的话题