hadoop3.0新特性

下图简单看一下hadoop的发展史

思想: 通过引用数据校验块,使其和原始数据校验块编码产生关联关系,然后听过关联关系恢复,这个技术依赖于线性代数一些姿势

用处: 用于数据的恢复,可以提高磁盘的利用率

缺点: 时间换空间产物,因为编码解码会浪费时间

纠删码技术原理解释:

假设

x1=1;

x2=2;

x3=3

x1+2 x2+4 x3=17

x1+2 x2+3 x3=14

根据上面一组方程求x1,x2,x3的值,其实虽然有5个方程,其实最少只需要有三个方程就能求出来另外两个方程

把上面这个原理对应到数据里面就是

x1,x2,x3就相当于是原始数据,

x1+2 x2+4 x3=17

x1+2 x2+3 x3=14

这两个方程结果为校验值,

就是假如只有x1这个数据块,但是有下面连个方程,是不是就可以求出对应的x2,和x3了,

如果一个数据是被是3个原始的数据块:

备份机制中:采用2复本机制,至少需要6个数据块才能够保证数据的可靠性,即每个各备份一个即可,

如果是数据块的这种,最少需要4个,他可以容许你的一个数据块的丢失,比如把1丢了,剩下的2和3剩下,通过一个方程就能求出来1的内容,就可以允许一个数据块丢失

之前数据丢失了,直接从别的服务器位置拷贝一个过来就行,hadoop3用纠删码就需要号计算,还需要拿到另外块的数据和计算公式,因为他是要计算的,比如1,2,3三块数据块,比如采用纠删码存储技术,就可以把1号数据丢失,但是某天需要用到1号,数据,就需要从新计算恢复,所以这个就需要耗费时间

但是我觉得吧,比如hadoop以后可以在这个基础上优化一下

比如说三台服务器,一个文件被切割成了1,2,3三份,具体存储如下

上面三个为纠删码存储方式

下面三个为正常存储方式

hadoop正在往这个方向优化

即先从其他服务器找这个数据块,找不到再用纠删码计算

所以纠删码用于存储冷数据,冷数据指的是平时很少用到的数据

这个用法创建一个eraszing zone(空间),然后放在这个空间的数据,创建目录,把需要纠删码技术存储的把这个文件放到这个路径即可

比如之前的数据时热门的,但是之前并不是存储在这个eraszing zone里面,但是现在就是冷数据,食之无味,弃之可惜,鸡肋也,所以就可以在这个数据拷贝到这个eraszing zone里面,然后把那旧数据原位置删除就行,hadoop也在做一种简单的办法,通过一个命令,修改这个冷数据的存储方式,hadoop正在做,

所以30的冷数据还是建议使用这种备份机制,冷门数据是用纠删码(时间换空间)

namenode的HA升级了,支持两个以上的namemode,

例如，通过配置三个NameNode和五个JournalNode，群集能够容忍两个节点的故障，而不是一个故障。

但是Active的NameNode始终只有1个，余下的都是Standby。 Standby NN会不断与JN同步，保证自己获取最新的editlog，并将edits同步到自己维护的image中去，这样便可以实现热备，在发生failover的时候，立马切换成active状态，对外提供服务。同时，JN只允许一个active状态的NN写入

以前是支持亚马逊的,现在30支持了更多的,尤其是阿里云,说明阿里云正在走向壮大

增加DataNode的 内部 负载均衡,之前是DataNode之间的负载均衡,现在是DataNode内部的负载均衡,比如DataNode这台机器有三块磁盘,然后发现只有一块磁盘写满了,另外两块磁盘都没怎么用,这时候输入一个命令,他就可以帮你重新分配一下

现在可以通过hdfs diskbalancer命令，进行节点内部硬盘间的数据平衡。该功能默认是关闭的，需要手动设置参数dfsdiskbalancerenabled为true来开启。

