CDN简介

CDN大家比较熟悉，这里做个简单介绍。

CDN主要是让用户访问资源的时候，能从离用户距离很近的CDN节点进行获取，不必到真正

提供服务的机器上获取。所以CDN可以

1. 让用户更快地获取所需要的内容
2. 减少骨干网络的流量
3. 减少服务器的压力

CDN经历了三个阶段

第一阶段 1995年，互联网发明者Tim，创建了第一家CDN服务公司Akamai

第二阶段 1999~2001，互联网发展高潮期，CDN快速发展

第三阶段 2001年互联网破灭，CDN公司大量倒闭，Tim的公司也倒闭了。2002年开始，宽带提升、游戏和视频大发展，带动CDN大发展

CDN虽然经历了二十多年的发展，但是现在还没有形成标准规范，各家的具体实现也不一样，本文章只讲解一种类型，希望能够让大家更深入的了解CDN。

CDN请求过程

CDN的请求过程，大致如下图所示，下面我简单介绍。左侧的实线框是DNS查找阶段，右侧的虚线框是CDN的范围。https://www.processon.com/view/link/5ed5175e0791291d5dba30ea

DNS查找阶段

用户在浏览器请求某个链接，如event.mi.com，浏览器需要查找该域名对应的ip地址

1.先查找自己机器的DNS客户端上是否有记录，如果没有记录

2.从本地DNS服务器获取，如果本地DNS服务器没有记录

3.从根域名服务器查找（根域名服务器全球共13台），根域名返回com域名服务器所在地址

4.本地DNS服务器从com域名服务器查找，com域名服务器返回event.mi.com的权威域名服务器地址

- 权威域名DNS服务器：包含了该域名的所有信息

5.找到权威域名服务器后，会查到该域名有个CNAME，这个CNAME一般指向CDN的全局负载均衡系统

- DNS的A记录

1）A记录格式为“域名-ip”，记录的是该域名对应的服务器ip地址

2）DNS的CNAMECNAME为域名的别名，一般有两种作用1)多个域名指向同一个服务ip，当服务ip变动时，只需要改一个A记录即可。例如，域名www.abc.com的A记录为1.1.1.1，对于域名mail.abc.com和study.abc.com的别名可以设置为www.abc.com，这样当该服务变更ip地址时，只需要变更www.abc.com的A记录，其他域名无需变动，减少维护成本2)CNAME在CDN上的作用也很重要。将域名挂载在CDN上，需要将该域名的CNAME设置为CDN供应商提供的域名，这样CDN供应商才能通过DNS将流量转移到CDN上。而且域名的CNAME设置为CDN的域名后，该域名的A记录也不能存在了。一般通过nslookup和dig命令，可以查看DNS解析的情况，如下图所示，可以看到域名event.mi.com的CNAME为白山云的一个域名。另外可以看到白山云的域名还有对应的CNAME，这个主要是为了做负载均衡，后面会进行讲解。

3) 本模块讲述的DNS解析是使用迭代查找，DNS还提供递归查找的方法， 大家如果有兴趣，可以看一下两者的差异

CDN阶段

通过上面讲述的DNS解析过程，CDN运营商成功将请求转移到他们那里

1.CDN的全局负载均衡系统实现方式很多，这里讲述使用的比较普遍的方案，基于DNS的全局负载均衡系统。

• 首先该系统是DNS，可以解析域名
• 其次，该系统有负载均衡的功能。CDN的负载均衡策略一般有两种，静态负载均衡（根据用户地理位置、使用的网络运营商等选择不同的服务器）和动态负载均衡（根据服务器的流量、性能、负载等动态数据选择服务器）。因为动态负载均衡比较耗费资源，所以全局负载均衡系统一般使用静态负载均衡策略，区域负载均衡系统一般使用动态负载均衡策略。
• 最终，该全局负载均衡系统，基于静态负载均衡策略，选择合适的区域负载均衡系统IP给请求方。
• PS：一般全局负载均衡系统会有一个后备系统，后备系统的配置和目前使用的系统一模一样。当CDN发觉被DDos攻击的时候，该后备系统会被启动，后备系统的ip会被加入到DNS中，而且该ip设置的缓存时间会较长，通过这种方案来减少DDos的攻击。
• PS：负载均衡有四级负载均衡和七级负载均衡，所谓四级和七级，对应的是OSI的七层，四层只能根据IP等做负载均衡，七层能获取请求的信息，如cookie等做负载均衡，我们常用的nginx能做四级负载均衡和七层负载均衡。

2.客户端请求CDN区域负载均衡系统，该系统会确定提供服务的CDN缓存服务器。区域负载均衡系统一般使用动态策略，为此需要有单独的服务器来收集区域内CDN缓存服务器的各种信息（如会话能力、往返时间、流量、缓存所在位置等）

