本文共 8369 字，大约阅读时间需要 27 分钟。

**中小站点的前端引用，且不考虑使用的CDN等技术，假如用户请求到达站点以后，前端首先到达的应该是调度器，调度器通常是一个nginx，或者是一个haproxy，对大多数站点使用nginx和haproxy足够了，为了避免成为单表，

一般做基于keepalived的高可用 ** 当用户请求到达以后，基于站点需要（比如电商类）站点程序会经常更新的，但是此前用户所发布的文章，还有各种各样生成的图片，一般都不会变，除非用户自己删除，所以一般都需要单独找一个存储，然后使用url调用站点上，基于应用程序布局以后进行显示的，因此应用程序需要经常更新的那一部分内容是单独存放的

图片需要单独存放，所以对于图片而言，基于某一url，通常是单独发送到一组主机上，对于图片内容来讲，应该是可以做缓存的，所以在前端调度时，所有静态内容，应该都是能够基于缓存进行加速的因此，.js,css,img结尾的文件，一般都发送到同一组服务器上，这个服务器通常是缓存服务器（varnish代表）

为了使命中更高，在使用haproxy或nginx的时候，需要根据目标url进行调度，这样调度以后可以使得命中率提升，为了避免一台varnish宕机，导致所有缓存不可用，需要使用一致性hash算法，来实现hash环构建 **动态内容不能缓存就需要发往动态内容服务器，虽然称为应用程序服务器，但是这上面内容，除了动态内容（。jsp之外）一般而言需要随着更新的还有.cs,.js各种跟网页本身相关的文件，而非用户数据，所以通常都在这一类主机上， 所以这些主机存放的是站点应用程序，以及跟站点本身构架相关的内容，js文件，css文件，jsp文件 因此基于varnish反代时，也需要分别代理的，js文件，css文件，jsp文件存储应该到下面的应用程序服务器 而对图片存储到另外一 主机上（varnish反代只能反代http协议，所以后端必须是一个http主机，对这台主机来讲，如果一台主机不足以承载这么多用户请求，更重要的是，图片数量可能会非常大，单台主机存储也是比较难以解决问题，因此需要多台主机，也需要负载均衡，由于是图片存储，怎么反代都可以） ** 对此处来讲，下面部分也是静态内容，也可以随意调度

但是下面的动态调度可不能随意调度，对动态内容是需要保存session的，对session而言需要去如何构建，

上面是静态内容

下面是动态内容

图片内容量会非常大，任何单台主机都无法解决问题，一次需要使用共享存储，NFS,SAMBA，但无论是NFS还是SAMBA在单个主机之上，且不说是单点故障所在，还有网络IO和磁盘IO也不足以承担庞大访问量

所以应该是一个可以横向扩展的存储系统 ，就是分布式存储（假设是一个多台主机构建的集群，分布式存储，就是数据并不是一台主机上存放的，每台主机上，都各自存放了整个 数据集的一部分，因此前端的主机，再向后端发送请求时，就需要知道数据到底在哪台主机上，（数据由元数据和数据组成））

可以尝试把每一个文件的元数据不跟数据一起存放在节点上，而是分开存放，找一个节点用来当中心节点，它知道一共有哪些文件，并且文件位于哪个主机上，所以这就称为有中心节点的架构

前端主机去访问数据时会首先找元数据这台节点，它会告诉请求的客户端，数据在哪台主机上，于是就去找真正存放数据的主机，如果有30台主机，每一台主机上都存放了30分之一的数据，所以前端大量请求会被30台主机均匀分摊，因此无论是网络IO还是磁盘IO的窘境都能得到解决

但是会有新的问题，单点，元数据服务器就成了单点，因此需要做高可用，这个高可用可以尝试的是，如果可以的话，不共享数据就比较麻烦，文件创建时，第一台主机更新，第二台改如何解决 因此他们两还需要用到共享存储，没有共享存储就不能把第一台主机数据更新到第二台主机上，确实有一些解决访问，比如使用mysql来存元数据，把元数据放在表当中，mysql对于数据创建慢，但是读还可以，如果遇到压力过大，mysql做主从，所有写操作发给主节点，读操作发给从节点，但是mysql也属于单点，mysql的单点可以用MHA或者直接使用PCRA集群 使用mysql并不是一种理想的解决方案，但是有些分布式存储确实是使用mysql，来解决名称节点的宕机