yarn timeline service做了升级,yarn timeline service是yarn是资源管理和任务调度,这timeline service就是监控这个任务的,什么时候启动的,用到了哪些资源,可以用时间序列这个结构来存储这个结构,hadoop的25之前,通过jobhistory server来提供任务监控信息的收集,但是他有缺点,底层扩展性和可靠性不高,因为做这个数据量也挺大的,所以在30作了相应的修改

支持opportunistic(机会主义的) containers(容器)和distributed(分布式) scheduling(调度)

在hadoop上面的跑的任务,对资源都是争抢的状态,但是有时候需要协调人物的优先级,在hadoop30跑的时候,比如MapReduce任务,hive任务过来,对底层资源都是争抢状态,所以就需要协调人物的优先级,hadoop30的yarn就是比较灵活,比如任务在跑的时候,指定了优先级也好,指定了比如2核,8G的固定资源也好,有时候某个时间点根本用不到这么多资源,那个时间段可能只用了一半,释放了一半,这个opportunistic(机会主义的) containers(容器)就可以让不这么重要的任务临时用一下这个临时的资源

yarn配置资源可以配置的更加细化,比如原先是只支持线级别,现在支持点级别

比如这个hive依赖hadoopclient,但是还依赖某一个jar包的10版本,但是呢,这个hadoopclient依赖这个jar包的20版本,然后这两个jar包放到一起,肯定报错,因为名字一样,版本不一样,使用就会紊乱

优化,将这个hadoop client的jar包放到另外一个空间,隔离起来,这样就不会乱了

以上内容纯手敲,如有疑问或者错误请留言或者私信

以上内容纯手敲,如有疑问或者错误请留言或者私信

以上内容纯手敲,如有疑问或者错误请留言或者私信

sql运行问题？

数据库运行过程中常见的故障有3类：事物故障、系统故障、介质故障。

恢复策略：

1、事物故障：

发生事务故障时，被迫中断的事务可能已对数据库进行丁修改，为了消除该事务对数据库的影响，要利用日志文件中所记载的信息，强行回滚该事务，将数据库恢复到修改前的初始状态。

为此，要检查日志文件中由这些事务所引起的发生变化的记录，取消这些没有完成的事务所做的一切改变，这类恢复操作称为事务撤销。

2、系统故障：

系统故障的恢复要完成两方面的工作，既要撤销所有末完成的事务，还要重做所有已提交的事务，这样才能将数据库真正恢复到一致的状态。

3、介质故障：

介质故障比事务故障和系统故障发生的可能性要小，但这是最严重的一种故障，破坏性很大，磁盘上的物理数据和日志文件可能被破坏，这需要装入发生介质故障前最新的后备数据库副本，然后利用日志文件重做该副本后所运行的所有事务。

“数据故障恢复”和“完整性约束”、“并e799bee5baa6e4b893e5b19e31333431353364发控制”一样，都是数据库数据保护机制中的一种完整性控制。所有的系统都免不了会发生故障，有可能是硬件失灵，有可能是软件系统崩溃，也有可能是其他外界的原因，比如断电等等。

数据库运行的突然中断会使数据库处在一个错误的状态，而且故障排除后没有办法让系统精确地从断点继续执行下去。这就要求DBMS要有一套故障后的数据恢复机构，保证数据库能够回复到一致的、正确地状态去。

1 HDFS中的一些概念

HDFS（Hadoop Distributed File System）：分布式文件系统，将一个文件分成多个块，分别存储(拷贝)到不同的节点上，它是Hadoop体系中数据存储管理的基础。它是一个高度容错的系统，能检测和应对硬件故障，用于在低成本的通用硬件上运行。HDFS简化了文件的一致性模型，通过流式数据访问，提供高吞吐量应用程序数据访问功能，适合带有大型数据集的应用程序。

11 数据块

每个磁盘都有数据块的概念，在HDFS中也有数据块的概念，HDFS中的所有文件都是分割成块存储在Datanode上的，每个块默认64M。。每个块都有多个副本存储在不同的机器上：默认有3个副本，3个副本不可能存放在同一个机器上。 

HDFS副本存放策略 

