目录
一、集中存储结构
二、分布式存储
1 、分布式存储的兴起
2 、分布式存储的重要性
3 、分布式存储的种类和比较
三、分布式理论浅析
1 、一致性和可用性
2 、数据分布
3 、复制
4 、分布式协议
5、跨机房部署
四、分布式文件系统
1、 Google 文件系统（ GFS ）
2、 Taobao 文件系统（ TFS ）
3、 Fackbook Haystack 文件系统
4、 CDN 内容分发网络
五、分布式键值系统
1、 Amazon Dynamo
2、 Taobao Tiar
3、 ETCD
4 、产品选型比较（ Etcd ， Zookeeper ， Consul ）
一、集中存储结构
说到分布式存储，我们先来看一下传统的存储是怎么个样子。
传统的存储也称为集中式存储， 从概念上可以看出来是具有集中性的，也就是整个存储是集中在一个系统中的，但集中式存储并不是一个单独的设备，是集中在一套系统当中的多个设备，比如下图中的 EMC 存储就需要几个机柜来存放。
在这个存储系统中包含很多组件，除了核心的机头（控制器）、磁盘阵列（ JBOD ）和交换机等设备外，还有管理设备等辅助设备。
结构中包含一个机头，这个是存储系统中最为核心的部件。通常在机头中有包含两个控制器，互为备用， 避免硬件故障导致整个存储系统的不可用。机头中通常包含前端端口和后端端口，前端端口用户为服务器提供存储服务，而后端端口用于扩充存储系统的容量。通过后端端口机头可以连接更多的存储设备，从而形成一个非常大的存储资源池。
在整个结构中，机头中是整个存储系统的核心部件，整个存储系统的高级功能都在其中实现。控制器中的软件实现对磁盘的管理，将磁盘抽象化为存储资源池，然后划分为 LUN 提供给服务器使用。这里的 LUN 其实就是在服务器上看到的磁盘 。当然，一些集中式存储本身也是文件服务器，可以提供共享文件服务。无论如何，从上面我们可以看出集中式存储 最大的特点是有一个统一的入口，所有数据都要经过这个入口 ，这个入口就是存储系统的机头。这也就是集中式存储区别于分布式存储最显著的特点。如下图所示：
二、分布式存储
分布式存储最早是由谷歌提出的，其目的是通过廉价的服务器来提供使用与大规模，高并发场景下的 Web 访问问题。它 采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。
1 、分布式存储的兴起
分布式存储的兴起与互联网的发展密不可分，互联网公司由于其数据量大而资本积累少，而通常都使用大规模分布式存储系统。
与传统的高端服务器、高端存储器和高端处理器不同的是，互联网公司的分布式存储系统由数量众多的、低成本和高性价比的普通 PC 服务器通过网络连接而成。其主要原因有以下三点
（1） 互联网的业务发展很快，而且注意成本消耗，这就使得存储系统不能依靠传统的纵向扩展的方式，即先买小型机，不够时再买中型机，甚至大型机。互联网后端的分布式系统要求支持横向扩展，即通过增加普通 PC 服务器来提高系统的整体处理能力。
（2） 普通 PC 服务器性价比高，故障率也高，需要在软件层面实现自动容错，保证数据的一致性。
（3） 另外，随着服务器的不断加入，需要能够在软件层面实现自动负载均衡，使得系统的处理能力得到线性扩展。
2 、分布式存储的重要性
从单机单用户到单机多用户，再到现在的网络时代，应用系统发生了很多的变化。而分布式系统依然是目前很热门的讨论话题，那么，分布式系统给我们带来了什么，或者说是为什么要有分布式系统呢？
（1）升级单机处理能力的性价比越来越低；
企业发现通过更换硬件做垂直扩展的方式来提升性能会越来越不划算；
（2）单机处理能力存在瓶颈；
某个固定时间点，单颗处理器有自己的性能瓶颈，也就说即使愿意花更多的钱去买计算能力也买不到了；
（3）出于稳定性和可用性的考虑
如果采用单击系统，那么在这台机器正常的时候一切 OK ，一旦出问题，那么系统就完全不能用了。当然，可以考虑做容灾备份等方案，而这些方案就会让系统演变为分布式系统了；
（4）云存储和大数据发展的必然要求
云存储和大数据是构建在分布式存储之上的应用。移动终端的计算能力和存储空间有限，而且有在多个设备之间共享资源的强烈的需求，这就使得网盘、相册等云存储应用很快流行起来。然而，万变不离其宗，云存储的核心还是后端的大规模分布式存储系统。大数据则更近一步，不仅需要存储海量数据，还需要通过合适的计算框架或者工具对这些数据进行分析，抽取其中有价值的部分。如果没有分布式存储，便谈不上对大数据进行分析。仔细分析还会发现，分布式存储技术是互联网后端架构的神器，掌握了这项技能，以后理解其他技术的本质会变得非常容易。
3 、分布式存储的种类和比较
分布式存储包含的种类繁多，除了传统意义上的分布式文件系统、分布式块存储和分布式对象存储外，还包括分布式数据库和分布式缓存等，但其中架构无外乎于三种
A、 中间控制节点架构
以 HDFS （ Hadoop Distribution File System ）为代表的架构是典型的代表。在这种架构中，一部分节点 NameNode 是存放管理数据（元数据），另一部分节点 DataNode 存放业务数据，这种类型的服务器负责管理具体数据。这种架构就像公司的层次组织架构， namenode 就如同老板，只管理下属的经理（ datanode ），而下属的经理，而经理们来管理节点下本地盘上的数据。
在上图中， 如果客户端需要从某个文件读取数据，首先从 NameNode 获取该文件的位置（具体在哪个 DataNode ），然后从该 NameNode 获取具体的数据。在该架构中 NameNode 通常是主备部署（ Secondary NameNode ），而 DataNode 则是由大量节点构成一个集群。由于元数据的访问频度和访问量相对数据都要小很多，因此 NameNode 通常不会成为性能瓶颈，而 DataNode 集群中的数据可以有副本，既可以保证高可用性，可以分散客户端的请求。因此，通过这种分布式存储架构可以通过横向扩展 datanode 的数量来增加承载能力，也即实现了动态横向扩展的能力。
B、 完全无中心架构 – 计算模式
以 Ceph 为代表的架构是其典型的代表。在该架构中与 HDFS 不同的地方在于该架构中没有中心节点。客户端是通过一个设备映射关系 计算出来 其写入数据的位置，这样客户端可以直接与存储节点通信，从而避免中心节点的性能瓶颈。
如上图所示， 在 Ceph 存储系统架构中核心组件有 MON 服务、 OSD 服务和 MDS 服务等。
(1) MON 服务用于维护存储系统的硬件逻辑关系，主要是服务器和硬盘等在线信息。MON 服务通过集群的方式保证其服务的可用性。
(2) OSD 服务用于实现对磁盘的管理，实现真正的数据读写，通常一个磁盘对应一个 OSD 服务。
(3) MDS 只为 CephFS 文件存储系统跟踪文件的层次机构和存储元数据。Ceph 块设备和 RADOS 并不需要元数据，因此也不需要 Ceph MDS 守护进程
(4) RADOS ：RADOS 就是包含上述三种服务的 ceph 存储集群。在 Ceph 中所有的数据都以对象形式存在的，并且无论哪种数据类型 RADOS 对象存储都将负责保存这些对象。RADOS 层可以确保数据始终保持一致性。要做到这一点必须执行数据复制、故障检测和恢复，以及数据迁移和所在集群节点实现在平衡
(5) RBD （块设备）：原名 RADOS 块设备，提供可靠的分布式和高性能块存储磁盘给客户端。
(6) CephFS ：Ceph 文件系统提供了一个使用 Ceph 存储集群存储用户数据的与 POSIX 兼容的文件系统
(7) Librados ：libRADOS 库为 PHP 、 RUBY 、 Java 、 Python 、 C++ 等语言提供 了方便的访问 RADOS 接口的方式
(8) RADOS GW ：RGW 提供对象存储服务，它允许应用程序和 Ceph 对象存储建立连接， RGW 提供了与 Amazon S3 和 openstack Swift 兼容的 RUSTFUL API
客户端访问存储的大致流程是，客户端在启动后会首先通过 RADOS GW 进入，从 MON 服务拉取存储资源布局信息，然后根据该布局信息和写入数据的名称等信息计算出期望数据的位置（包含具体的物理服务器信息和磁盘信息），然后和该位置信息对应的 CephFS 对应的位置直接通信，读取或者写入数据
C、 完全无中心架构 – 一致性哈希
以 swift 为代表的架构是其典型的代表。与 Ceph 的通过计算方式获得数据位置的方式不同，另外一种方式是通过一致性哈希的方式获得数据位置。一致性哈希的方式就是将设备做成一个哈希环，然后根据数据名称计算出的哈希值映射到哈希环的某个位置，从而实现数据的定位。
Swift 中存在两种映射关系，对于一个文件，通过哈希算法（ MD5 ）找到对应的虚节点（一对一的映射关系），虚节点再通过映射关系（ ring 文件中二维数组）找到对应的设备（多对多的映射关系），这样就完成了一个文件存储在设备上的映射。
D 、分布式存储的比较
那么现在问题来了，如果我们要选择分布式存储，选择哪种好呢？其实它们各有各的优势和使用场景，具体要看需求。
（1）HDFS
主要用于大数据的存储场景，是 Hadoop 大数据架构中的存储组件。HDFS 在开始设计的时候，就已经明确的它的应用场景，就是大数据服务。主要的应用场景有：
a 、对大文件存储的性能比较高，例如几百兆，几个 G 的大文件。因为 HDFS 采用的是以元数据的方式进行文件管理，而元数据的相关目录和块等信息保存在 NameNode 的内存中， 文件数量的增加会占用大量的 NameNode 内存。如果存在大量的小文件，会占用大量内存空间，引起整个分布式存储性能下降，所以尽量使用 HDFS 存储大文件比较合适。
b 、适合低写入，多次读取的业务。就大数据分析业务而言，其处理模式就是一次写入、多次读取，然后进行数据分析工作， HDFS 的数据传输吞吐量比较高，但是数据读取延时比较差，不适合频繁的数据写入。
c 、 HDFS 采用多副本数据保护机制，使用普通的 X86 服务器就可以保障数据的可靠性，不推荐在虚拟化环境中使用。
（ 2 ） Ceph
目前应用最广泛的开源分布式存储系统，已得到众多厂商的支持，许多超融合系统的分布式存储都是基于 Ceph 深度定制。而且 Ceph 已经成为 LINUX 系统和 OpenStack 的 “ 标配 ” ，用于支持各自的存储系统。Ceph 可以提供对象存储、块设备存储和文件系统存储服务。同时支持三种不同类型的存储服务的特性，在分布式存储系统中，是很少见的。
a、 Ceph 没有采用 HDFS 的元数据寻址的方案，而且采用 CRUSH 算法，数据分布均衡，并行度高。而且在支持块存储特性上，数据可以具有强一致性，可以获得传统集中式存储的使用体验。
b、 对象存储服务， Ceph 支持 Swift 和 S3 的 API 接口。在块存储方面，支持精简配置、快照、克隆。在文件系统存储服务方面，支持 Posix 接口，支持快照。但是目前 Ceph 支持文件的性能相当其他分布式存储系统，部署稍显复杂，性能也稍弱，一般都将 Ceph 应用于块和对象存储。
c、 Ceph 是去中心化的分布式解决方案，需要提前做好规划设计，对技术团队的要求能力比较高。特别是在 Ceph 扩容时，由于其数据分布均衡的特性，会导致整个存储系统性能的下降
（ 3 ）Swift
主要面向的是对象存储。和 Ceph 提供的对象存储服务类似。主要用于解决非结构化数据存储问题。它和 Ceph 的对象存储服务的主要区别是。
a 、客户端在访问对象存储系统服务时， Swift 要求客户端必须访问 Swift 网关才能获得数据。而 Ceph 使用一个运行在每个存储节点上的 OSD （对象存储设备）获取数据信息，没有一个单独的入口点，比 Swift 更灵活一些。
b 、数据一致性方面， Swift 的数据是最终一致，在海量数据的处理效率上要高一些，但是主要面向对数据一致性要求不高，但是对数据处理效率要求比较高的对象存储业务。而 Ceph 是始终跨集群强一致性。主要的应用场景，在 OpenStack 中，对象存储服务使用的就是 Swift ，而不是 Ceph 。
三、分布式理论浅析
1 、一致性和可用性
由于异常的存在，分布式存储系统设计时往往会将数据冗余存储多份，每一份称为一个副本）。这样，当某一个节点出现故障时，可以从其他副本上读到数据。可以这么认为，副本是分布式存储系统容错技术的唯一手段。由于多个副本的存在，如何保证副本之间的一致性是整个分布式系统的理论核心。
数据一致性这个单词在平常开发中，或者各种文章中都能经常看见，我们常常听见什么东西数据不一致了，造成了一定的损失，赶快修复一下。那有几种一致性呢？
a、 时间一致性：要求所有数据组件的数据在任意时刻都是完全一致的；
b、 事物一致性：事务一致性只能存在在事务开始前的和事务完成之后，在事务过程中数据有可能不一致，比如 A 转 100 元给 B ， A 扣减 100 ， B 加上 100 ，在事务开始前和事务完成之后都能保证他们的帐是对上的，那么这就是事务一致性。但是在事务过程中有可能会出现 A 扣减了 100 元， B 没有加上 100 元的情况，这就是不一致
c、 在应用程序中涉及多个不同的单机事务，只有在所有的单机事务完成之前和完成之后，数据是完全一致的。
仅仅靠这三种一致性在实际的一些复杂场合是很难描述清楚的，所以，我们引出了一致性模型，这里我们由强到弱简单的介绍几种常见的一致性模型。文章来源：https://www.toymoban.com/news/detail-405581.html
A 、线性一致性
又称强一致性， 可以看做只有一个单核处理器，或者可以看做只有一个数据副本，并且所有操作都是原子的。文章来源地址https://www.toymoban.com/news/detail-405581.html
到了这里，关于一文看懂分布式存储架构的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
