什么是CDN？CDN和DNS有哪些关系和区别？

一、什么是CDN？

CDN的全称是Content Delivery Network，翻译成中文就是内容分发网络。CDN依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取内容，降低网络延迟，提高访问速度。简单来讲，CDN是用来进行加速的，它可以让用户更快获得所需的数据。

举个例子，某个网站的服务器在北京，如果深圳的用户想要获取服务器上的数据，就需要跨越很远的距离，由于传输速度和路由转发等因素，就会导致访问速度非常缓慢。但如果我们在深圳建立一个CDN服务器，上面缓存了一些服务器数据，那么深圳用户只需要访问这个CND的服务器就能获取相关的内容，这样速度就提升了很多。

二、什么是DNS？

要了解cdn就先要了解一下dns。当我们在浏览器中输入一个域名时，就能访问对应的站点。但实际的情况远比我们看到的复杂，因为计算机不能直接识别域名，所以必须依靠某种环节将域名翻译成IP地址才能，这个环节就是DNS。

当我们向DNS服务器发起解析域名的请求时，DNS服务器首先会查询自己的缓存中有没有该域名，如果缓存中存在该域名，则可以直接返回IP地址。如果缓存中没有，服务器则会以递归的方式层层访问。

例如，我们要访问> 四、>目前市场上具备综合技术实力和提供城市应急通信系统解决方案能力的厂商尚且不多， 华脉智联应急指挥调度系统是以音视频调度为主，可以实现跨地区、跨部门、跨警区以及不同警种之间的统一指挥协调，快速反应、统一应急、联合行动，真正实现社会服务的联动，有效应对突发性公共事件。该系统可以帮助市各级政府对突发公共紧急事件(如流行病、恶性案件、灾害事故)应急反应机制进行完善，为城市构建一张全面的应急预警和处理“安全网”。 系统可实现如下功能:
1、 分布式调度:地面指挥中心和应急车分别配备独立的调度系统，调度机和视频服务器可作为主从关系存在。现场应急车中的设备可以实时将现场数据上传至指挥中心总服务器，在卫星链路有压力或失效的情况下，现场应急车调度系统自成体系，完全可以独立对现场进行指挥调度。这种二级分布式的调度结构，就解决了多个公共事业部门之间协同作战的问题。各个部门之间可以协同工作，可互为备份，可分担压力，这是整套系统的优势所在。
2、 视频回传:通过单兵终端视频设备和车载视频终端，将现场图像实时上传至应急车或指挥中心，指挥中心领导依据现场图像做出各种实时决策。
3、 视频监控:通过应急车上的车载视频采集终端监控现场情况，并可以远程控制视频终端的监控方向和角度。
4、 指挥中心与现场语音调度通信:指挥中心通信设备通过卫星链路可以和现场通信设备建立双向语音通话;通过网关设备，可以将GSM和传统公网电话系统接入调度网络;指挥中心调度台可对所有终端灵活分组，随时可发起单呼、组呼、会议和广播等语音调度指令。
5、 现场通信系统:现场工作人员可以配备手台或者单兵调度终端，应急车上可配备车载调度终端和车载视频设备，这些现场终端之间通过无线链路实现语音、视频互通，现场终端还可以通过McWiLL基站设备实现与指挥中心通信设备的语音、视频通信，实现调度任务的上传和下达。
6、 应急多媒体会议功能:指挥中心、救援现场以及其他任何装备多媒体交互终端的地方可进行集视频、语音、数据为一体的多媒体交互会议。
7、 远程数据通信功能:现场用户可通过车载台连接电脑终端远程查询指挥中心各类数据库服务器和其他各业务服务器，以获取更多的有效信息用于现场的救援工作。
8、 集群对讲:现场McWiLL手台、车载调度终端和单兵设备之间可以发起集群对讲，一键即可呼通组内所有终端。
9、 视频监控:指挥中心调度台主动呼叫现场单兵终端或应急车载调度终端的号码，建立通话后，单兵终端或应急车视频终端将现场图像传回指挥中心，并通过视频服务器分屏显示在监控台上。
10、 录音功能:实时录音系统记录整个应急作业过程中的任务下达、信息收集，以及处理过程中的一言一行，既是宝贵的经验资料又为日后的排查提供证据。可对单呼、会议、广播、对讲等业务进行录音 *** 作。
11、 联动与对接:城市应急最重要的要求就是联动，包括各种通信网络联动，各种语音、视频设备联动、各种广播系统联动。城市应急必须要做到多网融合，破除通信孤岛，达到无所不在，无所不通，才能最大限度保障应急事件处理的实效性。