以下是HDFS文件存储架构图 

**：表示每台机器 

绿色：文件被分割出的块 

例如： 

上图中part-0文件，有2个块。块1和块3只在2个机器上分别出现过2次。 

上图中part-1文件，有3个块。块2,4,5分别在不同的机器上各出现3次

HDFS中也可以显示块信息，使用fsck命令 

例如：下面的命令将列出文件系统中各个文件由哪些块构成

$ hadoop fsck / -files -blocks

12 NameNode和DataNode

HDFS的设计是主（Master）从（Slave）结构的。也就是，一个管理者（NameNode）和多个工作者（DataNode）组成。

121 管理者：Namenode

NameNode是主节点，它是一个中心服务器，负责管理整个文件系统的命名空间和控制着客户端对文件的访问。它不保存文件的内容，而是保存着文件的元数据（文件名称，所在目录，文件权限，文件拥有者，文件有多少块，每个块有多少副本，块都存在哪些节点上）。 

Namenode负责文件的元数据操作，Datanode处理文件内容的读写请求。 

跟文件相关的流不经过Namenode，只会询问该文件跟哪个Datanode有关系。 

副本存放在哪些Datanode上是由Namenode来控制。读取文件时，Namenode尽量让用户先读取最近的副本。 

Namenode全权管理数据块的复制，周期性的从集群中的每个Datanode接收心跳信号和块状态报告。 

Namenode和Datanode就是通过这两种方式来进行通信： 

心跳信号：意味着该Datanode节点工作正常 

块状态报告：包含了一个该Datanode上所有数据块的列表

元数据保存在内存中 

Namenode维护着整个文件系统树以及树内的所有文件。这些信息以两个文件的形式永久保存在磁盘上。命名空间镜像文件（fsimage）和操作日志（fsedits）文件 

1 fsimage是什么？ 

fsimage是元数据镜像文件：Namenode启动后，文件的元数据被加载到内存中，加载到内存后也会把这些元数据写入到本地的磁盘中，这个文件就是fsimage文件。 

元数据镜像在内存中保存一份最新的，内存中的镜像=fsimage+fsedit 

2 fsedits是什么？ 

fsedits是元数据操作日志文件：客户端要对文件进行读写操作，在这些操作产生的日志就存在了fsedit文件中。

121 工作者：Datanode

DataNode是从节点，它的作用很简单，就是存储文件的块数据。以及块数据的校验和。 

一个数据块在Ddtanode以文件存储在磁盘上，包括两个文件：数据本身和元数据（数据块的长度，块数据的校验和，时间戳） 

Datanode启动后向Namenode注册，通过后，周期性（1小时）的向Namenode上报所有块信息。 

心跳是3秒一次，如果超过10分钟没有收到某个Datanode的心跳。则认为该节点不可用。

13 Secondary Namenode

Secondary Namenode：Secondary表示助手的意思，也就是说Secondary Namenode表示NameNode的助手，辅助NameNode工作的一个节点。要了解Secondary Namenode节点都辅助NameNode做了哪些工作，我们需要先回顾下NameNode是做什么的？ 

NameNode是HDFS中的一个主节点，主要是来管理其他DataNode从节点。它存储了HDFS系统的namespace和控制着客户端对HDFS文件系统的访问。NameNode在维护整个文件系统树的时候是以两个文件的形式永久保存在磁盘上。镜像文件(fsimage)和操作日志文件（fsedits）。考虑以下，这两个文件一直这样运行存在着有什么问题？

fsedits操作日志文件会越来越大，因为它保存着客户端对HDFS文件系统的访问日志。

只有在NameNode重启后，edits logs才会合并到fsimage中，产生一个新的文件系统快照。但是NameNode是很少重启的。 

为了保证edit logs文件不会太大和fsimage是一个最新的文件，此时需要一个节点来备份这些文件。定期的合并这两个文件然后再推送给NameNode，这样就减轻NameNode工作的压力，同时也保证了假如Namenode节点宕机后数据无法恢复问题。虽然可能不会把所有的数据全部恢复出来，但是至少丢失的很少。

