关于分布式系统的简介

转载自：http://blog.csdn.net/fynjy/article/details/46955319

前几天因为收到一个面试，是关于系统同步的，查了一下发现有点分布式系统同步的意思。于是决心了解一下分布式系统。网上真的是好多牛人啊，我等菜鸟根据自己的理解整理一下（适合像我这样对这个东西没有概念的人），大牛请忽略，谢谢！

第一部分：关于分布式系统的热点和设计理念的介绍

（【来源】http://www.infoq.com/cn/articles/features-and-design-concept-of-distributed-system）

分布式系统并不是什么新鲜词，在上个世纪七八十年代就已经有各种分布式系统出现。只是在互联网时代，分布式系统才大放异彩，尤其是Google更是把分布式系统运用到了极致。Google整个的软件构架都是基于各种各样的分布式系统，诸如Borg、MapReduce、BigTable等。正是这些分布式系统，使得Google可以处理高并发请求响应以及海量数据处理等。Apache旗下的Hadoop、Spark、Mesos等分布式系统，把大数据处理相关技术变得非常亲民，让更多企业客户体会到了分布式系统的便利。

一、分布式系统的特点

分布式系统最大的特点是可扩展性，它能够适应需求变化而扩展。企业级应用需求经常随时间而不断变化，这也对企业级应用平台提出了很高的要求。企业级应用平台必须要能适应需求的变化，即具有可扩展性。比如移动互联网2C应用，随着互联网企业的业务规模不断增大，业务变得越来越复杂，并发用户请求越来越多，要处理的数据也越来越多，这个时候企业级应用平台必须能够适应这些变化，支持高并发访问和海量数据处理。分布式系统有良好的可扩展性，可以通过增加服务器数量来增强分布式系统整体的处理能力，以应对企业的业务增长带来的计算需求。

分布式系统的核心理念是让多台服务器协同工作，完成单台服务器无法处理的任务，尤其是高并发或者大数据量的任务。分布式系统由独立的服务器通过网络松散耦合组成的。每个服务器都是一台独立的PC机，服务器之间通过内部网络连接，内部网络速度一般比较快。因为分布式集群里的服务器是通过内部网络松散耦合，各节点之间的通讯有一定的网络开销，因此分布式系统在设计上尽可能减少节点间通讯。此外，因为网络传输瓶颈，单个节点的性能高低对分布式系统整体性能影响不大。比如，对分布式应用来说，采用不同编程语言开发带来的单个应用服务的性能差异，跟网络开销比起来都可以忽略不计。因此，分布式系统每个节点一般不采用高性能的服务器，而是性能相对一般的普通PC服务器。提升分布式系统的整体性能是要通过横向扩展（增加更多的服务器），而不是纵向扩展（提升每个节点的服务器性能）。

分布式系统最大的特点是廉价高效：由成本低廉的PC服务器组成的集群，在性能方面能够达到或超越大型机的处理性能，在成本上远低于大型机。这也是分布式系统最吸引人之处。成本低廉的PC服务器在硬件可靠性方面比大型机相去甚远，于是分布式系统由软件来对硬件进行容错，通过软件来保证整体系统的高可靠性。

分布式系统最大的好处是实现企业应用服务层面的弹性扩展。应用服务层面的弹性扩展是相对计算资源层面的弹性扩展而言的。一般公有云服务（IaaS）厂商都会提供计算资源层面的弹性扩展，比如可以很方便地增加或删除虚拟主机、提升或降低虚拟主机的性能配置等等。但是企业客户真正需要的是应用服务层面的弹性扩展，即随着业务量的涨落，后台应用服务的实例能动态变化，这是IaaS厂商还做不到的。比如，某移动互联网短视频分享应用，在晚间11点到凌晨1点是访问高峰，同时在线人数高达几十万，这时后台应用服务要扩张到数千个实例才能应付这么高并发的访问请求；过了高峰时段，后台应用服务可以收缩到几十个实例。有了分布式系统，就可以很方便地调度应用服务实例，从几十个到几百个甚至上千个，真正实现应用服务的弹性扩展。