• 这里简单介绍一下基于缓存所在位置选择CDN缓存服务器的方式。这种方式实现原理很简单，请求的url经过某种算法，匹配到一台CDN缓存服务器，今后再次请求该url的时候，仍然会命中该缓存服务器。这种方式的好处是节省了空间，一个请求只存储在一台服务器上，没有冗余。坏处是如果是热点url，服务器压力会过大，另外如果该服务器有问题，所有的请求都有回源的可能。

3.如果区域负载均衡系统提供的CDN缓存服务器没有缓存或者缓存失效，则会向上一级CDN缓存服务器进行请求，一般使用的协议有ICP/HTCP/CARP等。当然，判断缓存失效使用的是Web基础知识，Pragma、 Expires、Cache-Control、Last-Modified、Etag等

4.如果上层的CDN缓存服务器仍然没有缓存或者过期，则会到回源机上请求该文件，请求成功后进行缓存

CDN使用过程中的一些问题

CDN对抗高并发的情况是很有用的，可以参考这篇文章《常用缓存技巧》

但是使用CDN的时候，也可能遇到一些问题，在这里我给大家讲述一些我曾经遇到的问题

获取文件时间超长

最近遇到一个问题，通过CDN获取50KB的图片，耗时120s。

发生这种情况的原因是CDN厂商负载均衡配置有问题，在错误的配置下，为了拿到该图片，需要经过半个地球。后来让CDN厂商修改配置后，只需要0.2s。

获取到错误文件

商品需要有产品站，产品站会引用js文件，每次产品站变更，js名称不变，但js的tag会变，如从base.js?v01变为base.js?v02。js文件设置的是永不过期，如果版本号变更，则会回源，这是前提。

如果产品站和js版本不匹配，产品站会产生一些错误，如打不开页面或者某些功能无法使用。产品站和js不匹配有两种情况

1.产品站为新版本，js为老版本

这种情况一般是因为发布的时候，没有先将js发布到回源机上，而是先发布了新的产品站，这样新的产品站请求新的js时，会请求到回源机，而回源机还是老版本，这样老的js被当做新的js缓存了。这种情况发生后，一般生成新的js版本，重新走一次发布操作。

2.产品站为老版本，js为新版本

这种情况产生的原因比较多，也往往比较难以处理。发生这种情况的一个前提是已经发布新的js到回源机上，老的产品站还没有发布

• 当只有一个CDN服务商的情况下，如果用户都在国外，此时在国内访问产品站，根据全局负载均衡策略，这个请求是国内的第一个请求，CDN上并没有缓存，取到的js则是新的js，但这种情况发生的概率比较少，而且影响不大
• 当有多个CDN服务商的情况下，这种事情发生的概率极高。因为不同服务商服务区域不同，而且运维也可能调配不同服务商的流量，就很可能导致该js请求完全不在CDN上，产生回源的情况。这种情况下，一般删除CDN缓存，强制达成版本一致，不过还是可能影响到用户
• 还有一种情况为，如果文件只缓存在一台CDN缓存服务器上，如果该服务器出现故障，也会产生回源。不过这种情况较少，因为服务器损坏概率不大，另外CDN服务器上层还有缓存服务器，所以几率较小。

请求大量回源

这种情况发生后，往往会将服务器压垮。发生这种情况的原因是因为大部分CDN服务商，判断命中CDN的方式是根据整个url，如果该url通过google广告等推广，后面会添加不同的后缀，会无法命中。阻止这种情况的发生，可以让运维帮忙做特殊配置，只有指定的query参数变化才回源(运维很可能不想做这种操作，因为不利于后期维护)，或者提升自己的服务性能。

最后

大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）

1. 记博客服务被压垮的历程

2. 常用缓存技巧

3. 如何高效对接第三方支付

4. Gin框架简洁版

5. 关于代码review的思考

资料

1. https://cloud.tencent.com/developer/article/1349559
2. https://www.cnblogs.com/liyuanhong/articles/7353974.html
3. https://www.jianshu.com/p/4d8df62d55e3
4. https://blog.csdn.net/jiajiren11/article/details/80071312?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase
5. CDN 中的 DNS 功能及用途介绍
6. https://mp.weixin.qq.com/s?__biz=Mzg3MjA4MTExMw==&mid=2247486200&idx=1&sn=197c0905028104e1ae32dc6bed7941f5&chksm=cef5f94ef982705874cf1a852e2f3e4879e59cb0705d1aed5a12cd91f845fba1869b58cb8863&scene=21#wechat_redirect