所以，Secondary Namenode做的就是这些辅助工作

Secondary NameNode所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的备份。

SecondaryNameNode有两个作用，一是镜像备份，二是日志与镜像的定期合并。两个过程同时进行，称为checkpoint

在core-sitexml配置文件中有2个参数可配置，但一般来说我们不做修改。fscheckpointperiod表示多长时间记录一次hdfs的镜像。默认是1小时。fscheckpointsize表示一次记录多大的size，默认64M。

<property>    <name>fscheckpointperiod</name>    <value>3600</value>    <description>The number of seconds between two periodic checkpoints    </description></property><property>    <name>fscheckpointsize</name>    <value>67108864</value>    <description>The size of the current edit log (in bytes) that triggers a periodic checkpoint even if the fscheckpointperiod hasn’t expired    </description></property>

可以参考这篇博客，写的还是很详细的Secondary NameNode:它究竟有什么作用？

14 HDFS的优缺点

优点：

高容错性 

数据自动保存多个副本 

副本丢失后，自动恢复

适合批处理 

移动计算而非数据 

数据位置暴露给计算框架

适合大数据处理 

GB、TB、甚至PB级数据 

百万规模以上的文件数量 

10K+节点规模

流式文件访问 

一次性写入，多次读取 

保证数据一致性

可构建在廉价机器上 

通过多副本提高可靠性 

提供了容错和恢复机制

缺点：

低延迟与高吞吐率的数据访问 ，比如毫秒级

小文件存取 

占用NameNode大量内存 

寻道时间超过读取时间

并发写入、文件随机修改 

一个文件同一个时间只能有一个写者 

仅支持append

2 HDFS的架构

HDFS以流式数据访问（一次写入，多次读取）模式来存储超大文件，运行于商用硬件集群上。超大文件是指GB,TB,PB的文件。目前已经有存储到PB级别的Hadoop集群了。

计算机字节关系 

Hadoop1x HDFS官方架构图 

21 HDFS架构之NameNode和DataNode

HDFS架构图 

客户端（HDFS Client）：如果想对文件进行读写的话，首先需要通过Namenode来获取一些信息。Namenode存储着命名空间（namespace）和元数据（metadata） 

客户端有如下工作：

文件的切分

与Namenode交互，获取文件位置信息

与Datanode交互，读取或者写入数据

管理HDFS

访问HDFS（浏览器，Shell命令，JavaAPI）

辅助节点（Secondary）：用于辅助Namenode工作，分担其工作量。主要工作是nameSpace的冷备份工作，并非热备份。定期将Namenode的镜像文件（fsimage）和操作日志（fsedit）进行合并，然后推送给Namenode 

1 fsimage是什么？ 

是元数据镜像文件：Namenode启动后，文件的元数据被加载到内存中，加载到内存后也会把这些元数据写入到本地的磁盘中，这个文件就是fsimage文件。 

元数据镜像在内存中保存一份最新的，内存中的镜像=fsimage+fsedit 

2 fsedits是什么？ 

是元数据操作日志文件：客户端要对文件进行读写操作，在这些操作产生的日志就存在了fsedit文件中。

数据节点（Datanode）：Namenode和Datanode通信是通过心跳和块报告。每个文件被分割成不同的块，存在不同的机器的本地磁盘上。

22 Namenode和Secondary Namenode运行关系

 

Secondarynamenode工作原理 

日志与镜像的定期合并总共分以下五步：

Secondary Namenode通知Namenode切换editlog

Secondary Namenode通过Http方式从Namenode获取fsimage和editlog

Secondary Namenode将fsimage载入内存，然后开始合并editlog

Secondary Namenode将新的fsimage发回给Namenode

Namenode收到fsiamge后将新的fsimage替换旧的fsimage

3 HDFS文件的读写流程

31 HDFS文件的读取

HDFS文件读取： 

首先调用FileSystem对象的open方法，其实是一个DistributedFileSystem的实例