二、分布式系统设计理念

上面简单介绍了分布式系统的基本情况，下面详细阐述笔者理解的几个分布式系统设计理念：

1. 分布式系统对服务器硬件要求很低

这一点主要现在如下两个方面：

• 对服务器硬件可靠性不做要求，允许服务器硬件发生故障，硬件的故障由软件来容错。所以分布式系统的高可靠性是由软件来保证。
• 对服务器的性能不做要求，不要求使用高频CPU、大容量内存、高性能存储等等。因为分布式系统的性能瓶颈在于节点间通讯带来的网络开销，单台服务器硬件性能再好，也要等待网络IO。

一般而言，互联网公司的大型数据中心都是选用大量廉价的PC服务器而不是用几台高性能服务器搭建分布式集群，以此来降低数据中心成本。比如，Google对于数据中心的成本控制做到了极致：所有服务器一律不要机箱；主板完全定制，只要最基本的组件，早期的定制主板连电源开关和USB接口都不要；在主板上加装隔离带把CPU单独隔出来，让冷风只吹CPU，不吹内存、硬盘等不需要降温的组件，最大限度降低冷却电力消耗。

2. 分布式系统强调横向可扩展性

横向可扩展性（Scale Out）是指通过增加服务器数量来提升集群整体性能。纵向可扩展性（Scale Up）是指提升每台服务器性能进而提升集群整体性能。纵向可扩展性的上限非常明显，单台服务器的性能不可能无限提升，而且跟服务器性能相比，网络开销才是分布式系统最大的瓶颈。横向可扩展性的上限空间比较大，集群总能很方便地增加服务器。而且分布式系统会尽可能保证横向扩展带来集群整体性能的（准）线性提升。比如有10台服务器组成的集群，横向扩展为100台同样服务器的集群，那么整体分布式系统性能会提升为接近原来的10倍。

互联网公司的数据中心，一般一个分布式系统横向扩展的上限在万台服务器左右。Google数据中心的基本单元，CELL，由两万台左右服务器组成，每个CELL由一套分布式管理系统，BORG，统一管理，每个数据中心都由多个CELL组成。

3. 分布式系统不允许单点失效（No Single Point Failure）

单点失效是指，某个应用服务只有一份实例运行在某一台服务器上，这台服务器一旦挂掉，那么这个应用服务必然也受影响而挂掉，导致整个服务不可用。例如，某网站后台如果只在某一台服务器上运行一份，那这台服务器一旦宕机，该网站服务必然受影响而不可用。再比如，如果所有数据都存在某一台服务器上，那一旦这台服务器坏了，所有数据都不可访问。

因为分布式系统的服务器都是廉价的PC服务器，硬件不能保证100%可靠，所以分布式系统默认每台服务器随时都可能发生故障挂掉。同时分布式系统必须要提供高可靠服务，不允许出现单点失效，因此分布式系统里运行的每个应用服务都有多个运行实例跑在多个节点上，每个数据点都有多个备份存在不同的节点上。这样一来，多个节点同时发生故障，导致某个应用服务的所有实例都挂掉、或某个数据点的多个备份都不可读的概率大大降低，进而有效防止单点失效。

通常情况，不要让服务器满负荷运行，服务器长时间满负荷运行的话，出故障的概率显著升高。所以分布式系统采用一大堆中低性能的PC服务器，尽可能把负载均摊到所有服务器上，让每台服务器的负载都不高，保证集群整体稳定性。

4. 分布式系统尽可能减少节点间通讯开销

如前所述，分布式系统的整体性能瓶颈在于内部网络开销。目前网络传输的速度还赶不上CPU读取内存或硬盘的速度，所以减少网络通讯开销，让CPU尽可能处理内存的数据或本地硬盘的数据，能显著提高分布式系统的性能。典型的例子就是Hadoop MapReduce，把计算任务分配到要处理的数据所在的节点上运行，从而避免在网络上传输数据。

5. 分布式系统应用服务最好做成无状态的