还有第二种方式，

可以使用zk集群，zookeeper，把数据放到zookeeper上，zookper自身也是集群，基于分布式zookeeper的原子协议，让数据在多节点之间冗余，任何一个节点宕机了不会导致数据丢失的，而且zk在数据接口上是用文件系统方式展现的，但是非常简单基于内存工作，因此性能不错，也算是一种解决方案 可以使用所谓的集中式的解决方案，而且世界上各种各样的分布式解决方案当中，应该有百分之90以上都是集中式的解决方案，不同的是，有些解决方案使用了mysql做后端存储，有些是用ZK，也有一些使用其他 的比如redis之类的，这取决于你的程序员开发时的需要，

还有一种为了高效直接放到本地内存中，这样就不能与其他共享，只能定期同步到磁盘上去，类似redis持久化一样，AOF,RDB一样，一旦出现故障，找一个备用节点，利用持久化恢复过来，只要持久化数据没有丢失，但是这个过程会比较慢，可能需要20,30分钟

类似微博的站点也是经常出现问题，每年也有一次的例行维护，账号不能创建，有各种各样的限制，所以任何解决方案都没有良好的解决机制，通常也需要一些理性维护来解决技术手段无法解决的所有问题，

这是一种方式有集中节点的解决方案、

分布式系统确实能把网络IO和磁盘IO扩散出去 还有一种叫无中心节点的解决方案，类似于redis的 cluster，把数据和元数据，数据是分散存储在系统的每一个节点上的的，但是元数据在每个节点上都有，你可以找到任何一个节点，都能知道哪些数据在哪些节点上存储

好处是节点故障了，客户端只要能够知道其他节点是谁，就能跟此前一样获取数据，对于这种集群来讲的确拜托了单点的束缚，但也有其他问题，

元数据的一次更新，需要在多个节点进行同步

另外无论是有中心节点还是无中心节点的集群，自身都应该拥有这种功能，数据自动分片，

所谓数据自动分片，代表无论你怎么存数据，这个数据都不会只存一副副本，不会只存在一个节点上，

(仍然以中心节点的解决方案为例，比较好理解)

一般来讲用户需要存数据的时候，会首先向名称节点，现在要存数据，该存到哪里，名称节点会根据数据分布均衡性等或根据当前节点的空闲性，，各种指标的特点，选择一个主机，返回给客户端，客户端现在就连接到这台主机上，通过它的API来发送数据存储请求

存下来以后，中心节点主机一般会告诉存数据主机，把这个数据至少冗余一份或多份，冗余到哪个节点上也是 由中心节点主机挑选的，这个文件不止要存一份，还需要发给集群中的一台主机存储

到底哪个节点，就需要中心节点告诉，只要这两个节点不同时故障，这个数据就能正常访问，更重要的是它们还有自动副本检测功能，为了确保数据的安全和可靠性，假如每个文件都有两个副本，任何一个节点宕了，就会导致文件就一份了，此时集群会自动启动，找其他节点，把哪些小于指定副本数量的文件，再重新创建一次，因此有达到了每个文件有多个副本的条件，不用等到节点修复了，，重新上线再创建这个样子，，可以理解为有自动治愈的功能，

多数的分布式文件系统都可以这样子，如果每一个文件都有2个副本，那坏一个没有问题，有3个副本，坏两个节点没有问题，但是副本数量越大，浪费空间越多，可以理解为文件级别的raid。如果存放下图片文件，每个都要复制，这样的代价就比较大，所以一般分布式存储时，还有两类管理机制 第一类风格可能只适合存储大文件，比如视频站点，一部电影就几个G，都是大文件，一般这样都是把大文件切成固定比例的块，每一块都当做一个单独的文件体被单独存放和管理，每一块都有副本，那么元数据就知道一个服务器被分为了几块，而块里有什么数据，之间是怎么组织起来的，是有记录的，每一块存储在哪些节点上都有记录，所以才可以化整为零才能拼凑起来。

