第7章 构建大型网站的其他因素

7.1 加速静态内容访问速度 CDN(内容分发网络)

CDN 系统分为CDN 源点和CDN 节点，CDN 源点是为CDN节点提供资源，CDN 节点则部署在离用户更近的地方，一般每个省重要的城市都会有一个CDN 节点，让用户可以最近距离进行访问数据。

CDN 系统本质上是一种网络缓存技术，把相对稳定(更新不频繁)的数据放到距离用户最近的机房，一方面可以节省整个广域网的带宽消耗，另一方面可以加快用户的访问速度。所以我们一般会把一些静态数据(图片、视频、js脚本、页面框架)放到CDN 系统上

下图是CDN 系统的简单架构图:



通过浏览器访问一个网站的流程：



引入CDN 系统后通过浏览器访问一个网站的流程



从上面CDN 系统后的流程中，可以体现CDN 系统的几个关机的技术：

全局调度
CDN 地址进行解析时，需要根据用户的ip地址和CDN 节点的负载来进行调度的；一个是就近原则，比如IP 是山东的，那就用济南的CDN 节点，如果济南没有CDN 节点或者CDN 节点负载很高，就采取就近原则再分配合理的CDN 节点；这个路由算法还是非常有挑战的(好在中国的省份、地域是固定的) 
缓存技术
1). 缓存最核心的一个指标就是命中率问题，如果命中率不高那CDN 效果不好，所以保证CDN 系统的命中率就成为一个很重要的问题：如果命中率高就尽可能的缓存所有的所有的数据，采用内容 + SSD + 机械磁盘的方式来缓存尽可能多的数据
2). 如果缓存没有命中那就需要回源点去获取数据，这时带宽和CDN 源点的服务能力就成了考验；可以把访问相同数据进行合并访问CDN 源点
3). CDN 源点数据更新后，及时通知CDN 节点去源点同步数据
内容分发
内容分发是全部放在CDN 节点不用回源的数据(页面的静态数据)快速、有效的分发到CDN节点上；一般就是在CDN 管理页面进行编辑、修改；然后把数据分发到CDN 节点，那分发的效率、分发的结果检验就变得比较重要
带宽优化
因为很多流量都会访问CDN (尤其是视频、图片)会占用很大的带宽，带宽的成本很高，所以带宽优化就变得很重要，一般采用返回更少的数据和更好的压缩算法

7.2 大型网站的存储支持

大型网站除了业务就是存储和计算的问题，很多系统也是围绕这个系统运转的；存储系统也是一个非常重要的支撑系统；存储系统最基本的就是关系型数据库，根据业务设计表结构，把一些数据的操作也放到关系型数据来做(触发器、存储过程)；但随着业务量的增加这些都会面临着一些列问题，后续会引入分布式数据、分库、分表来做。

7.2.1 分布式文件系统

对于图片、视频等大文本的数据采用数据库存储就不合适了，这时一般采用分布式文件系统来存储(最常见的就是hadoop 系统中的HDFS 分布式文件系统)；HDFS 分布式文件系统从GFS 的论文实现的，这里简单说下GFS 的架构：

7.2.2 NoSQL

NoSQL 又称为not only sql，关系型数据库、分布式文件系统、NoSQL 都各自有自己的优缺点；相互之间是互补的，没有哪个可以彻底颠覆另外一个，只能是不同的场景选择合适的存储方案。
NoSQL 覆盖范围很广，基本是在关系型数据库和分布式文件系统之间的存储都是NoSQL 的数据库；下面我们从数据模型和系统结构上来介绍下NoSQL：
1). 首先从数据模型上做一个区分：

key-value
key-value 是最基本的技术支撑，后续的NoSQL 查询都是基于kv 架构发展起来的，但kv 结构的数据库有一个很大的问题就是没有办法进行大范围的有效查询

order key-value 
key 是有续的，解决了key 大范围查询的效率问题，但是value 还是需要业务自己解析和处理，在一些场景不是很直观

big table
google 开源的分布式数据库，从数据模型上来讲就是：BigTable 对value 进行了schema 支持，value 是由多个列组成；每个列里面可以嵌套列来组建数据

文档型数据库(mongodb)
数据是文档型的，可以任意扩展；类似与json的数据结构，银河一个value 又可以是一个完整的json 数据结构

graph(图数据库)：是kv 数据库发展来的一个重要分支，就是把数据库表的关系建立在是数据库中，这样把一些负载的计算从业务代码下沉到数据库里面

7.2.3 缓存系统

缓存系统可以看作是一种特殊的存储，一般我们说的存储是持久性的，但是缓存是非持久的，是一种临时的存储状态；是为了加速用户对数据的访问；缓存一般放在内存中，数据库一般放在磁盘中，内存的速度是磁盘的快百倍；redis 和memched 是当前最流行的2种缓存系统，redis 是分布式缓存，memached 是单机缓存系统。

7.2.4 搜索系统

这里的搜索系统指的不是百度、谷歌那样的全网搜索，指的是站内搜索；类似taobao.com 里面的搜索系统;当网站的访问量和数据量都比较小时，采用数据库 LIKE 的方式来检索、查询数据是基本可以满足需求的；但是效率很低；但当网站的数据量和访问量都很大时，就必须用搜索系统来实现数据的查询了。

爬虫系统
爬虫系统在整个搜索系统里面是非常重要的一个系统，是收集网页信息的一个系统；也就是搜索系统数据源的获取。在站内不用爬虫系统，一般从内部的DB中获取数据，一般称之为dump；获取数据源有2种: 一种是定期(one day) dump 一次数据、一种是有数据变更时通知去dump，增量进行dump，只dump 变更的数据

倒排索引
key1--doc1/doc2/doc3/../docN 每一个关键词对应的所有的宝贝title；这样可以快速检索
key2--doc1/doc2/doc3/../docN ....
正排索引
正排索引主要用来进行排序的，倒排索引检索出宝贝，然后对每个宝贝进行打分、排序；然后一起处理后展示出结果

搜索预处理
对搜索的关键词进行处理，比如输入的搜索词有错别字、太长、不合格字符；需要进行归一化、纠错、拼写、预测等 一系列的预处理，可以更方便的检索到宝贝

7.2.5 数据支撑计算

计算涉及的范围很广，计算机系统解决的问题就是计算和存储，所以我们这里来说一下网站产生的大量数据怎么进行处理：
 

离线计算：
离线计算就是把数据从生产环境剥离出来放到离线的存储环境进行计算，这部分的计算跟生产环境有比较大的延迟；离线计算中mapreduce 是最常用的一种方式，是Google 提出来的；hadoop 就是mr 的一种开源实现；数据都放在hdfs 上面，然后对每个node 分配计算单元，把计算后的数据merger 到一起

在线计算
相比离线计算，在线计算是一种比较实时的计算，是实时对数据进行计算；其中 storm和spark 是2种比较常用的实时计算框架

二者的区别之前说过了：1. 数据都是放在内存中，2. storm 是把数据用网络方式传输给个个计算节点  3. spark是根据数据存储的方式分配对应的计算任务 4. 最后都是把数据merger 进行输出

7.2.6 发布系统

任何一个系统、产品都需要迭代，所以发布系统是不可或缺的一部分；这部分还非常重要

7.2.7 监控系统

监控系统是实时检测系统是否正常的系统，也是必不可少的系统