动态内容如何通过CDN进行加速

本质上来讲CDN接近于一个全网分布的巨型cache，在这个方面来说，其对静态内容的加速非常容易理解。但是，在目前的网路中，又有多少网站恪守静态内容呢？面对动态内容、个性话内容、电子商务的实时交易数据等等完全不同于以往静态内容的要求，CDN应该如何完成呢？本文接下来将会为您简单的解释和介绍下目前的主流CDN服务系统是如何解决这个困难的。

单纯的静态内容由于管理繁琐且表现能力严重不足，所以日益为各式各样的CMS取代。为了顺利的实现对动态内容的交付，典型的web系统在结构上也有了很大的变化，逐步演变为如下图所示的结构：

web系统分为了表现、数据访问和业务逻辑三层，CDN针对动态内容的加速也就被分解为单独针对三层内容的依次加速。

CDN对表现层的加速

表现层基本上是web系统与用户发生直接交互的界面，这层通常由HTTP服务器直接构成，负责接收用户发起的服务请求并转交给后端的业务逻辑层，同时也负责接收业务逻辑层发来的处理完成内容，并付则组装为HTML页面转发给用户。由此不难看出，CDN在表现层完成的加速本质上还是一个静态内容的积极合理cache和分发。常见的，在表现层需要CDN缓存的内容通常包括：

∙网页中嵌入的独立元素：典型如图片、各类脚本、flash动画、网银可能用到的activeX控件等。

∙真正的多媒体内容：如视频

∙网页的部分片段内容：如公用的广告栏或导航栏。

CDN在业务逻辑层的加速

一般情况下，逻辑层往往是web系统的核心，负责处理所有的业务逻辑并生成动态内容，换而言之，在逻辑层不存在可以直接大量缓存的结果数据，而代之以的是运算过程。

相对的加速也就转变为边缘计算。顾名思义不难理解，边缘计算是指将应用程序及其及其所需的数据和运算能力从少量而集中的网络的中心节点转移到接近用户的网络的逻辑边缘位置。

传统上，在典型的web服务部署结构中，用户直接通过URL对布置在数据中心或中心节点的应用系统发起请求，而应用服务器则通过参数或其他类似机制给予客户反馈，在边缘计算的过程中则不在直接是这样。采用边缘计算服务之后，应用系统及其数据被复制到了成千上万的更靠近用户的分发服务器中，在利用边缘计算平台提供的计算能力之外，也减少了从中心节点读取数据的次数和大小，降低了整个系统的响应时间。

CDN在数据访问层的加速

通常情况下大型网站系统的应用瓶颈往往存在于多个节点，可能是业务逻辑的运算，也有可能是后端的I/O，尤其是数据库IO，在此种情况下，就需要考虑使用CDN对应用数据进行加速了。当前，主流的加速技术还是复制，在边缘服务器上复制web系统数据访问层的方法可以分为整体缓存和部分缓存两大类，其中部分缓存按照缓存内容预知情况可以分为盲缓存和已知缓存。

整体缓存

整体缓存最容易理解，一般是指将数据库整体复制到多台或全部边缘服务器上，在此种情况下，边缘服节点可以完全不依赖中心节点而独立的生成完成的内容。显而易见，在整体缓存中最重要和最大的挑战的就是保持各节点之间的数据一致性。

确保所有节点上的数据一致性，关键在于及时或即时讲数据更新扩散到各个副本上，其中扩散的方法可以大致分为两类，即惰性扩展和积极扩展。积极扩展指在实现一个针对数据的更新之前通知各副本更新数据，惰性扩展则把这个步骤遗留到了更新完成之后。理论上来说，积极扩展实现了即时的数据更新，但在实践中却由于性能、扩展性等方面因素而很难实现；相反，惰性的方法由于不存在这些方面的问题，且其延时也相对容易被用户理解，故而得到了广泛的应用。

盲缓存

盲缓存是指缓存的对象是应用系统中最近一段时间最常用的查询或查询数据，并将其复制到边缘服务器上。显而易见，此种缓存的内容只能包含之前已经被查询过得内容，在此种情况下，影响效能的核心因素就成了缓存内容的命中率了。为了解决这个问题，最常见的解决方案是优化查询结果，以匹配更多的查询。例如，针对一个新的查询请求，尽管其结果在缓存中不存在直接的对应，但是可以由多个之前的查询结果复合而成，进而减少了对中心节点的源服务器的访问请求，降低了整体的相应时间。

盲缓存的主要问题是确保内容有效性，当然，也可以理解为另外一种数据的一致性问题。已知缓存

相对于盲缓存的被动选择，已知缓存是指基于一定的形式，对中心节点的源数据进行事先的有选择的复制和缓存。比较典型的情况是在边缘服务器中运行一个由其自身维护的数据库服务iqi，并保存中心节点的部分视图。这种缓存的不足在于其需要一个额外的角色完成在全局上分析查询重点，并调整、分发被缓存对象的功能，而此角色本身往往会成为系统中的流量瓶颈。

转载