第二种方案，对于某些站点，社交电商，有大量图片，但每个图片不会太大，一般几十K，几兆，这种就属于海量的小文件，很可能达到几亿个，可以创建一个容器，把图片放到一个个容器了，每个图片放到哪个节点的容器，名称节点服务器都会记录，

找一个理想的折中大小的机制，来解决，这两种方式一个是化大为小，一个是积小为大

但是如果一个站点既要存储大文件又要存储小文件，如果又需要还是需要分开的，不过有些存储是的确可以海纳百川，比如淘宝的TFS，是用来设计存储淘宝大量图片的

TFS淘宝开源出来的图片存储，

创业公司一般超过1年的不超过百分之20 这就是分布式存储的一些基础逻辑和常见的解决思路，有了分布式存储，就需要思考一个问题。

存储用的都是存储协议，但nginx向后端反代是http协议，意味这些存储需要提供http接口，nginx才能打交道，没有http接口。(有些分布式存储还是能输出http协议的，但是大多数是不可能输出http接口。所以nginx要实现反代后，还能去存储上找到文件)

无非就是几种方式：

1.找一个中间节点，代理，这个程序一侧代理http，一侧支持存储，或者是nginx本身也是模块化的，给它开发一个模块，这个模块能适配这个存储协议，增进nginx的功能，但需要自己开发

我们上传图片是通过专门的应用程序发布的，程序允许你点击上传，意味着动态站点应用，一旦用于要上传，就需要上传到分布式系统

这样前端才能看到数据，像这种能存储在文件系统之上的，都是非关系型数据，非结构化数据，（比如发朋友圈，有图片有文字，如果没有什么关联可以存到非关系型数据库，但是有些数据需要严格做事务的，比如和朋友之间的关系，用户信息，还是需要存到关系型数据库）每一种存储都需要冗余

对有些数据库来讲，可能性能较差，还需要做缓存，任何系统性能差，速度慢，要么换要么就是加中间层 那么有些程序需要发布，可以基于灰度发布，可以基于混合模型构架

运维的日常工作，发布（脚本），变更（可以使用配置管理系统，ansible），故障处理，去构建整个结构的时间是很少的，可以做个配置管系统，里面保存了整个系统架构里面主机需要用到的配置，任何一主机出现故障，下了，新主机上来，配置好地址，配置系统自动连接上，把安装包等一些程序直接安装，启动

以手工劳动为耻，以自动为荣，所以需要一个配置系统里面存储好整个环境中每台主机的配置，而后它可以去周期检查每个主机是否是正确状态，还能自动改回来，ansible就是，saltstack

对于大型应用来讲，这种配置系统是不足以解决需要的。国内的BAT，都会有自己的自研系统，到了这种公司首先要学习业务流程，岗位上的操作 故障处理，需要一个监控系统，随时监控着向集群中的每一个节点，甚至包括监控系统自己，出现故障就报警，小故障，可以写一些监控系统脚本放那里，或者连接到配置系统，让二者联动起来，对于一些小故障，能够触发脚本或者触发配置系统，来完成自动修复的功能

比如监控的一个web服务停了，先重启服务，解决不了，一次不行，再次重启，第三次就联系配置系统，进行配置变更，查看是否配置出问题，还有问题可以呼叫人工接入 ansible比较来讲还是过于简单了，企业中用的比较多的pulic。saltstack，但是在红帽的推广下，ansible还是有很大的用武之地的，尤其是在红帽系统上

分布式的解决方案有非常多，可以在git hub搜索 distrubutable FS，有很多

google，facebook，阿里云等这些大公司需要海量的数据存放，因此要么自己把通用解决方案做二次研发，要么自己从头构建，它们都面临大数据丝带面临的问题

1数据增长爆炸式，

2信息链接呈现越来越复杂性

3访问并发增大

4数据结构多样性（结构化数据，非结构化数据（日志文件，图片文件）） 对于这些都会带来巨大挑战，尤其是数据存储，对于海量数据，无论多大中心存储需要存下来，这个是第一点，

