分布式存储系统的一些理解和实践张建伟一、分布式存储系统介绍1.简介互联网数据规模越来越大，并发请求越来越高，传统的关系数据库，在很多使用场景下并不能很好的满足需求。

分布式存储系统应运而生。

它有良好的扩展性，弱化关系数据模型，甚至弱化一致性要求，以得到高并发和高性能。

按功能分类，主要有以下几种：✧分布式文件系统hdfs ceph glusterfs tfs✧分布式对象存储s3(dynamo) ceph bcs(mola)✧分布式表格存储hbase cassandra oceanbase✧块存储ceph ebs(amazon)分布式存储系统，包括分布式系统和单机存储两部分；不同的系统，虽在功能支持、实现机制、实现语言等方面是有差异的，但其设计时，关注的关键问题是基本相同的。

单机存储的主流实现方式，有hash引擎、B+树引擎和LSM树(Log Structured Merge Tree)三种，不展开介绍。

本文第二章节，主要结合hbase、cassandra和ceph，讲下分布式系统设计部分，需要关注的关键问题。

2.适用场景各分布式存储系统功能定位不尽相同，但其适用和不适用的场景，在一定程度上是相同的，如下。

1)适用大数据量（大于100T，乃至几十PB）key/value或者半结构化数据高吞吐高性能高扩展2)不适用Sql查询复杂查询，如联表查询复杂事务二、分布式存储系统设计要点1.数据分布分布式存储，可以由成千甚至上万台机器组成，以实现海量数据存储和高并发。

那它最先要解决的就是数据分布问题，即哪些数据存储在哪些机器（节点）上。

常用的有hash类算法和用meta表映射两种方式。

一般完全分布式的设计（无master节点），会用hash类算法；而集中式的设计（有master节点）用meta表映射的方式。

两者各有优缺点，后面讲到具体问题时再做比较。

1)一致性hash将存储节点和操作的key（key唯一标识存储的object，有时也叫object name）都hash到0~2的32次方区间。

映射到如下环中的某个位置。

沿操作key的位置顺时针找到的第一个节点即为此key的primary存储节点。

如下图所示：图1 一致性hashCassandra借鉴了dynamo的实现，用了一致性hash的方式。

节点的hash值（也叫token），可以手动分配或者自动生成。

Key的hash值即md5(key)。

每个表可以在建表时指定副本数，当副本数为3时，找primary存储节点后，顺时针方向的下2个存储节点即为replica存储节点。

Hash类算法，优点是无需master节点，一个缺点是，不支持key的顺序扫描。

2)Crush算法也是一种类hash算法，随着ceph诞生，也是ceph的一大亮点。

Crush算法比较复杂，这里简化介绍下。

Ceph的每个Object最终都会映射到一组OSD中，由这组OSD保存这个Object，映射流程如下：Object → PG → OSD set•OSD先理解为机器节点吧•PG即Placement Groups，可以理解为存储在同一组OSD上的object的集合Object先映射到PG(Placement Group)，再由PG映射到OSD set。

每个表空间有固定数量的pg，在建表时指定。

每个Object通过计算hash值并对pg数量取模得到它所对应的PG。

PG 再映射到一组OSD（OSD的个数由表的副本数决定，也是建表时指定），第一个OSD是Primary，剩下的都是Replicas。

PG → OSD set 的映射由几个因素决定：•CRUSH hash算法：一种伪随机算法。

•OSD MAP：包含当前所有OSD的状态、OSD的机器机架信息等。

•CRUSH Rules：数据映射的策略。

这些策略可以灵活的设置object存放的区域。

比如可以指定table1中所有objects放置在机架1上，所有objects的第1个副本放置在机架1上的服务器A上，第2个副本分布在机架1上的服务器B上。

table2中所有的object分布在机架2、3、4上，所有Object的第1个副本分布在机架2的服务器上，第2个副本分布在机架3的服器上，第3个副本分布在机架4的服务器上。

具体实现不再展开。

图2 ceph crush算法伪代码如下所示：Crush相比一致性hash更加灵活。

3)按range查表由master节点记录和管理每个表range的粒度，以及每个range的数据存储在哪些节点上。

range是根据key的字节序确定。

Client在执行key存取操作是，先到master，根据其所在range，查询其存储在哪些节点；再直接跟存储节点交互，实现存取。

Hbase是用这种方式实现，支持key的顺序扫描。

如下图所示，region即一段range的数据（存储在mater server上），region sever即实际存储节点。

图3 hbase region映射2.数据可靠性数据可靠性，即数据不丢失，是存储系统的第一职责。

图4 数据中心分布式一般采用普通服务器，要假设服务器和硬盘都是不可靠的。

如何保证在有硬件损坏时数据不丢失，是任何分布式存储系统都必须考虑的。

已有做法有以下几种。

1)多副本即数据保存N+1份（一般是3份），每一份都存储在不同的节点上。

在数据损坏N份时，仍能修复数据。

缺点是，需N倍的冗余存储空间。

