数据分布式存储方案 第1篇
聚类包括下列典型类型：
1、基于层次的算法
2、基于划分的算法
3、基于密度的算法
4、基于网格的算法(grid)
5、基于模型的算法(model)
词语距离计算
1、统计
2、把本体或者分类关系组织成树状结构来进行量化计算
基于知识体系
基于语料库
在网络基础上计算相似度
哈希方法及其改进的一些算法主要集中在数据集在分配时要考虑小同存储服务器的负载升使得服务器群的容错性高，而聚类划分和基于知网语义相似度的方法是采用人工智能的非监督或者监督方法来对数据集合划分，它们的主要的侧重点是相同或者类似的节点划分在一起，从而在查询中更容易在一台机器查找相关信息，但是如果给定的数据集合聚合程度很高，使得相当多的数据集中在极少数的机器上，必然会导致机器的负载承受的问题，当某些服务器聚集了更多关系紧密的节点及关系数据，当超过负载，在集群服务器多线程并发查找消息时必然会影响数据查询的效率。
本文提出基于词汇语义相似度及节点密度的分割方法，在分割的时候综合考虑了关系标签语义的相似度以及节点和关系的密度，使得关系密切的点和关系尽量集中分布到一台服务器上。
对于N台存储服务器，首先随机选取度数最大并且不存在直接关系的N个节点（例如，不存在直接关系的节点，即不允许直接关系(Vi,Vj)的存在,允许间接联系(Vi,Vk),(Vk,Vj) 存在），对于剩下的全部节点，计算待分配的节点和全部的服务器中的节点组成的图中的总度数和，并且计算待分配节点和服务器中节点组成新的关系的标签的语义相似度的平均值（例如待分布节点Vi和服务器Ni中的节点Vj、Vk、Vm组成关系，求得关系(Vi,Vj)、(Vi,Vk)、(Vi,Vm)标签的相似度并取平均值，即
其中分子为待计算的节点同服务器中当前存在的节点形成的关系的标签的语义相似度之和，分母为待计算的节点同服务器中的节点形成关系数量）作为权重求和的一部分；接着计算待分配节点和服务器中的全部节点形成的图的总度数之和并除以全部节点数量的均值，
其中分子为待计算的节点同服务器中的节点形成关系数量之和加上Ni服务器中已存在的关系数量，分母为Ni服务器中的节点数量并加上待加入的节点数量1，并选取这些均值作为权重求和的一部分，最后把相似度的平均值与度数的平均值相加，然后按照总和最大的顺序递减排列候选服务器作为待分布的候选服务器的选择顺序，即
在确定候选服务器的排序后（优先选择的顺序，第一个为最优选择，最后一个为最差选择），接下来考虑负载均衡的问题。
对于负载均衡，采用一致性哈希方法的改进算法即带负载上限的方法来解决此问题。就是为每台服务器加入了一个能够承担的最大负载上限，其中最大负载上限为平均负载的(1+e)倍，此处的自定义e值自定为，（例如存储服务的平均负载为100，当此服务器的负载为100 ∗ (1 + )时，如果当前待加入的节点及关系在加入服务器Ni后会导致此服务器的负载容量与平均负载相差20%时，就要排除当前候选服务器，然后按排好的顺序顺位选择下一个候选服务器，以此类推）。
数据分布式存储方案 第2篇
Dynamo 以很简单的键值方式存储数据，不支持复杂的查询。Dynamo 中存储的是数据值的原始形式，不解析数据的具体内容。Dynamo 主要用于 Amazon 的购物车及 S3 云存储服务。在实现过程中解决了如下问题：
采用的技术
数据分布
改进的哈希算法
复制协议
复制写协议（NRW参数可调）
数据冲突的解决
向量时钟
临时故障处理
数据回传机制
永久故障处理
Merkle哈希树
成员资格及错误检测
基于Gossip的成员资格和错误检测协议
Dynamo 采用一致性哈希将数据分布到多个存储节点中，概括来说：给系统中的每个节点分配一个随机 token ，这些 token 构成一个哈希环。执行数据存放操作时，先计算主键的哈希值，然后存放到顺时针方向的第一个大于或者等于该哈希值的 token 所在的节点。一致性哈希的有点在于节点加入 / 删除只会影响到在哈希环相邻的节点，而对其他节点没影响。
A 、 Dynamo 架构
考虑到节点的异构性，不同节点的处理能力差别很大， Dynamo 使用了改进的一致性哈希算法：每个物理节点根据其性能的差异分配多个 token ，每个 token 对应一个虚拟节点，每个虚拟节点的处理能力基本相当，并随机分布在哈希空间中。存储时，数据按照哈希值落到某个虚拟节点负责的区域，然后被存储到该虚拟节点所对应的物理节点。
如下图，某 Dynamo 集群中原有 3 个节点，每个节点分配 3 个 token 。存放数据时，首先计算主键的哈希值，并根据哈希值将数据存放到对应 token 所在的节点。假设增加节点 4 ，节点 token 分配情况发生变化，这就实现了自动负载均衡。
为了找到数据所属的节点，要求每个节点维护一定的集群信息用于定位。Dynamo 系统中每个节点维护整个集群的信息，客户端也缓存整个集群的信息，因此，绝大部分请求能够一次定位到目标节点。
由于机器或者人为的因素，系统中的节点成员加入或者删除经常发生，为了保证每个节点缓存的都是 Dynamo 集群中最新的成员信息，所有节点每隔固定时间（比如 1s ）通过 Gossip 协议的方式从其他节点中任意选择一个与之通信的节点。如果连接成功，双方交换各自保存的集群信息。
Gossip 协议用于 P2P 系统中自治的节点协调对整个集群的认识，比如集群的节点状态、负载情况。我们先看看两个节点 A 和 B 是如何交换对世界的认识的。
（ 1 ） A 告诉 B 其管理的所有节点的版本（包括 Down 状态和 Up 状态的节点）；
（ 2 ） B 告诉 A 哪些版本它比较旧了，哪些版本它有最新的，然后把最新的那些节点发给 A （处于 Down 状态的节点由于版本没有发生更新所以不会被关注）；
（ 3 ） A 将 B 中比较旧的节点发送给 B ，同时将 B 发送来的最新节点信息做本地更新；
（ 4 ） B 收到 A 发来的最新节点信息后，对本地缓存的比较旧的节点做更新。
由于种子节点的存在，新节点加入可以做得比较简单。新节点加入时首先与种子节点交换集群信息，从而对集群有了认识。DHT （ Distributed Hash Table ，也称为一致性哈希表）环中原有的其他节点也会定期和种子节点交换集群信息，从而发现新节点的加入。
集群不断变化，可能随时有机器下线，因此，每个节点还需要定期通过 Gossip 协议同其他节点交换集群信息。如果发现某个节点很长时间状态都没有更新，比如距离上次更新的时间间隔超过一定的阈值，则认为该节点已经下线了。
数据分布式存储方案 第3篇
到 2014 年， Facebook 大概有超 4000 亿张图片，总大小为 30PB ，通过计算可以得出每张照片的平均大小为 30PB/260GB ，约为 100KB 。用户每周新增照片数为 10 亿（总大小为 60TB ），平均每秒新增的照片数为 109/7/40000 （按每天 40000s 计），约为每秒 3800 次写操作，读操作峰值可以达到每秒百万次。
Facebook 相册后端早期采用基于 NAS 的存储，通过 NFS 挂载 NAS 中的照片文件来提供服务。后来出于性能和成本考虑，自主研发了 Facebook Haystack 存储相册数据。
和 TFS 类似， Facebook Haystack 新架构主要解决图片存取 IO 次数过多的文件，主要的思路是多个逻辑文件共享同一个物理文件。Haystack 架构及读请求处理流程图如下
Haystack 架构主要有三个部分：Haystack Directory ， Haystack Store 以及 Haystack Cache 。Haystack Store 是物理存储节点，以物理卷轴 (physical volume) 的形式组织存储空间，每个物理卷轴一般很大，比如 100GB ，这样 10TB 的数据也只有 100 个物理卷轴。每个物理卷轴对应一个物理文件，因此，每个存储节点上的物理文件元信息都很小。多个物理存储节点上的物理卷轴组成一个逻辑卷轴 (logical volume) ，用于备份。Haystack Directory 存放逻辑卷轴和物理卷轴的对应关系，假设每个卷轴的大小为 100GB ，对应关系的条数为 20PB / 100GB = ，占用的内存可以忽略。Haystack cache 主要用于解决对 CDN 提供商过于依赖的问题，提供最近增加的图片的缓存服务。
Haystack 图片读取请求大致流程为：用户访问一个页面时， Web Server 请求 Haystack Directory 构造一个 URL ：http:// ＜ CDN ＞ / ＜ Cache ＞ / ＜ Machine id ＞ / ＜ Logical volume,Photo ＞ ，后续根据各个部分的信息依次访问 CDN ， Cache 和后端的 Haystack Store 存储节点。Haystack Directory 构造 URL 时可以省略 部分从而使得用户直接请求 Haystack Cache 而不必经过 CDN 。Haystack cache 收到的请求包含两个部分：用户 Browser 的请求及 CDN 的请求， Haystack cache 只缓存用户 Browser 发送的请求且要求请求的 Haystack Store 存储节点是可写的。一般来说， Haystack Store 的存储节点写一段时间以后达到容量上限变为只读，因此，可写节点的图片为最近增加的图片，是热点数据。
Haystack 的写请求 ( 图片上传 ) 处理流程为：Web Server 首先请求 Haystack Directory 获取图片的 id 和可写的逻辑卷轴，接着将数据写入对应的每一个物理卷轴 ( 备份数一般为 3) 。
Facebook Haystack 及 Taobao TFS 这样的文件系统一般称为 Blob 文件系统。它们都是解决大量的小图片文件的问题，因此架构很类似，不同点包括
（1） 逻辑卷轴大小的选择，比如 Haystack 选择 100GB 的逻辑卷轴大小， TFS 中 block 大小一般为 64MB ；
（2） Haystack 使用 RAID 6 ，且底层文件系统使用性能更好的 XFS ，淘宝后期摈除了 RAID 机制，文件系统使用 Ext3 ；
（3） Haystack 使用了 Akamai & Limelight 的 CDN 服务，而 Taobao 已经使用自建的 CDN ，当然， Facebook 也在考虑自建 CDN 。
数据分布式存储方案 第4篇
Tair 是一个分布式的 key/value 系统。
Tair 有四种引擎：mdb, rdb, kdb 和 ldb 。分别基于四种开源的 key/value 数据库：memcached, Redis, Kyoto Cabinet 和 leveldb 。Tair 可以让你更方便地使用这些 KV 数据库。比如 Redis 没有提供 sharding 操作，如果有多个 Redis Server ，你需要自己写代码实现 sharding ， Tair 帮你封装了这些。
Tair 有以下优点：
（ 1 ）统一的 API 。无论底层使用何种引擎，上层的 API 是一样的。
（ 2 ） Tair 将集群操作封装起来，解放了开发者。淘宝内部在使用 Tair 时，一般都是双机房双集群容错，利用 invalid server 保证两个集群间的一致性，这些对于开发者都是透明的。
（ 1 ）非持久化 (mdb,rdb)
· 数据可以以 key/value 的形式存储
· 数据可以接受丢失
· 访问速度要求很高
· 单个数据大小不是很大，一般在 KB 级别
· 数据量很大，并且有较大的增长可能性
· 数据更新不频繁
（ 2 ）持久化 (kdb,ldb)
· 数据可以以 key/value 的形式存储
· 数据需要持久化
· 单个数据大小不是很大，一般在 KB 级别
· 数据量很大，并且有较大的增长可能性
· 数据的读写比例较高
Tair 作为一个分布式系统，是由一个中心控制节点和若干个服务节点组成，
a 、 config server 功能：
（ 1 ）通过维护和 data server 心跳来获知集群中存活节点的信息；
（ 2 ）根据存活节点的信息来构建数据在集群中的分布表；
（ 3 ）根据数据分布表的查询服务；
（ 4 ）调度 data server 之间的数据迁移、复制；
b 、 data server 功能
（ 1 ）提供存储引擎；
（ 2 ）接受 client 的 put/get/remove 等操作；
（ 3 ）执行数据迁移，复制等；
（ 4 ）插件：在接受请求的时候处理一些自定义功能；
（ 5 ）访问统计；
c 、 client 功能
（ 1 ）在应用端提供访问 tair 集群的接口；
（ 2 ）更新并缓存数据分布表和 invalid server 地址等；
（ 3 ） local cache ，避免过热数据访问影响 tair 集群服务；
（ 4 ）流控；
在下图中，。客户端首先请求 Config Server 获取数据所在的 Data Server ，接着往 Data Server 发送读写请求。Tair 允许将数据存放到多台 Data Server ，以实现异常容错。
Tair 的分布采用的是一致性哈希算法，对于所有的 key ，分到 Q 个桶中，桶是负载均衡和数据迁移的基本单位， config server 根据一定的策略把每个桶指派到不同的 data server 上，因为数据按照 key 做 hash 算法，保证了桶分布的均衡性，从而保证了数据分布的均衡性。
当某台 Data Server 故障不可用时， Config Server 能够检测到。每个哈希桶在 Tair 中存储多个副本，如果是备副本，那么 Config Server 会重新为其指定一台 Data Server ，如果是持久化存储，还将复制数据到新的 Data Server 上。如果是主副本，那么 ConfigServer 首先将某个正常的备副本提升为主副本，对外提供服务。接着，再选择另外一台 Data Server 增加一个备副本，确保数据的备份数。
增加或减少 data server 的时候， config server 会发现这个情况， config server 负责重新计算一张新的桶在 data server 上的分布表，将原来由减少的机器服务的桶的访问重新指派到其他的 data server 中，这个时候就会发生数据的迁移。比如原来由 data server A 负责的桶，在新表中需要由 B 负责，而 B 上并没有该桶的数据，那么就将数据迁移到 B 上来，同时 config server 会发现哪些桶的备份数目减少了，然后根据负载均衡情况在负载较低的 data server 上增加这些桶的备份。当系统增加 data server 的时候， config server 根据负载，协调 data server 将他们控制的部分桶迁移到新的 data server 上，迁移完成后调整路由；
数据迁移时 data server 对外提供服务的策略，假设 data server A 要把桶 1,2,3 迁移到 data server B ，因为迁移完成前，客户端的路由表没有变化，客户端对 1,2,3 的访问请求都会路由到 A ，现在假设 1 还没迁移， 2 正在迁移， 3 已经迁移完成，那么如果访问 1 ，则还是访问 data server A ，如果访问 3 ，则 A 会把请求转发给 B ，并且将 B 的返回结果返回给客户，如果访问 2 ，则在 A 上处理，同时如果是对 2 的修改操作，会记录修改 log ，当桶 2 完成迁移的时候，还有把 log 发送给 B ，在 B 上应用这些 log ，最终 AB 数据一致才是真正完成迁移。如果 A 是由于宕机而引发的迁移，客户端会收到一张中间临时状态的分配表，把宕机的 data server 负责的桶临时指派给有其备份的 data server 来处理，此时服务是可用的，负载可能不均衡，当迁移完成后，又能达到一个新的负载均衡状态。
数据分布式存储方案 第5篇
本章节主要讨论了数据集合在分布式数据库中是如何划分的问题，分别对哈希方法及其相关的一些改进方法包括一致性哈希算法、考虑了负载上限的一致性哈希算法、加入了虚拟节点的一致性哈希算法）、聚类划分、基于知网词汇语义划分三类方法进行了介绍，，然后根据上面讨论的方法的相应优缺点，提出了本文采用的数据分割方法，即基于词汇语义相似度及节点密度的分割方法，此方法在考虑了节点关系密度的同时考虑了关系标签的语义相似度，使得关系更为紧密的图分布到同一台服务器，最后在此基础上加入了负载均衡的考虑，在本文中自定义负载上限值为1+e，其中e自定义为。在均衡分割完数据集合后，对于跨不同服务器的节点和关系采用了复制冗余的方法，并对这些节点关系进行了标记。以上这些方法将会对下面的子图查询产生影响。
数据分布式存储方案 第6篇
分布式键值系统是用于存储关系简单的半结构化数据，半结构化数据均封装成由 键值对组成的对象，其中 key 为唯一标示符；value 为属性值，可以为任何类型，如文字、图片，也可以为空；timestamp 为时间戳，提供对象的多版本支持。分布式键值系统以键值对存储，它的结构不固定，每一元组可以有不一样的字段，可根据需要增加键值对，从而不局限于固定的结构，适用面更大，可扩展性更好。
分布式键值系统支持针对单个 键值对的增、删、查、改操作，可以运行在 PC 服务器集群上，并实现集群按需扩展，从而处理大规模数据，并通过数据备份保障容错性，避免了分割数据带来的复杂性和成本。
总体来说，分布式键值系统从存储数据结构的角度看，分布式键值系统与传统的哈希表比较类似，不同的是，分布式键值系统支持将数据分布到集群中的多个存储节点。分布式键值系统可以配置数据的备份数目，可以将一份数据的所有副本存储到不同的节点上，当有节点发生异常无法正常提供服务时，其余的节点会继续提供服务。
数据分布式存储方案 第7篇
由于异常的存在，分布式存储系统设计时往往会将数据冗余存储多份，每一份称为一个副本）。这样，当某一个节点出现故障时，可以从其他副本上读到数据。可以这么认为，副本是分布式存储系统容错技术的唯一手段。由于多个副本的存在，如何保证副本之间的一致性是整个分布式系统的理论核心。
数据一致性这个单词在平常开发中，或者各种文章中都能经常看见，我们常常听见什么东西数据不一致了，造成了一定的损失，赶快修复一下。那有几种一致性呢？
a、 时间一致性：要求所有数据组件的数据在任意时刻都是完全一致的；
b、 事物一致性：事务一致性只能存在在事务开始前的和事务完成之后，在事务过程中数据有可能不一致，比如 A 转 100 元给 B ， A 扣减 100 ， B 加上 100 ，在事务开始前和事务完成之后都能保证他们的帐是对上的，那么这就是事务一致性。但是在事务过程中有可能会出现 A 扣减了 100 元， B 没有加上 100 元的情况，这就是不一致
c、 在应用程序中涉及多个不同的单机事务，只有在所有的单机事务完成之前和完成之后，数据是完全一致的。
仅仅靠这三种一致性在实际的一些复杂场合是很难描述清楚的，所以，我们引出了一致性模型，这里我们由强到弱简单的介绍几种常见的一致性模型。
又称强一致性，可以看做只有一个单核处理器，或者可以看做只有一个数据副本，并且所有操作都是原子的。
如上图所示，对于事件 e1 和 e2 来说，如果事件 e1 的 response 是在事件 e2 的 invoke 之前，我们就说 e1 happen before e2 。
对于同一个线程来说，前面的事件一定 happen before 后面的事件。但是对于不同线程上的两个事件来说，它们之间只有在在时间线上没有交叉的情况下，才会存在 happen before 关系。对于有交叉的那些事件，比如下图中的 event2 和 event3 ，它们两个就不存在 happen before 关系，对于我们要寻找的合法顺序执行过程来说，它们两个的顺序可以是任意的。
顺序一致性弱于严格一致性。对变量的写操作不一定要在瞬间看到，但是，不同处理器对变量的写操作必须在所有处理器上以相同的顺序看到，这里处理器再分布式系统中可以换成不同的节点。
假设有两个线程 A 和 B 并发执行。其中 A 线程由 3 个操作构成，它们在程序中的顺序是：A1->A2->A3. B 线程也有 3 个操作，它们在程序中的顺序是：B1->B2->B3. 假设如果在顺序一致的模型中的效果就是如上两个图所示。
因果一致性是弱于顺序一致性的一致性模型，顺序一致性要求所有的操作的顺序都必须按照某个单个处理器(节点)的顺序，而因果一致性只需要满足有因果关系的操作是顺序一致性即可。
简单来说如果有人问你一个问题，那么你给出答案，这两个就是因果关系，但如果你给出答案再问题之前，那么这个就违反了因果关系。举个简单的例子如果节点 1 更新了数据 A ，节点 2 读取数据 A ，并更新数据 B ，这里的数据 B 有可能是根据数据 A 计算出来的，所有具备因果关系，但是如果节点 3 看到的是先更新的 B ，再更新的 A 那么就破坏了因果一致性。
其实除了强一致以外，其他的一致性都可以看作为最终一致性，只是根据一致性不同模型的不同要求又衍生出了很多具体一致性模型。当然最简单的最终一致性，是不需要关注中间变化的顺序，只需要保证在某个时间点一致即可。只是这个某个时间点需要根据不同的系统，不同业务再去衡量。再最终一致性完成之前，有可能返回任何的值，不会对这些值做任何顺序保证。
可用性指“ Reads and writes always succeed” ，即服务一直可用，而且是正常响应时间。对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。所以，一般我们在衡量一个系统的可用性的时候，都是通过停机时间来计算的。
可用性分类
可用水平（%）
年可容忍停机时间
容错可用性
<1 min
极高可用性
<5 min
具有故障自动恢复能力的可用性
<53 min
高可用性
<
商品可用性
< min
通常我们描述一个系统的可用性时，我们说淘宝的系统可用性可以达到 5 个 9 ，意思就是说他的可用水平是 ，即全年停机时间不超过 ()36524*60 = min ，这是一个极高的要求。
好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。一个分布式系统，上下游设计很多系统如负载均衡、 WEB 服务器、应用代码、数据库服务器等，任何一个节点的不稳定都可以影响可用性
2000 年 7 月，加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2 年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP 。之后， CAP 理论正式成为分布式计算领域的公认定理。
CAP 理论概述：一个分布式系统最多只能同时满足一致性（ Consistency ）、可用性（ Availability ）和分区容错性（ Partition tolerance ）这三项中的两项。
需要特别指出的 CAP 中的一致性是 all nodes see the same data at the same time ，也就是线性一致性。
一致性必须从两个维度看：
（ 1 ）从客户端角度，多进程并发访问时，非分布式数据库要求更新过的数据能被后续的访问都能看到，所有都是强一致的；
（ 2 ）从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。
参考以下公式：
N — 数据复制的份数
W — 更新数据时需要保证写完成的节点数
R — 读取数据的时候需要读取的节点数
（1） 如果 W+R>N ，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库， N=2,W=2,R=1 ，则不管读的是主库还是备库的数据，都是一致的。
（2） 如果 W+R<=N ，则是弱一致性。例如对于一主一备异步复制的关系型数据库， N=2,W=1,R=1 ，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。
对于一个分布式系统来说。P 是一个基本要求， CAP 三者中，只能在 CA 两者之间做权衡，并且要想尽办法提升 P 。
包含两种系统：CP without A**、 AP without C**
我们在上文所提到的 Hdfs 、 Ceph 、 Swift, 均是属于CP without A的这个大类，只是并不是完全没有 A ，为了实现一定的可用性，一般设置副本的个数为 N>=3 。不同的 N,W,R 组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。
那么，实际生活中，也有一些是AP without C的案例，如 CAP 图中所示，大部分是 Nosql 、 CoachDB 、 Cassandra 数据库，那场景是哪些呢？
其实就是不要求正确性的场合，如某米的抢购手机场景或 12306 抢购火车票的场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲。
数据分布式存储方案 第8篇
FusionStorage的IO流程
FusionStorage的IO流程：
主机上应用APP通过OS上的启动器发送SCSI读写流到VBS模块，VBS将SCSI转换成Key-value（Key值是SCSI里的HostID，tegetID，channelID，lunID重组得到：HostID—>TreeID，tegetID—>BlockID，channelID—>snapID，lunID—>branceID）VBS中的VBP模块将下发下来的数据块进行切块（默认1M），VBS中的Client模块将Key值进行hash算法运算，将hash过后的值到DHT环上进行取模运算，得到对应的PartitionID，MDC模块将IOviow视图推送到VBS模块，VBS查找IOviow得到这个PartitionID所对应的主OSD信息，然后将Key-value发送给主OSD，主OSD将Key进行hash得到Partiton，之后MDC推送Partitonviow，OSD根据Partitionviow得到备OSD，然后通过RSM模块完成两副本的数据同步写。
FusionStorage的三种视图：
IOview：PartitonID与主OSD的对应关系。
Partitionview：主OSD与备OSD的关系，主OSD的Status，备OSD的status。
OSDview：OSD的ID，OSD的Status等信息。
数据分布式存储方案 第9篇
这三个产品是经常被人拿来做选型比较的。
（1） Etcd 和 Zookeeper 提供的能力非常相似，都是通用的一致性元信息存储，都提供 watch 机制用于变更通知和分发，也都被分布式系统用来作为共享信息存储，在软件生态中所处的位置也几乎是一样的，可以互相替代的。二者除了实现细节，语言，一致性协议上的区别，最大的区别在周边生态圈。Zookeeper 是 apache 下的，用 java 写的，提供 rpc 接口，最早从 hadoop 项目中孵化出来，在分布式系统中得到广泛使用（ hadoop, solr, kafka, mesos 等）。Etcd 是 coreos 公司旗下的开源产品，比较新，以其简单好用的 rest 接口以及活跃的社区俘获了一批用户，在新的一些集群中得到使用（比如 kubernetes ）。虽然 v3 为了性能也改成二进制 rpc 接口了，但其易用性上比 Zookeeper 还是好一些。
（2） Consul 的目标则更为具体一些， Etcd 和 Zookeeper 提供的是分布式一致性存储能力，具体的业务场景需要用户自己实现，比如服务发现，比如配置变更。而 Consul 则以服务发现和配置变更为主要目标，同时附带了 kv 存储。在软件生态中，越抽象的组件适用范围越广，但同时对具体业务场景需求的满足上肯定有不足之处。
原题：分布式存储架构分析
数据分布式存储方案 第10篇
首先是追求极简的架构，用一套存储支撑一个数据中心的全部应用。并在极简架构的基础上，实现极致的稳定、极致的可靠、极致的性能、极致的容量、极致的云化，以及极致的安全这六大存储能力，再融合到领先的硬件平台，并进行深度的核心部件优化，为客户带来安全可靠、经济高效、易用易管的全球领先的全闪分布式存储产品。
万物之始，大道至简。浪潮全闪分布式存储，追求极简的道，业内首个支持四合一架构的融合存储，客户只需要购买一套分布式存储，就能同时享有文件、块、对象和大数据四种服务。其中文件、对象和大数据三种存储服务间可以相互访问，数据无需在不同设备简进行迁移和拷贝，实现了一份数据相当于存了三份，构建成真正的统一的存储资源池。业务处理效率也翻倍提升，实现了一套存储高效支撑一个数据中心的业务。满足性能需求的同时帮助客户显著节省了TCO。
以自动驾驶场景为例，自动驾驶的过程，数据处理步骤依次是数据的采集、预处理、训练以及仿真，分别会使用到对象、大数据和文件的服务。相较于单一的协议服务，分布式存储，浪潮AS13000用一套存储就可以高效支撑自动驾驶全业务流程，显著提高流程的处理效率，同时降低多套存储设备带来的管理和运维的维护成本。
容量是分布式存储的立身之本，从PB级到EB级甚至是ZB级。为了让全闪分布式存储空间的利用效率更高，我们做了很多算法优化，如业内最领先的大比例纠删、均衡算法、压缩重删、多源零拷贝、软拷贝等智能容量算法。让存储空间利用达到最优。
其中32+2的业内最大比例的纠删能力，系统出盘率高达94%以上，而智能均衡算法，则是管理海量数据均衡落到每个节点上以及每块盘上，从而保证整个存储系统的利用率达到95%以上，让客户花的每一分钱都是有价值的。
压缩重删、软拷贝功能则是让数据存储每一份数据都是有使用价值的。通过消除重复数据对存储空间的占用，存储空间的利用效率也会更高。多种容量算法的加持，让存储空间利用达到了最优，让客户的投资收益比也达到了最大。
此外我们还提供高效的分级存储方案，实现热数据存放在SSD池，而温冷数据可以迁移至HDD池，实现了存储性能、容量、成本三者之间的更加均衡。
浪潮全闪分布式存储不仅容量追求极致，系统性能方面同样追求极致，如智能协议卸载，充分释放了CPU的网络处理工作负载，让CPU更专注于IO的处理工作，同时网卡的开销也得到了充分的满足，系统性能也会发挥到极致，从而保障整个系统链路的高性能。而小文件聚合功能，则是将数据按照4K对齐聚合，从而减少了数据写入硬盘的次数，显著地提升了小文件的性能。
智能资源调度，则实现CPU的专核专用，减少了同一任务在多核之间的切换。而数据随机小IO聚合、大块顺序写入SSD的方式，可以显著减小SSD的写放大，同时可以实现SSD的综合磨损均衡。避免出现局部热盘，从而提高SSD整体的寿命。系统性能也是得到了显著的提升。
在配套全链路的协议和ROC网络，浪潮全闪分布式存储的性能将发挥到极致。浪潮存储秉承稳定压倒一切的原则，针对数据存储全生命周期做了多重稳定保障机制的设计。
如应用层，可以对数据进行快照、克隆等，利用回收站，在数据被误删后还可以找回。而数据中心的远程复制、智能双活则可以构筑业务系统多站点同步容灾的解决方案，有效地消除了单站点的故障。而数据冗余的策略，则由领先的副本和大比例纠删的加持，用户可以更加灵活的选择和主核的使用，数据的校验则保障了数据写入内容的完整性。存储系统可以提前识别到硬件、底软等不易察觉的故障带来的数据的错写，并进行告警和修复。
针对整个服务架构，我们设计了无感知的故障切换，以及4TB/H的快速重构，实现存储系统出现故障后后台自动地切换，而前端的业务仍是稳定运行的一个状态，没有任何的卡顿。
智能亚健康检测则是对系统资源降级模式的一个快速精准的定位。如检测网络的丢包和时延，多维度来测评硬盘是否是慢盘，从而快速识别集群中的慢盘并进行剔除。针对CPU内存是否有超高占用，也进行检测，并能够进行自动的告警和关闭，确保系统的性能更加持久和稳定的可靠。
浪潮全闪分布式存储的多重数据保护模式，保障客户业务系统极致的稳定和高连续。面对大量的IT设备，客户需要一套统一管理和智能运维的平台，浪潮存储自研的InView管理软件，则可以帮助客户实现，同时还可以针对硬盘使用的空间、使用的寿命、性能等等进行预测，提前高度客户硬件等资源未来使用的情况，从而来指导客户，提前做好设备的更新迭代的规划，保证数据存储系统的可靠性和可用性。这种自动部署化的功能，可以显著地降低运维成本，提升业务的连续性，最终为客户提供一体化的智能运维解决方案。
数字化时代无云不欢，浪潮全闪分布式存储，在各类主流的云平台的适配和兼容方面都做了大量的工作。针对容器平台、OpenStack云管平台和公有云方面，浪潮AS13000全闪分布式存储都有对接接口，可以实现本地和云端数据的高效流转。客户可以更加高效地使用云端的计算力，帮助节约大量的TCO。目前针对金融、央企、国企数据下云的应用，浪潮全闪分布式存储，可以提供一体化存储解决方案，数据既可以在云端备份，也可以在本地高效地使用。
最后是极致安全。数据安全是当前的头等大事，去年国家陆续出台和更新了一系列的法律和法规以及标准，强调了数据基础设施安全的重要性。浪潮全闪分布式存储，针对数据的采集、传输、存储、处理、交换、销毁的生命周期，构筑了多维的安全保障体系。通过通信安全、应用安全、系统安全、数据安全，四个层面进行防护。从全线管理、防病毒、漏洞扫描等等，让我们的存储产品成为数据的堡垒。数据的存储，给用户足够的信息安全感。
数据分布式存储方案 第11篇
为了保证分布式存储系统的高可靠和高可用，数据在系统中一般存储多个副本。当某个副本所在的存储节点出现故障时，分布式存储系统能够自动将服务切换到其他的副本，从而实现自动容错。分布式存储系统通过复制协议将数据同步到多个存储节点，并确保多个副本之间的数据一致性。
客户端将写请求发送给主副本，主副本将写请求复制到其他备副本，常见的做法是同步操作日志（ Commit Log ）。主副本首先将操作日志同步到备副本，备副本回放操作日志，完成后通知主副本。接着，主副本修改本机，等到所有的操作都完成后再通知客户端写成功。下图中的复制协议要求主备同步成功才可以返回客户端写成功，这种协议称为强同步协议。
与强同步对应的复制方式是异步复制。在异步模式下，主副本不需要等待备副本的回应，只需要本地修改成功就可以告知客户端写操作成功。另外，主副本通过异步机制，比如单独的复制线程将客户端修改操作推送到其他副本。异步复制的好处在于系统可用性较好，但是一致性较差，如果主副本发生不可恢复故障，可能丢失最后一部分更新操作。
分布式存储系统中还可能使用基于写多个存储节点的复制协议（ Replicated-write protocol ）。比如 Dynamo 系统中的 NWR 复制协议，其中， N 为副本数量， W 为写操作的副本数， R 为读操作的副本数。
NWR 协议中多个副本不再区分主和备，客户端根据一定的策略往其中的 W 个副本写入数据，读取其中的 R 个副本。只要 W+R ＞ N ，可以保证读到的副本中至少有一个包含了最新的更新。然而，这种协议的问题在于不同副本的操作顺序可能不一致，从多个副本读取时可能出现冲突。这种方式在实际系统中比较少见，不建议使用。
数据分布式存储方案 第12篇
FusionStorage是什么？
FusionStorage是华为推出的一款可大规模横向扩展的分布式存储系统，其本质是将通用的X86、ARM服务器的本地已有的HHD磁盘，SATA盘，SAS盘，SSD盘等介质，利用分布式技术组成大规模存储资源池。利用软件系统模拟出SCSI和iSCSI接口向上层应用提供块存储服务，以满足云资源池及数据库等场景的存储需求。
FusionStorage存储系统分为了三个不同类型的版本：
Block（块存储）
File（文件存储）
OBS（分布式对象存储）
通常我们说FusionStorage是指Block版本，本文重点也是关于块存储。
FusionStorage 思想：
1.数据写入是随机的
2.存储的数据是均匀的分布在存储介质上
首先在创建存储池时，FusionStorage默认是在一块磁盘上部署一个OSD（进程），多个OSD接管上来的磁盘组成了一个地址空间，这就是存储池。
FusionStorage利用OSD所接管的底层磁盘提供存储的空间后，VM虚拟机等要想使用存储服务，首先就是能找到存储的地址。FusionStorage利用DHT分布式hash算法，将OSD提供上来的磁盘分成了2的32次方个地址块。每一个地址块用LBA ID作唯一标识，由于此地址空间过大，FusionStorage存储系统为了更好的管理与查找LBA ID，便将多个LBA ID组成的连续地址空间划分为一个Partition（区），DHT分布式hash算法的作用就是保存LBA ID与Patition的对应的关系（即LBA ID属于哪个一个Partition），与Patition对应OSD的关系（即Partition用到了哪个OSD提供上来的地址空间）。
Patition分区的个数是固定3600个。
FusionStorage的基础概念：
对于Key-value的补充，Key是写或读Value的路径。（也可以理解为Key是元数据）
数据分布式存储方案 第13篇
说到分布式存储，我们先来看一下传统的存储是怎么个样子。
传统的存储也称为集中式存储， 从概念上可以看出来是具有集中性的，也就是整个存储是集中在一个系统中的，但集中式存储并不是一个单独的设备，是集中在一套系统当中的多个设备，比如下图中的 EMC 存储就需要几个机柜来存放。
在这个存储系统中包含很多组件，除了核心的机头（控制器）、磁盘阵列（ JBOD ）和交换机等设备外，还有管理设备等辅助设备。
结构中包含一个机头，这个是存储系统中最为核心的部件。通常在机头中有包含两个控制器，互为备用，避免硬件故障导致整个存储系统的不可用。机头中通常包含前端端口和后端端口，前端端口用户为服务器提供存储服务，而后端端口用于扩充存储系统的容量。通过后端端口机头可以连接更多的存储设备，从而形成一个非常大的存储资源池。
在整个结构中，机头中是整个存储系统的核心部件，整个存储系统的高级功能都在其中实现。控制器中的软件实现对磁盘的管理，将磁盘抽象化为存储资源池，然后划分为 LUN 提供给服务器使用。这里的 LUN 其实就是在服务器上看到的磁盘。当然，一些集中式存储本身也是文件服务器，可以提供共享文件服务。无论如何，从上面我们可以看出集中式存储最大的特点是有一个统一的入口，所有数据都要经过这个入口，这个入口就是存储系统的机头。这也就是集中式存储区别于分布式存储最显著的特点。如下图所示：
数据分布式存储方案 第14篇
FusionStorage的副本机制
以三台存储节点，两副本、服务器磁盘容灾级的举例：
假设Server 01服务器盘都已物理损坏了，则在没有重构的情况下，Server 02或者Server 03都不可以在坏盘了，因为我们不能确定Server 02和Server 03坏的盘中是否有Server 01中最后的数据副本。但是，如果在Server 01服务器坏盘的同时，存储系统进行了数据重构了，则在Server 01机柜坏四块盘的情况下，Server 02可以坏3块盘，因为系统会自动将之前的数据写到Server 03服务器上，同理，如果Server 01机柜坏了，并且Server 02又坏了3块盘，这种情况下再进行数据重构后，Server 03最多坏3块盘。不重构的情况下最多坏4块盘，如果进行了数据重构则可以坏10块盘（6+3+3）
数据重构过程：
如果有一块磁盘物理损坏了，则与之对应的OSD进程产生了异常，OSD进程出现异常后，MDC进程会通过与OSD之间的心跳信息会中断，MDC会感应到此OSD状态异常，而DHT环会发现地址少了一块空间，因为OSD提供的地址空间被DHT环映射，MDC进程在5秒钟后如果还未收到此OSD的心跳后，则会修改OSDviow，同步到主MDC进程中，主MDC修改数据库信息，并且主MDC会同步到各个从MDC，还会修改IOviow，Partitionviow。修改IOviow是为了防止VBS在收到主机写IO请求的时候将数据落到此OSD所对应的故障盘，避免了写入失败。修改PartitionViow是为了将此坏盘上所对应的主OSD进程暂停，并将备OSD改为主OSD继续提供存储服务。
MDC如果在5分钟后还未收到OSD心跳，则会将此OSD踢出存储池。利用DHT重新建立DHT与OSD、Partition所映射的关系，DHT会更改坏掉的磁盘上对应的Partition，根据之前的副本将数据推送到其他的OSD接管的磁盘上。
数据分布式存储方案 第15篇
FusionStorage中的网络平面
FusionStorage网络拓扑和网络平面：
BMC/管理网络：管理网络主要是指BMC带外管理和FusionStorage内部管理流量使用的网络平面。
交换机连接到各个服务器Mgmt管理口用作带外管理。
与FSM之间的管理指令下发网络平面。
业务网络：业务网络主要用作用户应用层下发SCSI/iSCSI流量到VBS的网络平面。
存储网络：存储网络平面主要是VBS和OSD或者OSD与OSD之间的数据通信，根据不同组件之间的通信划分为了“存储前端网络”、“存储后端网络”、“存储前后端共享网络”。
1.存储前端网络：VBS组件与OSD组件之间通信的网络平面。
2.存储后端网络：OSD组件与OSD组件之间存储复制网络平面。
3.存储前后端共享网络：VBS组件和OSD组件间数据通信和OSD组件与OSD组件间数据通信使用同一个存储网络平面时，称为前后端共享网络平面。