第二存下来以后如何基于IO压力来让前端应用程序装载以后，去进行分析处理，（把上T的数据加入内存分析，这在单台主机上是简直无法完成的）

像这种，就有一些思路，如果需要在某些数据上排名，不会把数据存下来以后再事后慢慢去分析，而是数据刚来的时候直接做好统计缓存到系统上，比如每个商品有个id在redis中表示，即便是有1000万个商品，都在做交易，1000万个商品每一天可能都不止一笔交易，每个交易都在redisincr就可以，不用再去分析将来的记录

利用前端程序让其统计在redis中也不失为一个解决方案，

真正如果需要去分析就需要强大的分布式数据存储和分析工具，首先需要是一个存储，把数据分割存储到每一个节点上，每一个节点上的数据最好能自成体系，能够被单独分析，，因此这样一来，大问题切割成了很多小问题来实现，hadoop就是类似

一个hadoop早期的平台构成，底层是一个分布式存储，一个MapReduce，MapReduce就是一个分布式运算框架，如果要做一个聚合计算的话，可以把一个大的聚合计算，可以拆分成N个小的，每个节点上只负责一部分，但每个节点上统计的排名不是最终排名，把每个结果统计出来的排名再合并到一块，重新再来，把一个大问题拆成很多小问题以后，合并成二级的，大问题，再拆小问题，合并成三次的大问题，最终一定能得出结果来

基于这种逻辑层层切割，层层递进来完成分析的

面临大数据存储首先应该是早期的搜索引擎公司，他们的爬虫把互联网上各家的数据爬过来，存下来，需要大量存储，还需要给这些页面做关键词分析，就需要排名关键词

对于google来讲，同一个关键词可能存在上亿的网站上，哪个网站质量最好，还需要做很多运算，比如这个站点被链接次数，这次出现正在页面中的次数，这个词出现在其他页面的次数，这个分析是非常复杂的部分，

google的这种算法叫page rank，google的创始人有个叫做佩奇，page，算法叫page rank，页面排名算法，这个是google的最高机密

google为什么搜索精准，就是因为背后的page rank

所以现在大多数企业现在面临的，其实在google几年前就已经面临和解决了，后来google把上一代技术把开源了，发不了论文，照着整个论文进行山寨，hadoop就是这么来的，山寨了google第一代分布式存储和分布式计算的思想而来的。

在google内部很有可能不用了，也包括容器

docker只是把容器推进了，让容器走进了千家万家，内部就把内部用的K8S发布出来了，K8S已经成为容器调度的标准框架，所以google一般出手，就所向披靡

技术发展是呈加速态势的，好在第一个吃螃蟹的和后面的吃的，花费的代价是不一样的，所以现在看到的大数据处理方案或多或少都有着google的影子，hadoop其实就是山寨了google的 产品，包括hadoop后来的各种各样的解决方案，比如HBASE（山寨的google的page table，也是后来google公布的论文）

也不是只有google一家公司独大，另外一家公司也是有高可用关系的竞争能力的，Amazon，亚马逊在云计算领域，连google都比不上，还有一家是FB，facebook，但是历史积淀太短，一定程度上来讲，也是社交媒体公司，facebook最近的技术也是爆发一样，很多产品一旦发布就立即开源，并贡献给ASF

目前在全球环境中可用的开源产品，都是山寨google，或者google贡献的，要么是亚马逊的，twitter也在不断地贡献出开源工具，使得原来让哪些开源技术赚钱的公司黯然失色，比如redhat

大数据带来的挑战，其实在十几年前，搜索引擎公司都已经面临过了，有技术并不能解决所有问题，商业模式才是王道，真正早期做搜索引擎的其实是雅虎，必应，这种应用就是强者通吃

因此云计算亚马逊起来以后，其他公司想起来特别难，

搜索引擎市场占有率，除了我国，google展百分之90以后，其他的加起来不足10.基本上处于垄断地位，能垄断就拥有角色支配权，事实上并没有垄断技术做太多事情，因为这家公司文化是不作恶