DistributedFileSystem通过rpc获得文件的第一批个block的locations，同一block按照重复数会返回多个locations，这些locations按照hadoop拓扑结构排序，距离客户端近的排在前面

前两步会返回一个FSDataInputStream对象，该对象会被封装成DFSInputStream对象，DFSInputStream可以方便的管理datanode和namenode数据流。客户端调用read方法，DFSInputStream最会找出离客户端最近的datanode并连接。

数据从datanode源源不断的流向客户端。

如果第一块的数据读完了，就会关闭指向第一块的datanode连接，接着读取下一块。这些操作对客户端来说是透明的，客户端的角度看来只是读一个持续不断的流。

如果第一批block都读完了，DFSInputStream就会去namenode拿下一批blocks的location，然后继续读，如果所有的块都读完，这时就会关闭掉所有的流。

32 HDFS文件的写入

HDFS文件写入： 

客户端通过调用DistributedFileSystem的create方法创建新文件

DistributedFileSystem通过RPC调用namenode去创建一个没有blocks关联的新文件，创建前，namenode会做各种校验，比如文件是否存在，客户端有无权限去创建等。如果校验通过，namenode就会记录下新文件，否则就会抛出IO异常

前两步结束后会返回FSDataOutputStream的对象，和读文件的时候相似，FSDataOutputStream被封装成DFSOutputStream，DFSOutputStream可以协调namenode和datanode。客户端开始写数据到DFSOutputStream,DFSOutputStream会把数据切成一个个小packet，然后排成队列data quene。

DataStreamer会去处理接受data quene，他先问询namenode这个新的block最适合存储的在哪几个datanode里，比如重复数是3，那么就找到3个最适合的datanode，把他们排成一个pipelineDataStreamer把packet按队列输出到管道的第一个datanode中，第一个datanode又把packet输出到第二个datanode中，以此类推。

DFSOutputStream还有一个对列叫ack quene，也是有packet组成，等待datanode的收到响应，当pipeline中的所有datanode都表示已经收到的时候，这时akc quene才会把对应的packet包移除掉。

客户端完成写数据后调用close方法关闭写入流

DataStreamer把剩余得包都刷到pipeline里然后等待ack信息，收到最后一个ack后，通知datanode把文件标示为已完成。

大数据中最宝贵、最难以代替的就是数据，一切都围绕数据。

HDFS是最早的大数据存储系统，存储着宝贵的数据资产，各种新算法、框架要想得到广泛使用，必须支持HDFS，才能获取已存储在里面的数据。所以大数据技术越发展，新技术越多，HDFS得到的支持越多，越离不开HDFS。 HDFS也许不是最好的大数据存储技术，但依然是最重要的大数据存储技术 。

HDFS是如何实现大数据高速、可靠的存储和访问的呢？

Hadoop分布式文件系统HDFS的设计目标是管理数以千计的服务器、数以万计的磁盘，将大规模的服务器计算资源当作一个单一存储系统进行管理，对应用程序提供数以PB计的存储容量，让应用程序像使用普通文件系统一样存储大规模的文件数据。

文件以多副本的方式进行存储：

缺点：

优点：

HDFS的大容量存储和高速访问的实现。

RAID将数据分片后，在多块磁盘上并发进行读写访问，提高了存储容量、加快了访问速度，并通过数据冗余校验提高了数据可靠性，即使某块磁盘损坏也不会丢数据。将RAID的设计理念扩大到整个分布式服务器集群，就产生了分布式文件系统，这便是Hadoop分布式文件系统的核心原理。

和RAID在多个磁盘上进行文件存储及并行读写的思路一样，HDFS是在一个大规模分布式服务器集群上，对数据分片后进行并行读写及冗余存储。因为HDFS可部署在一个大的服务器集群，集群中所有服务器的磁盘都可供HDFS使用，所以整个HDFS的存储空间可以达到PB级。

HDFS是主从架构。一个HDFS集群会有一个NameNode（命名节点，简称NN），作为主服务器（master server）。