hbase、cassandra、ceph都很好的支持。

2)纠删码即将一条数据切分成n等份，通过对这n份数据编码，得到m份相等大小的校验数据块儿。

这n+m份数据，各自存储在不同的节点上，拿到n+m中的任意n份数据，均可计算得到原始的数据。

一般n取10，m取3。

优点是，只需m/n倍的冗余空间，缺点是读写效率较低，且耗费cpu。

图5 纠删码✧Hbase：hdfs层为hbase提供支持。

✧Cassandra：社区版本不支持，社区还无添加此功能的路线图，之前社区有讨论过此功能，后来不了了之。

应该是主要考虑到纠删码方式对现有系统的存储结构、一致性语义都有较大影响，且性能较低。

✧Ceph：支持。

但在功能上有些缺失，比如不支持partial read，适合读远多于写的场景，应用较少。

3)跨级群自动备份一般为了更高的可靠性，数据会通过准实时备份机制，备份到另外一个IDC的存储集群。

✧Hbase：社区版本已经支持。

✧cassandra和ceph：都不支持，短期没有路线图，长远来讲，是需要添加的。

4)接入修复客户端写数据到存储集群，一般先按一定规则找到一个接入节点，再由次接入节点做proxy 将数据写到实际存储的节点。

假设需要写入3副本，如果接入节点发现，有的副本对应的存储节点此时不可用，或者写超时，那么会将写失败的节点及未写成功的数据存储下来。

之后，定时或者收到通知不可用节点变为可用时，尝试写入之前未写成功的数据。

✧Hbase：hdfs层会保证写入足够的副本，因为hdfs的namenode记录了每个block的meta数据（block存储在哪些datanode），一个datanode写失败，换一个写，直至写成功。

可以看到，记录meta这种方式很灵活✧Cassandra：有hinthandoff机制，原理如上✧Ceph：有pglog机制，原理如上5)全局扫描修复用以修复磁盘损坏、误删文件等原因引起的数据丢失。

由master节点发起全局数据，或者primary节点发起自己负责的range的数据，的多个副本间的数据扫描。

如果发现某个副本缺失，则进行修复。

Hbase、cassandra、ceph都有类似机制，原理类似，机制不同，这里不一一展开讲了。

✧Hbase：hdfs层的data node在发现盘损坏后，会收集剩下的所有block信息，并通知namenode对比修复✧Cassandra：基于Merkle tree的anti-entropy机制✧Ceph：scrub和deep-scrub机制3.可用性分布式存储系统，相比传统关系数据库，有更好的可用性。

在个别机器硬件或软件故障，甚至整个机房断电断网等极端情况下，仍不影响在线读写。

对于个别机器硬件或者软件故障，一般数据保存多份副本或者纠删码方式就能解决。

对于整个机房断电，只能是多副本的跨idc存储，一般分布式存储系统都支持这种方式，只是目前实际应用的很少。

保证可用性，另外一个影响因素是，整个系统是否有单点故障。

完全分布式的设计是没有单点的。

集中式的设计，有meta信息，需要meta server的角色，一般也会将meta server做成集群式，以避免单点问题。

下面结合例子讲下。

1)分布式or集中式✧Hbase：meta server是集群方式，通过zk的选举算法选出一个主节点来提供服务，主节点挂掉后，会重新选一个。

所以hbase的meta server也不算是单点的。

但其region server 是单点的，即一个region server挂掉，在master没有为其负责的region进行重分配前，这个region所负责的range，是无法提供在线读写的。

之所以存在此单点问题，猜测因为hbase设计之初，是为网页库这类离线存储设计的，而非在线服务。

另外，region server 的这种设计能较方便是实现强一致性和简单事务，后面会提到。

现在貌似已有region server的stand by机制，即一台region server挂掉，另一台准备就绪的能马上接替并提供服务。

Hbase架构如下：图6 hbase架构✧cassandra和ceph：是完全分布式的（ceph虽有monitor server，但仍可理解为完全分布式的，这里不展开了），无单点问题。

4.可扩展性存储系统的可扩展性，即扩容的难易程度。

可扩展性是分布式系统相比传统关系数据库，最大的优势。

各分布式存储系统都能很好的支持横向扩展。

由于实现方式的不同，扩容的难易程度还是有差异的。

一般集中式的系统扩容更加容易，完全分布式的系统会更加麻烦些。

下面结合例子讲下。

1)扩容✧Hbase：比较容易，扩容的大致过程为：增加一些region server，由master server做一下balance，即重新确定region server与region的对应关系（每个region负责一定范围的key，对应于hdfs上的一组文件），完全不需要拖数据。

而hdfs本身扩容也较容易，因为有name node存在（相当于master server，对写入hdfs的每个块儿都记录其存储节点），可以将新写入的文件写入到新扩容的server，这样不需要拖数据；如果要考虑写压力均衡（即不把写压力集中在新加入的机器上，仍然写所有机器），仍需要做数据迁移。