正是因为这种不作恶的文化，才能吸收越来越多的公司合作，就能吸纳各家优秀先进的公司的文化和思想，很多技术好的人都去了google，google甚至允许70%的时间完成工作，30%的开发自己喜欢的产品 我们的存储和要存的数据 传统的存储NAS ,SAN，这种存储都是集中式的，各个服务器在需要使用数据的 时候，通过集中的交换和网络来实现数据存储，这样的IO是有限的，无论是网络IO还是磁盘IO，更重要的是也不利于扩展，无论是磁盘空间，还是磁盘IO还是网络IO扩展起来及其困难，所以必须要突破这种局面，就出现了分布式存储，

分布式存储也有很多挑战和问题需要解决，这些问题甚至于是不能忽略的，比如

1.节点之间如何通信，

2.数据存储如何完成

3.数据存储的时候怎么均衡使得各个节点都能获得存储

4.容错，一个节点出现故障百分之一，10个就是百分之10，有100个主机，几乎每天都有坏的，如何容错，就需要是在设计初就需要考虑的问题

5.文件系统支持 分布式存储也只能满足CAP理论中的两种

可用性

分区容错性

数据一致性

要确保我们的系统的可用的，其次分区容错性，

数据一致，经过每个节点去访问的数据应该一致，对于有集中节点的来讲，这个集中节点能确定数据是一致的，如果说是无中心节点，那就要讲弱一致，最终一致性

所以就要求元数据存储足够高效

数据本身要有冗余 分布式文件系统设计目标要满足这些特性

任何简单出现故障，对客户端来讲是无所感知的，客户端并不知道哪些节点坏了，所以叫失效透明

并发透明一样的道，大量访问的时候，客户端并不知道自己是如何被分布的，

但是访问的IO和性能依然可用

复制透明

迁移透明

一个数据不只一个副本，这个副本还需要分布到其他节点上去，所以这个复制过程对于用户来讲是透明的，不管复制何时发生，用户访问数据该访问访问

迁移，如果新增了10个节点进来，要把有些数据迁移到新加入的节点上，以实现更好的均衡，这个过程对用户来讲也是透明的，为了加进节点进来，自动迁移和备份 **分布式文件系统的代表产品 1.最早最著名的是google file system（现代意义上的分布式系统，简称GFS） 2.HDFS hadoop distrubuted filesystem 山寨GFS 3.TFS 淘宝的 是HDFS二次衍生，几乎支撑了淘宝内部的所有图片存储和服务 GlusterFS 无中心节点和redis节点相似，主要是对象存储，每一个文件在存储时，是一个数据对象，自己自带元数据，cluster对于元数据可以调度，但是有些元数据是在文件之上调度的，以为不需要事先提供文件系统，还需要格式化之类的，不需要这个过程 Lustre 是oracle的分布式文件系统，常用的构建，,HPC高性能的计算机集群 Ceph 被收录进linux内核，是内核级的linux分布式文件系统，现在应该还不是特别稳定，文件系统一般都是内核级的，但是前面这些都不是，是在应用程序之上实现的，都是用户空间的文件系统，基于内核本地的文件系统做了二次抽象而已，但是ceph原生就是内核级的，自己原生就是分布式的 mogile filesystem （分布式存储）使用perl语言研发，早期和memcached是一个组织研发的 API（php，java，perl，python）大众点评和豆瓣都使用mogile fs来存储自己的图片，所以对很多中小企业来讲，mogileFS还算是不错的解决方案， moosefilesystem MFS 还算是不错的分布式文件系统 fastdfs 是C语言研发的Mogile filesystem （perl语言研发，要运行在perl虚拟机上，元数据存放在mysql中），而fastdfs是C语言，不依赖mysql，而且是国内作者研发的 国内中小企业用MFS.FASTDFS都可以 ** nginx反代的驱动

这个三个都可以作为图片存储

可以结合docker，直接基于容器启动

也比较适合存储图片 这个项目来讲还算是比较活跃的 mogilefs 维护率很低，是因为这个产品已经成熟了，没有什么bug需要修复

转载地址：http://idkgn.baihongyu.com/