应用服务的状态是指运行时程序因为处理服务请求而存在内存的数据。分布式应用服务最好是设计成无状态。因为如果应用程序是有状态的，那么一旦服务器宕机就会使得应用服务程序受影响而挂掉，那存在内存的数据也就丢失了，这显然不是高可靠的服务。把应用服务设计成无状态的，让程序把需要保存的数据都保存在专门的存储上，这样应用服务程序可以任意重启而不丢失数据，方便分布式系统在服务器宕机后恢复应用服务。

比如，在设计网站后台的时候，对于用户登陆请求，可以把登陆用户的session相关信息保存在Redis或Memcache等缓存服务中，这样每个网站的后台实例不保存用户登录状态，这样即使重启网站后台程序也不丢失用户的登录状态信息；如果把用户的session相关信息保存在网站后台程序的内存里，那一旦受理用户登录的网站后台程序实例挂掉，必然有用户的登录状态信息会丢失。

总而言之，分布式系统是大数据时代企业级应用的首选平台，它有良好的可扩展性，尤其是横向可扩展性（Scale Out），使得分布式系统非常灵活，能应对千变万化的企业级需求，而且降低了企业客户对服务器硬件的要求，真正能做到应用服务层面的弹性扩展（auto-scaling）。

第二部分：关于Hadoop介绍

【来源】http://blog.csdn.net/wengyupeng/article/details/5083881

