分布式存储系统的一些理解和实践
张建伟
一、 分布式存储系统介绍
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 一致性hash
Cassandra 借鉴了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 信息，并通知name
node 对比修复
✧ 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
，这样不需要拖数据；如果要考虑写压力均
衡（即不把写压力集中在新加入的机器上，仍然写所有机器），仍需要做数据迁移。 ✧ Cassandra 和ceph ：因为key 定位是通过hash 类算法，所以拖数据不可避免。拖的数据
量即新加的node 所负责的数据量。一致性hash 和crush 算法不同，导致拖数据的源节点不一样，但总的来说大同小异。
5. 数据一致性
一致性分强一致性和最终一致性，解释如下：
强一致性：写完一条数据key1，马上读key1，能读到最新数据。
最终一致性：写完一条数据key1，马上读key1，可能读到老数据，但一段时间后，能够读到新数据。
最终一致性相比强一致性，有更高的性能。一致性跟primary 和replica 在读写时的地位相关，不同系统在实现上会有不同的取舍，下面具体说明。
1) 单主、多主、主从
✧ Hbase ：region server是单点，可以理解问题单主方式，天然的强一致性。
✧ Cassandra ：最终一致性，通过客户端一致性级别的设置也可实现强一致性。Cassandra
多个副本节点的地位相同，可以理解为多主方式，并列提供读写，这种方式读写性能很高，除了牺牲了强一致性，还有造成写冲突问题，cassandra 通过column 级别的时间戳解决此问题，但不彻底，时间戳相同时就没有办法了。
✧ Ceph ：的多个副本间有主从关系，一主多从，客户端写主节点，主节点负责写从节点。
客户端只能读主节点。以此实现强一致性。Ceph 也支持配置为本地化（就近，不一定是主节点）读方式，这种方式也牺牲了强一致性。Ceph 的块儿存储和分布式文件系统功能，要求它必须支持强一致性。
6. 性能
前面已经提到，不同的一致性会对性能有影响。
另外，还有两点对对性能影响较大：
1) 完全分布式or 集中式
集中式架构需要有meta server。读操作先查meta server，再向data node查询真正的数据；写操作除更新data node也可能要更新meta server。完全分布式读写则少了与meta server
交互的过程。所以延时更低。且集中式，在数据量巨大或者压力很大时，meta server有可能成为性能瓶颈，目前有meta server分层、静态子树等解决方案。
✧ Hbase ：是集中式的，但客户端维护meta server的缓存，一般读写时无需网络查询meta
server ，所以从hbase 这层看，集中式并不影响其性能。但hdfs 层读写必须要name node参与，所以性能低些。Hbase+hdfs这种分层架构，有很多好处，但显然性能会逊一筹。 ✧ Cassandra ：是完全分布式的，客户端可以连接任一台node 读写，这台接入node 通过一
致性hash 定位真正负责此次读写的node ，再进行读写。效率要比hbase 高些。
✧ Ceph ：是完全分布式的，客户端通过monitor server得到节点信息，缓存在本地，再通
过crush 算法，直接定位到主节点实现读写。这个角度看，ceph 的效果比cassandra 更高些。
2) 单机存储引擎
分布式存储一般采用LSMT 引擎，将随机写转化为顺序写log 和memtable （内存）方式，能极大提高写性能。读操作，还是通过索引来提高性能。分布式存储的数据模型一般是schema-less 的，即不需要预先定义每行包括哪些列以及每个列的类型，多行之间允许包括不同的列；一般只有主key 索引；不需考虑数据完整性约束（比如外键约束）、列类型约束、NOT NULL约束等；所以较适合用LSMT 引擎实现，关系数据库则不太适合。Schema-less 是分布式存储一般性能较高的原因之一。
图7 LSMT
✧ Hbase 、cassandra 、ceph 都是wal 的方式。顺序写完journal log 后，写实际数据。写数
据时，hbase 和cassandra 是写memtable （源自bigtable 吧），更多的减少随机写硬盘。Ceph 不是memtable 的方式，直接写文件系统，并定时sync 。Memtable 的方式对小value 更加友好，但需要引入的compaction ，compaction 带来了更多的运维工作。Ceph
由于
其块儿存储功能，经常会修改一个对象的某一小段，如果用memtable 的方式，即使修改一小段，也要重写整个对象，效率比较低。
7. 易运维性
主要是扩容、顶替（一台机器损坏，用另外一台机器代替之，可能涉及到迁移数据）、升级、盘故障（数据修复）等操作的快速性和简单性。
存储机器一般是12*2T盘，现在极端一些有24*4T盘。单机存储数据量是很大的。扩容或者顶替一台机器，一般也要几个小时甚至1天的时间。在这段时间内存储系统是处于副本缺失状态的，万一这段时间好的副本又出问题，后果可能很严重；所以，要尽量避免数据迁移或者缩短迁移时间。
1) 扩容、顶替、升级
✧ Hbase ：不考虑hdfs 的话，其扩容、顶替更容易，因为不涉及迁移数据。Hbase 因单点
问题，升级必然影响在线服务，这一点是一直在努力优化的，例如之前提到的region server standby机制，hdfs 的name node的热备机制。
✧ Cassandra ：由于其gossip 广播的限制，较难做的很大，所以360有多达几十个cassandra
集群，给运维带来不少工作量。扩容和顶替因涉及到迁移数据，比较麻烦，一般会绕过它，刚开始集群建设一步到位，后续不扩容，如果有机器损坏，直接修，而不是顶替。Cassandra 的升级比较有优势，3副本的情况下，可以最多一次升级1/3的机器，而不影响在线读写。
✧ Ceph ：还没搞过大集群，crush 机制理论上可以将集群建的比较大（也许几千台），但扩
容、顶替拖数据不可避免。因为不能确定数据的几个副本在那几个节点上，或者说不能确定几台机器上是否有同一批数据的副本，所以，升级为了不影响在线服务，最好一台台升级。
2) 磁盘故障
✧ 盘故障引起的数据修复，衡量其好坏的标准，就是是否够快、是否足够自动化。磁盘写
性能是修复速度的瓶颈。全局修复机制都能够做到自动化。所以，三种系统在这一点上差异不大。
8. 复杂查询与事务
分布式存储系统相对于关系数据库之所以能做到高性能、高扩展，主要的原因之一就是选择不支持复杂的联表查询与事务操作。
联表查询，分布式存储系统一般都不支持，而是通过冗余存储的方式实现类似的功能需求。
复杂的事务，也不支持。但简单的事务，如单行事务、CAS （compare –and-set ）还是可以支持的。
1) 事务
✧ Hbase ：支持单行事务（可以是多个操作），由于region sever 单点，可以在单机上较容
易的实现。这是region server单点的一个优势。
✧ Cassandra ：支持单次操作行级锁；单个column 的cas 操作（依赖paxos 多机协商，较
为复杂，效率低）。
✧ Ceph 则没有此类需求，自然不支持。
以上有些是实践总结，有些则加了自己的理解，有不对之处，还请指出，多谢。