分布式文件系统架构设计(20201126073806)
分布式系统架构设计
分布式系统架构设计分布式系统是由多个独立且自治的计算机节点通过网络互相通信和协同工作的系统。
在当今互联网和云计算的背景下，分布式系统已经成为了大规模数据处理和计算的基础设施。
在设计分布式系统架构时，需要考虑以下几个方面：1.可伸缩性：分布式系统的一个主要目标就是实现可伸缩性，即能够根据需求灵活扩展和缩减计算和存储资源。
为了实现可伸缩性，可以采用水平扩展的方式，将负载分布到多个计算节点上，通过增加或减少节点的数量来调整系统的总体能力。
2.容错性：由于分布式系统由多个节点组成，其中任何一个节点都可能发生故障。
因此，容错性是设计分布式系统时需要考虑的重要因素。
可以采用冗余备份的方式来保证系统的可靠性，如复制数据到多个节点，当一个节点发生故障时，可以从其他节点恢复数据。
3. 一致性：在分布式系统中，由于节点之间的通信延迟和可能的网络分区等原因，节点之间的数据可能存在不一致的情况。
为了保证数据的一致性，可以采用分布式一致性协议，如Paxos或Raft。
这些协议通过协同节点之间的操作顺序来保证数据的一致性。
4.可靠性：分布式系统的可靠性是指系统能够在发生故障时继续提供服务，并且在故障恢复后能够正常工作。
为了提高系统的可靠性，可以采用故障检测和故障恢复机制，如心跳检测和自动故障转移等。
此外，还可以使用容错技术，如容器化和虚拟化等，将系统运行在多个主机上，以减少单点故障。
5.可扩展性：可扩展性是指系统能够在负载增加时保持性能的稳定。
为了实现可扩展性，可以采用异步消息传递的方式来解耦系统的各个组件，利用消息队列来缓冲和调节高峰负载。
6.安全性：在设计分布式系统时，需要考虑数据和通信的安全性。
可以采用加密算法保护数据的机密性，使用数字签名和数字证书验证通信的合法性。
此外，还需要采用访问控制和身份认证等机制来保护系统的安全性。
在实际设计分布式系统时，可以采用一些经典的架构模式，如客户端-服务器模式、分布式数据库、MapReduce等。
分布式系统架构设计
分布式系统架构设计分布式系统架构设计是一个关键性的环节，它决定了整个系统的可靠性、可扩展性和性能。
一个好的架构设计可以提高系统的可用性，并且能够应对不同规模的负荷。
在分布式系统架构设计中，有几个关键的方面需要考虑，包括数据分割与分区、容错处理、通信协议和服务发现等。
一、数据分割与分区在分布式系统中，数据分布是非常重要的。
数据的分割与分区有助于提高系统的性能和伸缩性。
在进行数据分割与分区时，需要考虑以下几个方面：1. 数据的分割粒度：根据系统的实际需求，确定数据的分割粒度。
可以根据数据的特点、使用频率或者其他因素来进行分割，以达到负载均衡和高性能的目的。
2. 数据的分区策略：选择适当的分区策略，将数据分布到不同的节点上。
可以采用哈希分区、范围分区或者一致性哈希等策略，以实现数据的均衡分布和高可用性。
3. 数据的复制与同步：在分布式系统中，为了提高系统的可靠性和容错性，通常需要将数据进行复制和同步。
可以采用主从复制、多主复制或者分布式数据库等方式，来实现数据的备份和同步。
二、容错处理在分布式系统中，容错处理是非常重要的。
容错可以保证系统在面对节点故障或者网络故障时，能够继续正常运行。
在进行容错处理时，可以考虑以下几个方面：1. 副本和冗余：通过在系统中增加副本和冗余，可以提高系统的容错性和可用性。
可以采用主从复制、备份节点或者冗余路由等方式来实现。
2. 故障检测与恢复：及时检测节点故障，并采取相应的恢复措施。
可以采用心跳检测、超时设置或者一致性协议等方式来实现。
3. 容错算法和协议：选择适当的容错算法和协议，可以保证系统在面对故障时能够正确地处理。
可以采用Paxos、Raft或者拜占庭容错协议等方式来实现。
三、通信协议在分布式系统中，节点之间的通信非常重要。
选择合适的通信协议可以提高系统的性能和可靠性。
在进行通信协议的选择时，可以考虑以下几个方面：1. 可靠性与延迟：根据系统的实际需求，选择适当的通信协议。
分布式系统架构设计
分布式系统架构设计分布式系统架构设计是指将一个大型系统拆分成多个子系统，并通过网络连接起来，使得这些子系统能够并行工作，共同完成系统的功能需求。
在设计分布式系统架构时，需要考虑诸多因素，如可扩展性、容错性、数据一致性、性能等。
下面将从这些方面详细介绍分布式系统架构设计的内容。
首先，可扩展性是设计分布式系统的重要考虑因素之一、随着系统的规模增大，系统可能面临更高的负载压力，需要通过增加计算节点等方式来增加系统的容量。
因此，在设计分布式系统架构时，需要考虑如何实现系统的横向扩展性，使得新的节点能够简单地加入到系统中，并能够平衡负载。
其次，容错性也是一个关键的设计目标。
由于分布式系统中存在着网络延迟、节点故障等问题，因此需要考虑如何在节点故障时保证系统的正常运行。
通常的做法是通过冗余设计来提高系统的容错性，例如通过备份机制保证数据的可靠性，通过使用容器化技术保证节点的可替换性等。
数据一致性是分布式系统设计中的一个重要问题。
由于数据在不同的子系统中存储和处理，可能会面临数据一致性的问题。
在设计分布式系统架构时，可以采用两阶段提交协议、Paxos算法等技术来保证数据的一致性。
此外，还可以通过使用一致性哈希算法来解决数据分片的问题，将数据均匀地分布在不同的节点上，从而提高系统的性能。
性能是设计分布式系统时要考虑的另一个重要因素。
在分布式系统中，数据需要在不同的节点之间传输和处理，因此网络延迟、带宽等因素会影响系统的性能。
在架构设计时，可以使用缓存技术、异步消息队列等手段来优化系统的性能。
此外，还可以通过选择合适的数据存储引擎、调优系统配置等方式来提高系统的性能。
此外，随着云计算、大数据、物联网等技术的兴起，分布式系统架构设计面临着新的挑战和需求。
例如，在设计分布式系统架构时，需要考虑如何将系统部署在云环境中，充分利用云计算资源；如何处理大规模的数据流，实现实时分析和响应；如何处理大量的设备连接，保证系统的可扩展性和性能等。
分布式文件系统架构设计
分布式文件系统架构设计目录1.前言 (3)2.HDFS1 (3)3.HDFS2 (5)4.HDFS3 (11)5.结语 (15)1.前言Hadoop是一个由Apache基金会所开发的分布式系统基础架构。
用户可以在不了解分布式底层细节的情况下，开发分布式程序。
充分利用集群的威力进行高速运算和存储。
Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS，解决了海量数据存储的问题；实现了一个分布式计算引擎MapReduce，解决了海量数据如何计算的问题；实现了一个分布式资源调度框架YARN，解决了资源调度，任务管理的问题。
而我们今天重点给大家介绍的是Hadoop里享誉世界的优秀的分布式文件系统-HDFS。
Hadoop重要的比较大的版本有:Hadoop1，Hadoop2，hadoop3。
同时也相对应的有HDFS1，HDFS2，HDFS3三个大版本。
后面的HDFS的版本，都是对前一个版本的架构进行了调整优化，而在这个调整优化的过程当中都是解决上一个版本的架构缺陷，然而这些低版本的架构缺陷也是我们在平时工作当中会经常遇到的问题，所以这篇文章一个重要的目的就是通过给大家介绍HDFS不同版本的架构演进，通过学习高版本是如何解决低版本的架构问题从而来提升我们的系统架构能力。
2.HDFS1最早出来投入商业使用的的Hadoop的版本，我们称为Hadoop1，里面的HDFS就是HDFS1，当时刚出来HDFS1，大家都很兴奋，因为它解决了一个海量数据如何存储的问题。
HDFS1用的是主从式架构，主节点只有一个叫：Namenode，从节点有多个叫：DataNode。
我们往HDFS上上传一个大文件，HDFS会自动把文件划分成为大小固定的数据块（HDFS1的时候，默认块的大小是64M，可以配置），然后这些数据块会分散到存储的不同的服务器上面，为了保证数据安全，HDFS1里默认每个数据块都有3个副本。
基于云计算的分布式文件系统架构设计
基于云计算的分布式文件系统架构设计近年来，随着互联网的不断发展和用户对数据存储和管理的需求越来越高，基于云计算的分布式文件系统的需求也越来越明显。
分布式文件系统可以实现高可用、可伸缩、可靠性强的数据管理和存储方案。
在众多分布式文件系统中，基于云计算的分布式文件系统因为具有自动扩容、高性能、高可靠等优点，已经成为企业存储方案的首选。
一、云计算基础云计算基础架构通常是由多个虚拟化机器构成的，每个机器都能够处理特定的工作。
每个虚拟化是由分布式计算机组成的，每个计算机又有多个处理器和内存，基本上可以灵活地按容量进行扩展。
二、分布式文件系统基础分布式文件系统是指将数据分布存储在多个物理设备上，实现对数据的快速访问和共享。
在分布式文件系统中，数据存储在多个节点上，如果一个节点出现故障，其他节点可以继续工作，从而实现高可用、可靠性强的数据管理和存储。
三、基于云计算的分布式文件系统架构设计1.可靠性和可扩展性基于云计算的分布式文件系统应该是可靠性和可扩展性的。
系统应该由多个服务器构成，从而能够无缝扩展，数据应该被多个节点复制，从而实现数据冗余和故障转移。
2.元数据管理元数据管理对分布式文件系统的可靠性至关重要。
元数据描述文件系统中所有文件和目录的信息，如文件名、文件大小、文件最后修改时间等。
元数据的管理应该采用多副本复制技术，每个节点都需要存储完整的元数据副本，以实现高可用、低延迟、容错和负载均衡等功能。
3.数据访问数据访问是分布式文件系统的核心。
数据在多个节点之间复制，应该基于高效的修改协议和广域网优化技术。
数据应该自动分割以便被分割到多个节点上。
文件分割策略应该基于访问频率、文件大小和文件类型，以确保高效和高负载均衡。
4.文件一致性保持文件的一致性是分布式文件系统关注的一个重点。
文件修改应该采用读-写锁，多个节点修改同一个文件应该保持同步。
同时，需要维护文件的修改历史，以便出现故障后快速还原数据。
5.容错技术分布式文件系统应该具有强大的容错技术。
分布式系统架构设计
分布式系统架构设计随着互联网的迅猛发展，分布式系统架构的设计成为了当今软件开发领域的热门话题。
分布式系统架构旨在解决单一系统无法满足高并发、高可用、高扩展性等需求的问题，将一个庞大的系统拆分成多个可独立运行的子系统，并通过各种通信协议来实现它们之间的协同工作。
在本文中，我们将讨论分布式系统架构设计的关键要素和常用模式，以及如何优化架构的性能和可靠性。
一、关键要素1. 异构性分布式系统架构设计中的第一个关键要素是异构性，即系统中的各个组件可以不同的编程语言、操作系统、硬件平台等。
通过允许异构性，我们可以利用不同技术栈的优势，实现更高效的系统。
2. 松耦合松耦合是指系统中的各个组件之间的依赖关系尽可能的降低。
通过松耦合，我们可以提高系统的可扩展性和灵活性，使得系统中的各个组件可以独立开发、测试和部署。
3. 容错性容错性是指系统在遇到故障时仍能保持正常运行的能力。
在分布式系统中，由于组件之间的通信可能存在不确定性和延迟，因此容错性尤为重要。
通过实现数据备份、故障恢复和负载均衡等机制，我们可以提高系统的容错性。
4. 数据一致性数据一致性是指在分布式系统中，各个组件之间的数据保持一致的特性。
由于网络延迟和并发访问等原因，数据一致性是一个复杂的问题。
设计者需要权衡一致性、可用性和分区容忍性等因素，选择适合的一致性模型。
二、常用模式1. 主从模式主从模式是分布式系统架构设计中最常见的模式之一。
它将系统分为一个主节点和多个从节点。
主节点负责协调和管理整个系统的状态，而从节点则负责处理请求和存储数据。
主从模式可以提高系统的可扩展性和可用性。
2. 分区模式分区模式是指将系统中的数据按照某种规则进行分片，每个分片独立存储在不同的节点上。
通过分区模式，我们可以提高系统的性能和并发能力，但也增加了数据一致性的难度。
设计者需要选择合适的分区策略，以保证数据的一致性和可用性。
3. 微服务模式微服务模式是一种将系统拆分成多个小型、独立运行的服务的架构设计模式。
分布式文件系统设计
分布式文件系统设计一、背景介绍分布式文件系统是一种用于存储和管理大规模数据的系统，通过将数据分散存储在多个物理设备上，实现高可靠性、高性能和可扩展性。
本文将介绍分布式文件系统的设计原理和关键技术。
二、分布式文件系统设计原理分布式文件系统设计的核心原理是将大文件分割成多个小块，并将这些块分别存储在不同的物理节点上。
通过合理的数据划分和节点协同工作，实现高效的数据访问和存储管理。
1. 数据划分将大文件切分成块的过程称为数据划分。
划分的原则可以是固定大小，也可以根据文件的特性进行动态划分。
划分后的数据块分别分配到不同的物理节点上，实现数据的并行处理。
2. 元数据管理元数据是指关于文件的描述信息，包括文件名、大小、权限、所在节点等。
元数据的管理是分布式文件系统设计的关键。
一种常用的方式是使用哈希表或数据库存储元数据，并通过复制、备份和冗余机制保证数据的可靠性。
3. 块存储与访问数据块的存储和访问是分布式文件系统设计中的重要环节。
每个节点负责存储一部分数据块，并可以根据需要对数据块进行读写操作。
块的存储使用多副本的方式，以提高数据的可用性和容错性。
4. 一致性与复制分布式文件系统中，多个节点共同维护数据一致性是一项重要的任务。
通过心跳机制和副本复制策略，实现数据的自动同步和错误恢复。
5. 安全性与权限控制为了保护数据安全，分布式文件系统需要实现合适的权限控制机制。
用户通过身份验证和访问控制策略，实现对数据的安全访问和管理。
三、关键技术分布式文件系统的设计需要借助一些关键技术来实现其功能。
下面介绍几种常见的技术。
1. 哈希算法哈希算法用于将数据块映射到特定的节点上，实现数据的均衡分布。
常用的哈希算法包括一致性哈希算法和CRC32哈希算法。
2. 容错机制容错机制是保证数据可靠性和高可用性的关键。
通过副本复制、错误检测和错误修复等机制，实现数据的冗余备份和自动恢复。
3. 负载均衡分布式文件系统中的节点通常会面临不同的负载情况，为了保证系统的性能和可扩展性，需要设计合适的负载均衡策略，将负载均衡地分配到各个节点上。
分布式文件系统的工作原理和架构(一)
分布式文件系统的工作原理和架构随着数据量的不断增长与云计算的兴起，分布式文件系统在现代计算中扮演着越来越重要的角色。
本文将介绍分布式文件系统的工作原理和架构，探讨其在大规模数据处理中的应用。
一、引言随着互联网的高速发展，人们对于数据的需求不断增加，这也带来了巨大的数据存储和处理挑战。
传统的文件系统面临着单点故障、性能瓶颈等问题，因此分布式文件系统应运而生。
二、分布式文件系统的基本原理分布式文件系统是将文件存储在多台服务器上，通过网络进行数据的存取和共享。
其基本原理包括以下几个方面：1. 数据切片：分布式文件系统将文件切分为小块，每个块的大小通常是固定的。
这样可以提高并行读写的效率，并确保数据在多台服务器上的均衡存储。
2. 元数据管理：分布式文件系统通过元数据管理对文件的存储位置、文件大小等信息的记录。
元数据通常存储在一个或多个主服务器上，以确保对文件的快速访问和管理。
3. 数据冗余：为了提高数据的可靠性和可用性，分布式文件系统通常会对数据进行冗余存储。
这意味着将文件的多个副本存储在不同的物理服务器上，当一个服务器发生故障时，其他服务器可以继续提供访问服务。
三、常见的分布式文件系统架构1. GFS（Google File System）：GFS是Google开发的一种分布式文件系统，旨在支持大规模分布式计算和存储需求。
其架构包括主服务器、从服务器和客户端三个组件。
主服务器负责管理元数据，从服务器负责存储实际的数据块，而客户端则通过GFS协议访问文件。
2. HDFS（Hadoop Distributed File System）：HDFS是Apache Hadoop项目中的一个核心组件，被广泛应用于大数据存储和处理。
它采用主从架构，其中NameNode负责管理元数据，DataNode负责存储实际的数据块。
HDFS还支持数据压缩、数据分片和数据冗余等功能。
3. Ceph：Ceph是一种开源的分布式文件系统，具有高可靠性和可扩展性。
分布式系统架构设计
分布式系统架构设计概述分布式系统架构设计是指在计算机系统中，将任务拆分并分配到不同的计算机节点上，实现资源共享、负载均衡、容错性和高性能等目标的设计过程。
本文将重点讨论分布式系统架构设计的关键问题和常用技术。
一、系统拆分与服务化在分布式系统架构设计中，系统拆分是关键的第一步。
将一个大型的单体系统拆分为多个互相独立的服务，可以提高系统的可扩展性和可维护性。
常见的拆分方式包括按业务功能拆分、按数据拆分和按服务类型拆分等。
1. 按业务功能拆分按业务功能拆分是将系统按照不同的业务功能进行拆分，每个功能模块都成为一个独立的服务。
这样可以提高系统的模块化程度，方便并行开发和维护。
2. 按数据拆分按数据拆分是将系统按照数据的关联性进行拆分，确保数据的一致性和可用性。
常见的拆分策略有按用户数据拆分、按地理位置拆分和按功能模块拆分等。
3. 按服务类型拆分按服务类型拆分是将系统按照不同的服务类型进行拆分，常见的服务类型有数据存储、业务逻辑处理和界面交互等。
这样可以实现不同类型的服务独立部署和水平扩展。
二、通信与数据同步在分布式系统中，各个服务之间需要进行通信和数据同步，以实现协同工作和数据一致性。
常用的通信方式包括同步通信和异步通信。
1. 同步通信同步通信是指发送方等待接收方的响应后才能继续执行。
常用的同步通信方式有RPC（远程过程调用）和RESTful（具象状态转移）等。
RPC可以实现方法调用的远程透明性，而RESTful则通过HTTP协议进行通信，具有更好的可扩展性。
2. 异步通信异步通信是指发送方发送消息后立即返回，不等待接收方的响应。
常用的异步通信方式有消息队列和发布-订阅模式等。
消息队列可以将消息进行排队和异步处理，提高系统的可伸缩性和可靠性。
三、负载均衡与容错性为了提高分布式系统的性能和可靠性，需要合理地分配负载并保证系统对故障的容错能力。
1. 负载均衡负载均衡是指将请求均匀地分发到多个计算机节点上，以提高系统的并发处理能力和吞吐量。
分布式文件系统设计简述
分布式文件系统设计简述分布式文件系统设计简述一、引言分布式文件系统是为了解决大规模数据存储和访问的问题而设计的一种系统。
它通过将数据分散存储在多个节点上，提供高可靠性、高性能和可扩展性。
本文将对分布式文件系统的设计进行简要介绍。
二、分布式文件系统的基本原理1. 数据划分与复制分布式文件系统将大文件划分为多个块，并在不同节点上进行复制。
这样可以提高数据的可靠性和访问速度。
2. 元数据管理元数据是指描述文件属性和位置等信息的数据。
分布式文件系统使用集中式或分布式的元数据管理方式，确保文件的一致性和可靠性。
3. 数据访问与传输分布式文件系统支持并发读写操作，并通过网络传输数据。
它通常采用副本选择策略来选择最近或最快的节点进行数据访问。
三、常见分布式文件系统设计方案1. Google 文件系统（GFS）GFS 是 Google 公司开发的一种分布式文件系统，它采用了大块存储、冗余复制和集中管理等技术。
GFS 能够处理 PB 级别的数据，并具有高可用性和容错能力。
2. Hadoop 分布式文件系统（HDFS）HDFS 是 Apache Hadoop 生态系统中的一种分布式文件系统，它采用了类似GFS 的设计思想。
HDFS 适用于大规模数据处理和分析，具有高吞吐量和容错性。
3. Ceph 文件系统Ceph 是一种分布式对象存储和文件系统，它具有高可靠性、可扩展性和自修复能力。
Ceph 文件系统支持多种访问接口，并提供了强大的数据保护机制。
四、分布式文件系统的设计考虑因素1. 可靠性与容错性分布式文件系统需要具备高可靠性和容错能力，能够自动检测和修复节点故障，并保证数据的完整性。
2. 性能与扩展性分布式文件系统需要具备高吞吐量和低延迟的特点，能够支持大规模数据访问和处理，并能够方便地扩展节点数量。
3. 数据一致性与并发控制分布式文件系统需要保证多个节点之间的数据一致性，并提供有效的并发控制机制，避免数据冲突和竞争条件。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
分布式文件系统架构设计1. 前言...................................................... 3.2. HDFS1 (3)3. HDFS2 (5)4. HDFS3 ............................................................................................. 1 15. 结语..................................................... 1.51. 刖言Hadoop 是一个由Apache基金会所开发的分布式系统基础架构。
用户可以在不了解分布式底层细节的情况下，开发分布式程序。
充分利用集群的威力进行高速运算和存储。
Hadoop 实现了一个分布式文件系统(Hadoop Distributed File System )，简称HDFS，解决了海量数据存储的问题；实现了一个分布式计算引擎MapReduce ，解决了海量数据如何计算的问题；实现了一个分布式资源调度框架YARN，解决了资源调度，任务管理的问题。
而我们今天重点给大家介绍的是Hadoop 里享誉世界的优秀的分布式文件系统-HDFS。
Hadoop 重要的比较大的版本有:Hadoop1 ,Hadoop2 , hadoop3 。
同时也相对应的有HDFS1 ，HDFS2，HDFS3三个大版本。
后面的HDFS的版本，都是对前一个版本的架构进行了调整优化，而在这个调整优化的过程当中都是解决上一个版本的架构缺陷，然而这些低版本的架构缺陷也是我们在平时工作当中会经常遇到的问题，所以这篇文章一个重要的目的就是通过给大家介绍HDFS不同版本的架构演进，通过学习高版本是如何解决低版本的架构问题从而来提升我们的系统架构能力。
2. HDFS1最早出来投入商业使用的的Hadoop 的版本，我们称为Hadoopl ，里面的HDFS就是HDFS1 ,当时刚出来HDFS1，大家都很兴奋，因为它解决了一个海量数据如何存储的问题。
HDFS1用的是主从式架构，主节点只有一个叫：Name node ，从节点有多个叫：DataNode 。
我们往HDFS上上传一个大文件，HDFS会自动把文件划分成为大小固定的数据块（HDFS1的时候，默认块的大小是64M，可以配置），然后这些数据块会分散到存储的不同的服务器上面，为了保证数据安全，HDFS1里默认每个数据块都有3个副本。
Name node 是HDFS的主节点，里面维护了文件系统的目录树，存储了文件系统的元数据信息，用户上传文件，下载文件等操作都必须跟NameNode 进行交互，因为它存储了元数据信息，Name node 为了能快速响应用户的操作，启动的时候就把元数据信息加载到了内存里面。
DataNode 是HDFS的从节点，干的活就很简单，就是存储block文件块。
01 / HDFS1 架构缺陷缺陷一：单点故障问题（高可用）我们很清楚的看到，HDFS1里面只有一个NameNode ，那么也就是说如果这个Name node 出问题以后，整个分布式文件系统就不能用了。
缺陷二：内存受限问题NameNode 为了能快速响应用户的操作，把文件系统的元数据信息加载到了内存里面，那么如果一个集群里面存储的文件较多，产生的元数据量也很大，大到name node 所在的服务器撑不下去了，那么文件系统的寿命也就到尽头了，所以从这个角度说，之前的HDFS1的架构里Name node 有内存受限的问题。
我们大体能看得出来，在HDFS1架构设计中，DataNode 是没有明显的问题的，主要的问题是在NameNode 这儿。
3. HDFS2HDFS1明显感觉架构不太成熟，所以HDFS2就是对HDFS1的问题进行解决。
01 /单点故障问题解决（高可用）大家先跟着我的思路走，现在我们要解决的是一个单点的问题，其实解决的思路很简单，因为之前是只有一个NameNode ，所以有单点故障问题，那我们把设计成两个Name node 就可以了，如果其中一个name node 有问题，就切换到另外一个NameNode 上。
NameNode所以现在我们想要实现的是：其中一个Name node 有问题，然后可以把服务切换到另外一个Name node 上。
如果是这样的话，首先需要解决一个问题：如何保证两个NameNode 之间的元数据保持一致？因为只有这样才能保证服务切换以后还能正常干活。
保证两个NameNode 之间元数据一致为了解决两个NameNode 之间元数据一致的问题，引入了第三方的一个JournalNode 集群。
IdumalnDde 集群JournO'INodo Journal NodoL -riri -!0$ 1 # ----------Ail JF MJour nalNode 集群的特点：JournalNode 守护进程是相对轻量级的，那么这些守护进程可与其它Hadoop 守护进程，如NameNode ，运行在相同的主机上。
由于元数据的改变必须写入大多数（一半以上）JNs，所以至少存在3个JournalNodes 守护进程，这样系统能够容忍单个Journal Node 故障。
当然也可以运行多于3个JournalNodes ，但为了增加系统能够容忍的故障主机的数量，应该运行奇数个JNs。
当运行N个JNs时，系统最多可以接受（N-1）/2 个主机故障并能继续正常运行，所以Jou nal Node 集群本身是没有单点故障问题的。
元数据，StandBy 状态的NameNode 实时从Journal Node 集群同步元数据，这样就保证了两个NameNode 之间的元数据是一致的。
两个NameNode 自动切换引入了Journal Node 集群以后，Active状态的NameNode 实时的往Journal Node 集群写工的参与把 Sta ndby N ameNode 切换成为 Active NameNode ，这个过程并不是自动化的,但是很明显这个过程我们需要自动化，接下来我们看 HDFS2是如何解决自动切换问题的。
为了解决自动切换问题，HDFS2弓I 入了 ZooKeeper 集群和ZKFC 进程。
ZKFC 是DFSZKFailoverController 的简称，这个服务跟 NameNode 的服务安装在同一台服务器上，主要的作用就是监控 NameNode健康状态并向 ZooKeeper 注册 NameNode ,如果Active 的NameNode挂掉后，ZKFC 为StandBy 的NameNode 竞争锁（分布式锁），获得ZKFC 锁的NameNode 变为active ，所以引入了 ZooKeeper 集群和 ZKFC 进程后就解决了 NameNode 自动切换的问题。
02 / 内存受限冋题解决目前虽然解决了单点故障的问题，但是目前假如Active NameNode 出了问题，还需要我们人• u 11 1 H 廿前面我们虽然解决了高可用的问题，但是如果NameNode 的元数据量很大，大到当前NameNode 所在的服务器存不下，这个时候集群就不可用了，换句话说就是NameNode 的扩展性有问题。
为了解决这个问题，HDFS2弓I入了联邦的机制。
Diffl带9阳顾lorn严nni燧架构之美如上图所示这个是一个完整的集群，由多个name node 构成，name nodel 和name node2构成一套name node ，我们取名叫nn 1 ,这两个name node 之间是高可用关系，管理的元数据是一模一样的；name node3 和name node4 构成一套name node ,假设我们取名叫nn2 ,这两个name node 之间也是高可用关系，管理的元数据也是一模一样的，但是nn1和nn2管理的元数据是不一样的，他们分别只是管理了整个集群元数据的一部分，引入了联邦机制以后，如果后面元数据又存不了，那继续扩nn 3, nn 4… 就可以了。
所以这个时候NameNode 就在存储元数据方面提升了可扩展性，解决了内存受限的问题。
联邦这个名字是国外翻译过来的，英文名是Federation ，之所以叫联邦的管理方式是因为Hadoop 的作者是Doug cutti ng ，在美国上学，美国是联邦制的国家，作者从国家管理的方式上联想到元数据的管理方式，其实这个跟我们国家的管理方式也有点类似，就好比我们整个国家是一个完整的集群，但是如果所有的元数据都由北京来管理的话，内存肯定不够，所以中国分了34个省级行政区域，各个区域管理自己的元数据，这行就解决了单服务器内存受限的问题。
HDFS2弓I入了联邦机制以后，我们用户的使用方式不发生改变，联邦机制对于用户是透明的，因为我们会在上游做一层映射，HDFS2的不同目录的元数据就自动映射到不同的name node 上。
03 / HDFS2的架构缺陷缺陷一：高可用只能有两个name node为了解决单点故障问题，HDFS2设计了两个name node, —个是active，另外一个是sta ndby ,但是这样的话，如果刚好两个NameNode 连续出问题了，这个时候集群照样还是不可用，所以从这这个角度讲，NameNode 的可扩展性还是有待提高的。
注意：这个时候不要跟联邦那儿混淆，联邦那儿是可以有无数个name node 的，咱们这儿说的只能支持两个name node 指的是是高可用方案。
缺陷二：副本为3，存储浪费了200%其实这个问题HDFS1的时候就存在，而且这个问题跟的设计没关系，主要是DataNode 这儿的问题，DataNode 为了保证数据安全，默认一个block都会有3个副本，这样存储就会浪费了200% 。
NameNode4. HDFS3其实到了HDFS2，HDFS就已经比较成熟稳定了，但是HDFS3还是精益求精，再从架构设计上重新设计了一下01 / 高可用之解决只能有两个name node当时在设计HDFS2的时候只是使用了两个NameNode 去解决高可用问题，那这样的话，集群里就只有一个NameNode 是Standby 状态，这个时候假设同时两个NameNode 都有问题的话，集群还是存在不可用的风险，所以在设计HDFS3的时候，使其可支持配置多个NameNode 用来支持高可用，这样的话就保证了集群的稳定性。
02 /解决存储浪费问题HDFS3之前的存储文件的方案是将一个文件切分成多个Block进行存储，通常一个Block 64MB 或者128MB，每个Block 有多个副本(replica)，每个副本作为一个整体存储在一个DataNode 上，这种方法在增加可用性的同时也增加了存储成本。