我觉得这个人讲的让我觉得比较好理解。所以就整理在这里了

 Hadoop是Apache开源组织的一个分布式计算开源框架(http://hadoop.apache.org/)，在很多大型网站上都已经得到了应用，如亚马逊、Facebook和Yahoo等等。对于我来说，最近的一个使用点就是服务集成平台的日志分析。服务集成平台的日志量将会很大，而这也正好符合了分布式计算的适用场景（日志分析和索引建立就是两大应用场景）。

什么是Hadoop？

       Hadoop框架中最核心的设计就是：MapReduce和HDFS。MapReduce的思想是由Google的一篇论文所提及而被广为流传的，简单的一句话解释MapReduce就是“任务的分解与结果的汇总”。HDFS是Hadoop分布式文件系统（Hadoop Distributed File System）的缩写，为分布式计算存储提供了底层支持。

       MapReduce从它名字上来看就大致可以看出个缘由，两个动词Map和Reduce，“Map（展开）”就是将一个任务分解成为多个任务，“Reduce”就是将分解后多任务处理的结果汇总起来，得出最后的分析结果。这不是什么新思想，其实在前面提到的多线程，多任务的设计就可以找到这种思想的影子。不论是现实社会，还是在程序设计中，一项工作往往可以被拆分成为多个任务，任务之间的关系可以分为两种：一种是不相关的任务，可以并行执行；另一种是任务之间有相互的依赖，先后顺序不能够颠倒，这类任务是无法并行处理的。回到大学时期，教授上课时让大家去分析关键路径，无非就是找最省时的任务分解执行方式。在分布式系统中，机器集群就可以看作硬件资源池，将并行的任务拆分，然后交由每一个空闲机器资源去处理，能够极大地提高计算效率，同时这种资源无关性，对于计算集群的扩展无疑提供了最好的设计保证。（其实我一直认为Hadoop的卡通图标不应该是一个小象，应该是蚂蚁，分布式计算就好比蚂蚁吃大象，廉价的机器群可以匹敌任何高性能的计算机，纵向扩展的曲线始终敌不过横向扩展的斜线）。任务分解处理以后，那就需要将处理以后的结果再汇总起来，这就是Reduce要做的工作。

图1：MapReduce结构示意图

 

上图就是MapReduce大致的结构图，在Map前还可能会对输入的数据有Split（分割）的过程，保证任务并行效率，在Map之后还会有Shuffle（混合）的过程，对于提高Reduce的效率以及减小数据传输的压力有很大的帮助。后面会具体提及这些部分的细节。

HDFS是分布式计算的存储基石，Hadoop的分布式文件系统和其他分布式文件系统有很多类似的特质。分布式文件系统基本的几个特点：

1. 对于整个集群有单一的命名空间。
2. 数据一致性。适合一次写入多次读取的模型，客户端在文件没有被成功创建之前无法看到文件存在。
3. 文件会被分割成多个文件块，每个文件块被分配存储到数据节点上，而且根据配置会由复制文件块来保证数据的安全性。

图2：HDFS结构示意图

 

上图中展现了整个HDFS三个重要角色：NameNode、DataNode和Client。NameNode可以看作是分布式文件系统中的管理者，主要负责管理文件系统的命名空间、集群配置信息和存储块的复制等。NameNode会将文件系统的Meta-data存储在内存中，这些信息主要包括了文件信息、每一个文件对应的文件块的信息和每一个文件块在DataNode的信息等。DataNode是文件存储的基本单元，它将Block存储在本地文件系统中，保存了Block的Meta-data，同时周期性地将所有存在的Block信息发送给NameNode。Client就是需要获取分布式文件系统文件的应用程序。这里通过三个操作来说明他们之间的交互关系。

文件写入：

1. Client向NameNode发起文件写入的请求。
2. NameNode根据文件大小和文件块配置情况，返回给Client它所管理部分DataNode的信息。
3. Client将文件划分为多个Block，根据DataNode的地址信息，按顺序写入到每一个DataNode块中。

文件读取：

1. Client向NameNode发起文件读取的请求。
2. NameNode返回文件存储的DataNode的信息。
3. Client读取文件信息。

文件Block复制：

1. NameNode发现部分文件的Block不符合最小复制数或者部分DataNode失效。
2. 通知DataNode相互复制Block。
3. DataNode开始直接相互复制。

最后再说一下HDFS的几个设计特点（对于框架设计值得借鉴）：

1. Block的放置：默认不配置。一个Block会有三份备份，一份放在NameNode指定的DataNode，另一份放在与指定DataNode非同一Rack上的DataNode，最后一份放在与指定DataNode同一Rack上的DataNode上。备份无非就是为了数据安全，考虑同一Rack的失败情况以及不同Rack之间数据拷贝性能问题就采用这种配置方式。
2. 心跳检测DataNode的健康状况，如果发现问题就采取数据备份的方式来保证数据的安全性。
3. 数据复制（场景为DataNode失败、需要平衡DataNode的存储利用率和需要平衡DataNode数据交互压力等情况）：这里先说一下，使用HDFS的balancer命令，可以配置一个Threshold来平衡每一个DataNode磁盘利用率。例如设置了Threshold为10%，那么执行balancer命令的时候，首先统计所有DataNode的磁盘利用率的均值，然后判断如果某一个DataNode的磁盘利用率超过这个均值Threshold以上，那么将会把这个DataNode的block转移到磁盘利用率低的DataNode，这对于新节点的加入来说十分有用。
4. 数据交验：采用CRC32作数据交验。在文件Block写入的时候除了写入数据还会写入交验信息，在读取的时候需要交验后再读入。
5. NameNode是单点：如果失败的话，任务处理信息将会纪录在本地文件系统和远端的文件系统中。
6. 数据管道性的写入：当客户端要写入文件到DataNode上，首先客户端读取一个Block然后写到第一个DataNode上，然后由第一个DataNode传递到备份的DataNode上，一直到所有需要写入这个Block的NataNode都成功写入，客户端才会继续开始写下一个Block。
7. 安全模式：在分布式文件系统启动的时候，开始的时候会有安全模式，当分布式文件系统处于安全模式的情况下，文件系统中的内容不允许修改也不允许删除，直到安全模式结束。安全模式主要是为了系统启动的时候检查各个DataNode上数据块的有效性，同时根据策略必要的复制或者删除部分数据块。运行期通过命令也可以进入安全模式。在实践过程中，系统启动的时候去修改和删除文件也会有安全模式不允许修改的出错提示，只需要等待一会儿即可。

下面综合MapReduce和HDFS来看Hadoop的结构：

图3：Hadoop结构示意图

 

在Hadoop的系统中，会有一台Master，主要负责NameNode的工作以及JobTracker的工作。JobTracker的主要职责就是启动、跟踪和调度各个Slave的任务执行。还会有多台Slave，每一台Slave通常具有DataNode的功能并负责TaskTracker的工作。TaskTracker根据应用要求来结合本地数据执行Map任务以及Reduce任务。

说到这里，就要提到分布式计算最重要的一个设计点：Moving Computation is Cheaper than Moving Data。就是在分布式处理中，移动数据的代价总是高于转移计算的代价。简单来说就是分而治之的工作，需要将数据也分而存储，本地任务处理本地数据然后归总，这样才会保证分布式计算的高效性。

为什么要选择Hadoop？

说完了What，简单地说一下Why。官方网站已经给了很多的说明，这里就大致说一下其优点及使用的场景（没有不好的工具，只用不适用的工具，因此选择好场景才能够真正发挥分布式计算的作用）：

1. 可扩展：不论是存储的可扩展还是计算的可扩展都是Hadoop的设计根本。
2. 经济：框架可以运行在任何普通的PC上。
3. 可靠：分布式文件系统的备份恢复机制以及MapReduce的任务监控保证了分布式处理的可靠性。
4. 高效：分布式文件系统的高效数据交互实现以及MapReduce结合Local Data处理的模式，为高效处理海量的信息作了基础准备。

使用场景：个人觉得最适合的就是海量数据的分析，其实Google最早提出MapReduce也就是为了海量数据分析。同时HDFS最早是为了搜索引擎实现而开发的，后来才被用于分布式计算框架中。海量数据被分割于多个节点，然后由每一个节点并行计算，将得出的结果归并到输出。同时第一阶段的输出又可以作为下一阶段计算的输入，因此可以想象到一个树状结构的分布式计算图，在不同阶段都有不同产出，同时并行和串行结合的计算也可以很好地在分布式集群的资源下得以高效的处理。

第三部分：关于HDFS进一步的理解和介绍

（【来源】http://my.oschina.net/shiw019/blog/92771）

HDFS是Hadoop Distribute File System 的简称，也就是Hadoop的一个分布式文件系统。

一、HDFS的主要设计理念

1、存储超大文件

    这里的“超大文件”是指几百MB、GB甚至TB级别的文件。

2、最高效的访问模式是 一次写入、多次读取(流式数据访问)

    HDFS存储的数据集作为hadoop的分析对象。在数据集生成后，长时间在此数据集上进行各种分析。每次分析都将设计该数据集的大部分数据甚至全部数据，因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要。

3、运行在普通廉价的服务器上

HDFS设计理念之一就是让它能运行在普通的硬件之上，即便硬件出现故障，也可以通过容错策略来保证数据的高可用。

二、HDFS的忌讳

1、将HDFS用于对数据访问要求低延迟的场景

    由于HDFS是为高数据吞吐量应用而设计的，必然以高延迟为代价。

2、存储大量小文件

    HDFS中元数据（文件的基本信息）存储在namenode的内存中，而namenode为单点，小文件数量大到一定程度，namenode内存就吃不消了。

三、HDFS基本概念

数据块（block）：大文件会被分割成多个block进行存储，block大小默认为64MB。每一个block会在多个datanode上存储多份副本，默认是3份。

namenode：namenode负责管理文件目录、文件和block的对应关系以及block和datanode的对应关系。

datanode：datanode就负责存储了，当然大部分容错机制都是在datanode上实现的。

四、HDFS基本架构图

图中有几个概念需要介绍一下

Rack 是指机柜的意思，一个block的三个副本通常会保存到两个或者两个以上的机柜中（当然是机柜中的服务器），这样做的目的是做防灾容错，因为发生一个机柜掉电或者一个机柜的交换机挂了的概率还是蛮高的。

五、HDFS写文件流程

思考：

    在datanode执行create file后，namenode采用什么策略给client分配datanode？

    顺序写入三个datanode，写入过程中有一个datanode挂掉了，如何容错？

    client往datanode写入数据时挂掉了，怎么容错？

六、HDFS读文件流程

【注】以后还可以研究的http://agapple.iteye.com/blog/1929370