HDFS公开了文件系统名称空间，允许用户将数据存储在文件中，就好比我们平时使用os中的文件系统一样，用户无需关心底层是如何存储数据的。 在底层，一个文件会被分成一或多个数据块，这些数据库块会被存储在一组数据节点中。在CDH中数据块的默认128M。 在NameNode，可执行文件系统的命名空间操作，如打开，关闭，重命名文件等。这也决定了数据块到数据节点的映射。

HDFS被设计为可运行在普通的廉价机器上，而这些机器通常运行着一个Linux操作系统。一个典型的HDFS集群部署会有一个专门的机器只能运行 NameNode ，而其他集群中的机器各自运行一个 DataNode 实例。虽然一台机器上也可以运行多个节点，但不推荐。

负责文件数据的存储和读写操作，HDFS将文件数据分割成若干数据块（Block），每个DataNode存储一部分Block，这样文件就分布存储在整个HDFS服务器集群中。

应用程序客户端（Client）可并行访问这些Block，从而使得HDFS可以在服务器集群规模上实现数据并行访问，极大提高访问速度。

HDFS集群的DataNode服务器会有很多台，一般在几百台到几千台，每台服务器配有数块磁盘，整个集群的存储容量大概在几PB~数百PB。

负责整个分布式文件系统的元数据（MetaData）管理，即文件路径名、数据块的ID以及存储位置等信息，类似os中的文件分配表（FAT）。

HDFS为保证数据高可用，会将一个Block复制为多份（默认3份），并将多份相同的Block存储在不同服务器，甚至不同机架。当有磁盘损坏或某个DataNode服务器宕机，甚至某个交换机宕机，导致其存储的数据块不能访问时，客户端会查找其备份Block访问。

HDFS中，一个文件会被拆分为一个或多个数据块。默认每个数据块有三个副本，每个副本都存放在不同机器，而且每一个副本都有自己唯一的编号：

文件/users/sameerp/data/part-0的复制备份数设为2，存储的BlockID分别为1、3：

上述任一台服务器宕机后，每个数据块都至少还有一个备份存在，不会影响对文件/users/sameerp/data/part-0的访问。

和RAID一样，数据分成若干Block后，存储到不同服务器，实现数据大容量存储，并且不同分片的数据能并行进行读/写操作，实现数据的高速访问。

副本存放：NameNode节点选择一个DataNode节点去存储block副本的过程，该过程的策略是在可靠性和读写带宽间权衡。

《Hadoop权威指南》中的默认方式：

Google大数据“三驾马车”的第一驾是GFS（Google 文件系统），而Hadoop的第一个产品是HDFS，分布式文件存储是分布式计算的基础。

这些年来，各种计算框架、各种算法、各种应用场景不断推陈出新，但大数据存储的王者依然是HDFS。

磁盘介质在存储过程中受环境或者老化影响，其存储的数据可能会出现错乱。

HDFS对存储在DataNode上的数据块，计算并存储校验和（CheckSum）。在读数据时，重新计算读取出来的数据的校验和，校验不正确就抛异常，应用程序捕获异常后就到其他DataNode上读取备份数据。

DataNode监测到本机的某块磁盘损坏，就将该块磁盘上存储的所有BlockID报告给NameNode，NameNode检查这些数据块还在哪些DataNode上有备份，通知相应的DataNode服务器将对应的数据块复制到其他服务器上，以保证数据块的备份数满足要求。

DataNode会通过心跳和NameNode保持通信，如果DataNode超时未发送心跳，NameNode就会认为这个DataNode已经宕机失效，立即查找这个DataNode上存储的数据块有哪些，以及这些数据块还存储在哪些服务器上，随后通知这些服务器再复制一份数据块到其他服务器上，保证HDFS存储的数据块备份数符合用户设置的数目，即使再出现服务器宕机，也不会丢失数据。

NameNode是整个HDFS的核心，记录着HDFS文件分配表信息，所有的文件路径和数据块存储信息都保存在NameNode，如果NameNode故障，整个HDFS系统集群都无法使用；如果NameNode上记录的数据丢失，整个集群所有DataNode存储的数据也就没用了。

