各位志同道合的朋友大家好，我是一名踏足互联网十多年的编码爱好者。现在我将分享我们的各种经验和实际架构。喜欢就关注我，一起学技术。深度学习，我会在每次分享结束时公布下一个话题
前几天我们讲了为什么要引入缓存，什么时候引入，以及我们生产中缓存的读写策略是什么。如果你忘记了，你可以去文章列表自己阅读。同时，我们也分别深入讲解了redis 机制。（Redis哨兵机制和底层原理深入分析，这次终于弄明白了）以及缓存穿透问题的解决方案（缓存穿透问题，开发中的真实解决方案）。到目前为止，我们现在的系统架构是这样的
从架构图中我们可以看出，我们现在正在使用分布式缓存来加速各种动态请求的数据。但是我们系统里面其实有很多静态资源，请求量也超级大。例如：
手机APP有很多图片、小视频和流媒体。对于网站来说，不仅有以上资源，还有大量的HTML文件、css文件和文件。
现在，在我们的一个商场里，有很多产品图片，详情页也有产品介绍视频。目前这些静态资源都放在Nginx服务器上，请求量非常大，而且这些文件对访问速度的要求极高。并占用高带宽。这里很可能访问速度会变慢，占用带宽，影响我们后端的动态请求。这时候，我们就需要考虑如何加速这些静态资源了。
如何加速思考
首先我们想一想我们是否也可以使用分布式缓存来存储来达到加速的目的？答案肯定是否定的，因为：
图像或视频文件大小不小，从几兆字节到数百兆字节不等。我们的用户遍布全国甚至国外用户。我们需要让用户快速获得相应的访问权限，即就近访问。我们不能在全国各地建机房来部署缓存，这是不现实的。图片或视频信息文件较大，访问量极高，如果自建机房带宽，肯定会面临很大的风险。
因此，我们不能建立自己的机房来加速静态资源。我们需要在我们的应用服务器外层加一层静态资源处理组件，让全国各地的用户就近访问，同时也让这些缓存命中率非常高。如此之高，以至于我们试图减少对我们自己的业务服务器的回源。这个技术就是我们下面要讲的CDN。
CDN核心技术
CDN实际上是一种网络分发技术。它将我们的静态资源分发到不同地理位置的机房服务器上，让用户就近访问问题，加快静态资源的访问速度。
你可能会说CDN是我们开发不出来的，不需要我们去掌握。事实上，事实并非如此。建议不要只停留在发展的位置上。你必须有控制全局的决心。许多CDN调查所有的工作都需要高级工程师，所以你需要了解这项技术。现在如果让你配置 CDN 和排查 CDN 问题，你可能会因为自己的技术壁垒而感到无助。
首先，让我们看一下在构建 CDN 系统时要考虑的两个关键点：
如何让用户请求先映射到CDN服务器，这个应该是最基本的。如何根据用户的地理位置选择最近的CDN节点供用户访问。
接下来，让我们看看CDN技术如何基于以上考虑对静态资源进行加速。
如何将用户请求丢弃到 CDN 服务器
12306网站大家应该不会陌生。它有很多cdn节点让我们可以访问附近的静态资源进行加速，而我们输入的url是12306自己家的url，而不是cdn的ip。为什么是这样？因为如果cdn节点的IP是直接提供给用户的，如果IP变了怎么办，那么所有的静态资源都要改地址，很不靠谱，所以都是自己的域名直接服务给我们的，然后隐藏如果你住在CDN的IP中，这个机制应该怎么做呢？其实大家应该都能猜到，那就是使用DNS进行域名映射。
DNS（Name）是一个分布式数据库，存储域名和IP映射。域名解析返回的结果有两种：
直接返回域名对应的IP地址。返回另一个域名，即将当前域名解析为另一个域名，会跳转到另一个域名解析，现在我们用这个方法解决上面的域名映射问题
让我们来看看它是如何工作的。
假设我们的一级域名是 ，那么我们可以将影像服务域名定义为“”，然后将该域名的解析结果配置为CDN提供的域名。比如ucoud提供了这样一个域名“”，我们的系统镜像地址是这样的“/100.jpg”。
当用户请求100.jpg的地址时，DNS服务器会将域名解析为域名，再将域名解析为CDN的IP地址，从而获得CDN上的资源数据。
我们知道DNS解析其实是有问题的，因为域名解析过程分为几个层次，每个层次都有专门的域名服务器承担其解析职责。因此，域名解析过程可能需要跨公网进行。多个 DNS 查询的性能相对较差。
查询多台DNS服务器后，整个DNS的解析时间可能会达到秒级，那么我们应该解决这个问题吗？
在这里，我会告诉大家我们在做数据采集时是如何解决这个性能问题的，希望能给遇到同样问题的朋友一些思路。即如果是APP项目，我们会在APP启动时预先解析出需要的域名，然后将解析结果缓存到LRU缓存中。LRU缓存算法见上一篇（LRU缓存消除算法，这次没人说你不开发）。这样cdn加速哪家好，如果我们使用这个域名，我们会先从缓存中获取对应的IP。如果没有，我们将经历整个 DNS 查询过程。此时缓存中的解析结果可能会发生变化，这会使缓存的数据失效。我们可以启动一个定时任务来定期更新缓存中的数据。这个方案在解析性能上提升了很多，
通过以上，我们已经知道了用户的请求是如何到达CDN服务器的，对于DNS解析我们也给出了相关的解释。同时，对于性能问题，我们也给出了自己的开发建议。现在我们来看看它的整体架构图。, 整体回顾。
如何找到离用户最近的 CDN 节点
现在，相信大家一定已经掌握了如何向CDN发起用户请求了。接下来我们要看另一个问题，就是我们应该如何将最近的CDN节点分发给用户。
GSLB（Load）是一个为部署在不同地理位置的服务器执行负载均衡的组件。它还可能管理其下的许多本地负载平衡组件。它有两个主要功能：
GSLB可以使用多种策略来保证返回的CDN服务器和用户尽可能在同一个地理区域。例如，可以将用户的IP划分为n个不同的地理区域，然后将CDN服务器映射到每个区域，这样就可以根据用户所在的区域返回对应的CDN节点。现在我们来看看它目前的架构图：
当然，能否从 CDN 节点获取资源也取决于 CDN 的同步延迟。一般使用CDN的流程如下：
我们首先通过CDN厂商提供的接口将静态资源写入CDN的其中一个节点。CDN 本身会在内部将静态资源同步到每个节点。
我们知道，只要有同步，肯定会有延迟。一旦我们无法从选定的 CDN 节点获取数据，就不得不从源站获取数据，而从用户网络到源站的网络可能跨越多个骨干网，不仅性能有损耗，而且消耗源站点，导致更高的研发成本。所以我们在使用CDN的时候，需要注意CDN的命中率和自己服务器的带宽。
综上所述，今天我们学会了使用CDN技术来加速我们的静态资源。核心知识有两个，一个是如何向 CDN 节点发送用户请求，另一个是如何选择离用户最近的 CDN 节点。CDN 技术并非专属于运维。我们的开发者应该掌握它的核心知识，这样我们在这方面遇到问题时才不会显得那么不专业。如果今天的内容对您有帮助，您就喜欢它。关注我，我会持续更新开发中的实战案例计划，谢谢。