既然说了大型，首先要考虑的就是高用户并发的情况。这就需要结合你实际用户端应用场景，视频都双向传输和简单的低通量的文本交互一定不是一个概念。做大型的系统，还要考虑平时的情况和突发的高占用率情况。

首先我们先对应用做一个分类：

1高带宽消耗累应用

这个方面的代表就是直播相关或网络教学领域。直播系统的大体原理，主播手机采集音视频、编码，然后推送一个视频流给服务器（实际上是一个做了负载均衡的视频服务器矩阵组）。然后负责实时流媒体数据流接收的服务器，会将流媒体数据流推送给分发服务器（现在有现成的CDN,这样开发难度就小了很多。）然后观众申请观看的时候，分发服务器就会将所申请的时时流媒体推荐给客户。

这么粗糙的应用就可能包换用户端权限管理服务器组，业务调度服务器组，不同区域IDC建立的接入服务器组，不同区域IDC建立的分发服务器组，分等级的数据存储服务器组，ai内容审核服务器组（基于分流实时分析，预设内容审核规则），归档视频存储服务器组，短视频评级推荐服务器组，应用兴趣行为分析服务器组。客户在请求交互的时候可能还会有一些缓冲的队列呀，nosql之类的（redis，memcache）。各组服务器的规格和数量都是根据同时并发的情况定的，在程序开发好的时间可以通过自动化的方式模拟高并发，再通过查看分析瓶颈，而对前期的规划做出合适的调整。

有些时间还要实现不经过分发，交互直通以降低延时。pk的连线的时候，太高延时是接受不了的。这个就不继续展开了。

还有网盘类应用也也很多类似，只是延时要求没那么高。传统的视频网站也是基本相同原理。

传统的微博也是类似的分发机制。

2低延时需求型

这方面一般是以网络游戏为主。对于一些点电子竞技类的应用，做到80ms以下的低延时是必须。服务器的核心响应速度和带宽的低延时是重点。这种服务器最好可以独享一条专线，或者在虚拟网络系统中设置一个更高的优先级，数据线优先同行也会尽可能的降低延时。至于服务器组之间的vpc也应该有一个更高的通过优先级，以保证服务器之间的访问延时极地。这种应用服务器，最好要支持核心运算，不过这个要开发的架构支持。

再就是后期用户量大的时候，做更新包下载的时候会采用分发服务器（CDN）。

3高突发的缓冲

这种都是电商网站，平时就是讲全段应用服务器做彼此依赖，后端选择一个大吞吐，大并发的后端框架（京东使用的go语言对高并发和数据挖掘就有很多优势，我也刚开始学习）。这种系统网元架构就简单很多，传统的负载均衡后挂着不同模块的应用服务器组，然后经过缓冲服务器组，之后到达数据服务器组和APIGateway。

日常的应用都是没啥问题，都是因为一些节日或促销，或爆款等发生临时性数据 *** 作的拥堵。解决这种缓冲都方式有很多，比如临时快速读写缓存，消息队列等。甚至开发总线通信队列等待机制，很多解决方案。

现在系统本身的规划和后期都优化都有许多解决方案，现在的瓶颈往往是系统间的交互通信。

服务器种类各云服务商都称呼也不一致，总体说分为轻量应用服务器，负载均衡服务器，超算服务器（CPU和GPU两个方向,后者也常常被成为图形处理服务器。）数据服务器（常见的版本都有），文件服务器（nas和oss），分发服务器，缓冲服务器，数据分析服务器。我项目中使用大大类就这些了，也许有些我没用过和不知道的，希望大家在讨论区补充纠正。

希望对你认知有所拓展。

---