所以，NameNode高可用容错能力非常重要。NameNode采用主从热备的方式提供高可用服务：

集群部署两台NameNode服务器：

两台服务器通过Zk选举，主要是通过争夺znode锁资源，决定谁是主服务器。而DataNode则会向两个NameNode同时发送心跳数据，但是只有主NameNode才能向DataNode返回控制信息。

正常运行期，主从NameNode之间通过一个共享存储系统shared edits来同步文件系统的元数据信息。当主NameNode服务器宕机，从NameNode会通过ZooKeeper升级成为主服务器，并保证HDFS集群的元数据信息，也就是文件分配表信息完整一致。

软件系统，性能差点，用户也许可接受；使用体验差，也许也能忍受。但若可用性差，经常出故障不可用，就麻烦了；如果出现重要数据丢失，那开发摊上大事。

而分布式系统可能出故障地方又非常多，内存、CPU、主板、磁盘会损坏，服务器会宕机，网络会中断，机房会停电，所有这些都可能会引起软件系统的不可用，甚至数据永久丢失。

所以在设计分布式系统的时候，软件工程师一定要绷紧可用性这根弦，思考在各种可能的故障情况下，如何保证整个软件系统依然是可用的。

## 6 保证系统可用性的策略

任何程序、任何数据，都至少要有一个备份，也就是说程序至少要部署到两台服务器，数据至少要备份到另一台服务器上。此外，稍有规模的互联网企业都会建设多个数据中心，数据中心之间互相进行备份，用户请求可能会被分发到任何一个数据中心，即所谓的异地多活，在遭遇地域性的重大故障和自然灾害的时候，依然保证应用的高可用。

当要访问的程序或者数据无法访问时，需要将访问请求转移到备份的程序或者数据所在的服务器上，这也就是 失效转移 。失效转移你应该注意的是失效的鉴定，像NameNode这样主从服务器管理同一份数据的场景，如果从服务器错误地以为主服务器宕机而接管集群管理，会出现主从服务器一起对DataNode发送指令，进而导致集群混乱，也就是所谓的“脑裂”。这也是这类场景选举主服务器时，引入ZooKeeper的原因。ZooKeeper的工作原理，我将会在后面专门分析。

当大量的用户请求或者数据处理请求到达的时候，由于计算资源有限，可能无法处理如此大量的请求，进而导致资源耗尽，系统崩溃。这种情况下，可以拒绝部分请求，即进行 限流 ；也可以关闭部分功能，降低资源消耗，即进行 降级 。限流是互联网应用的常备功能，因为超出负载能力的访问流量在何时会突然到来，你根本无法预料，所以必须提前做好准备，当遇到突发高峰流量时，就可以立即启动限流。而降级通常是为可预知的场景准备的，比如电商的“双十一”促销，为了保障促销活动期间应用的核心功能能够正常运行，比如下单功能，可以对系统进行降级处理，关闭部分非重要功能，比如商品评价功能。

HDFS是如何通过大规模分布式服务器集群实现数据的大容量、高速、可靠存储、访问的。

1文件数据以数据块的方式进行切分，数据块可以存储在集群任意DataNode服务器上，所以HDFS存储的文件可以非常大，一个文件理论上可以占据整个HDFS服务器集群上的所有磁盘，实现了大容量存储。

2HDFS一般的访问模式是通过MapReduce程序在计算时读取，MapReduce对输入数据进行分片读取，通常一个分片就是一个数据块，每个数据块分配一个计算进程，这样就可以同时启动很多进程对一个HDFS文件的多个数据块进行并发访问，从而实现数据的高速访问。关于MapReduce的具体处理过程，我们会在专栏后面详细讨论。

3DataNode存储的数据块会进行复制，使每个数据块在集群里有多个备份，保证了数据的可靠性，并通过一系列的故障容错手段实现HDFS系统中主要组件的高可用，进而保证数据和整个系统的高可用。