分布式存储技术(2)

一、分布式系统CAP原则

在了解分布式系统之前，需要对分布式CAP原则进行了解，其也是分布式系统重要的组成部分。
CAP原则：指在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错），三者不可能同时做到。
Partition tolerance （分区容错）：指在分布式系统中分布的分区之前的通信可能会失败，一般来说分区容错无法避免，因此可以认为CAP中P必须要实现所以C和A无法同时做到。
Consistency （一致性）：指写操作之后的读操作，必须是写后的值而不是写之前的值。强一致和弱一致的区别在于，弱一致再变更后有短暂的不一致状态而强一致是变更后就一直是一致的。
Availability （可用性）：指服务器只要收到用户的请求就必须做出回应。
一致性和可用性的矛盾：其主要问题在于可能会出现通信失败，比如为了保证一致性，服务器在写操作时需要进行锁定保证数据同步，但这是就不能读写所以无法保证可用性。要想保证可用性就不能保证数据同步也就不能保证数据的一致性。

二、分布式系统分类

分布式系统有：分布式文件系统，分布式键值系统，分布式表格系统，分布式数据库。

1、分布式文件系统

分布式文件系统的主要功能有两个：一个是存储文档，图像，视频之类的Blob类型数据；另一个是作为分布式表格的持久层。目前流行的是google 的GFS，支持自动容错，其内部将大文件划分哼大小约为64MB的数据块并通过主控服务器实现数据管理、副本管理，自动负载均衡。其他的框架有Taobao File System，Facebook Haystack，与GFS架构相近。
GFS的系统节点可划分为三个角色：主控服务器，数据块服务器和GFS客户端。主控将文件划分为固定大小的数据块，在用数据块服务器将数据块存入磁盘中，默认复制三份。主控服务器中存储了系统元数据包括文件，对数据块之间的映射以及数据块的位置信息，也负责整个系统的全局控制比如数据库租约管理，垃圾回收以及数据库复制。
租约机制：在分布式系统中，往往会有一个中心服务器节点。该节点负责存储、维护系统中的元数据。如果系统中的各种操作都依赖于中心服务器上的元数据，那么中心服务器很容易成为性能瓶颈及存在单点故障。而通过租约机制，可以将中心服务器的“权力”下放给其他机器，并设置租约时间，主控服务器会定时给其他机器续约并检测，如果机器发生异常则停止续约，替换其他机器。就可以减轻中心服务器的压力。当然，租约机制还有许多其他的用途：比如，确定集群中结点的状态，还可以实现分布式下的读写锁。
一致性：GFS主要是为了追加（append）而不是改写（overwrite）设计的，在不发生异常情况下GFS追加的记录在各个副本中严格一致的，但出现异常GFS将重试在各个副本中至少追加成功了一次但也可能会存在重复数据的存在。所以GFS系统是弱一致性。
容错：有两种方式，通过操作日志加checkpoint的方式以及通过数据块服务器通过数据块进行获取。而数据块服务器用的是校验和来对数据进行校验
负载均衡：GFS为了提高系统可用性采取避免副本存储到一个机架上的方式。通过对服务器的磁盘利用率，以及限制创建数量，和每个子表的副本不能再同一个机架上来分配
垃圾回收：采用延迟删除的机制，即删除后不立即归还物理内存，而是隐藏并包含一个时间戳，master定时检查发现在进行删除。

2、分布式键值系统

分布式键值模型可以看作分布式表格模型的一种特例，只支持针对单个键值的crud。常见的框架有Amazon Dynamo 和Tair。
Dynamo是以简单的键值方式存储数据而不是关系型数据库，不支持复杂查询，通过组合P2P的各种技术打造了线上可运行的分布式键值系统。其存储节点包含三个组件：请求协调、成员和故障检测，存储引擎。其设计目标就是无上限的扩展性以及100%的可用性（所以一致性是最低级别的：最终一致性）
数据分布：通过使用一致性哈希算法将数据分布到多个存储节点中，原理是将系统中每个节点都分配一个随机的token，然后构成一个哈希环。执行数据存放的操作时，先计算主键的哈希值，然后存放到顺时针方向第一个大于或等于该哈希值的token所在的节点。一致性哈希的优点在于节点在加入或者删除时只对相邻的节点有影响，对其他的节点没有影响。
容错：Dynamo把异常分为两种类型：临时性的异常和永久性的异常通过宕机的时间进行判断，解决方式有

• 数据回传：在指定时间T内，异常修复就会使用Gossip协议将启动运输任务暂存的数据回传给异常机器
• Merkel树同步：如果超过指定时间，就认为是永久性需要使用Merkel树机制从其他副本进行数据同步
• NWR修复：NWR机制（N:数据的副本数量，W:写操作成功所需要的最少副本数，R:写操作成功所需要的最少副本数，。Dynamo认为只要R+W>N，可以保证集群的可用性。N、W、R的值是可以设定的。如果注重读的效率，可以把R的值设置小些；如果注重写的效率，可以把W的值设置小些。NWR并不能保证数据一致。如果R=N且W=N，那么可以保证一致性。）

负载均衡：Dynamo的负载均衡取决于如何给每台机器分配虚拟节点号，即token给物理机器分配虚拟节点。其中方法包括：随机分配和数据范围等分+随机分配。
读写流程：通过一致性哈希算法计算出每个数据副本所在的存储节点，当所有的副本都写入成功后在回复成功，如果失败则重试。读则是读多个副本并进行比较一致再报成功。
Tair是淘宝开发的一个分布式键值存储引擎，分为持久化和非持久化，非持久化Tair可视为一个分布式缓存，而持久化的Tair可以把数据存放在磁盘中。

3、分布式表格系统

分布式表格系统对外提供表格模型，每个表格有很多行组成，通过主键唯一标识，每一行包含很多列。整个表格再形同中全局有序。常见的有Google Bigtable，Hadoop。
Bigtable：是谷歌基于GFS和Chubby（分布式锁服务）开发的分布式表格系统。其主要由客户端程序库，一个主控服务器和多个子表服务器组成。实现强一致性。客户端程序库提供了Bigtable到应用上的接口，以及应用程序对表格数据的crud。主控服务器用于管理所有的子表服务器，包括分配给子表服务器，指导子表服务器实现子表合并，以及子表分裂，监控子表之间进行负载均衡以及故障恢复。子表服务器实现子表的装载和卸出，表格内容的读写，子表的合并或者分裂。
Chubby锁服务：其底层是Paxos算法，其过程是需要一个多数派的某个值达成一致，进而才能得到一个分布式一致性状态，简单来说就是只要一半以上的节点不发生故障，Chubby就能提供正常服务。
Bigtable依赖于Chubby锁服务完成：

• 选取并保证同一时间内只有一个主控服务器
• 存储Bigtable系统引导信息
• 用于配合主控服务器发现子表服务器加入和下线
• 获取Bigtable表格的schema信息以及访问控制信息

数据分布：Bigtable将数据切分成100~200MB的子表，所有数据按照主键全局排序。
复制和一致性：Bigtable系统保障强一致性，同一时刻同一子表只能被一台子表服务器服务，子表与子表服务器的使用之间是由互斥锁保证的。并且底层存储系统用的是GFS，但GFS是弱一致性系统，只能保证同一条记录至少成功写入一次，所以可能存在重复记录。而Bigtable有两种写入方式：

• 操作日志，如果子表服务器发生故障，则服务器上的子表会被其他的子表服务器加载继续服务，每条操作日志都有唯一的序号，通过这个可以去除
• 每个子表包含SSTable数据。如果写入GFS失败重试产生多条重复记录，但指挥索引到最后一条写入成功的记录。

负载均衡：通过主控服务器对子表服务器中负载的子表进行控制，如果出现某个子表服务器出现负载过重就会实行子表迁移来保证负载均衡。
分裂和合并：在存储和删除中会出现某个子表过大或者过小需要进行分裂或者合并，分裂操作是由子表服务器发起的对元数据进行更改，而合并是通过主控服务器进行的，由于子表可能不在同一个子表服务器上，所以先进行迁移再合并。

4、分布式数据库

分布式数据库是一种跨不同物理位置存储数据的数据库。它可以存储在位于同一物理位置的多台计算机中（例如数据中心）；或者可以分散在互连计算机的网络上。从定义来看，分布式数据库是一种把数据分散存储在不同物理位置的数据库。分布式数据库本身分为计算层、元数据层和存储层。其中常见的由Microsoft SQL Azure 和Google Spanner。
集群和分布式数据库区别：
集群是个物理形态，分布式是个工作方式。分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
1）分布式：一个业务分拆多个子业务，部署在不同的服务器上。
2）集群：同一个业务，部署在多个服务器上。
OceanBase 是分布式数据库的具体应用，它是阿里研发的可拓展的关系型数据库，其目标是支持数百TB的数据量以及数十万TPS、数百万QPS的访问量。用户使用OceanBase的方式和Mysql数据库完全相同，并且支持JDBC。具有数据强一致、高可用、高性能、在线扩展、高度兼容SQL标准和主流关系数据库、低成本等特点。其主要组成部分可以分为：主控服务器（RootServer），更新服务器（UpdateServer），基线数据服务器（ChunkServer）以及合并服务器（MergerServer）。
系统架构：

• 一主一备的RootServer，用于管理所有服务器包括子表服务器的上下线，更新服务器的选主，主备主控服务器实现数据强同步，子表数据分布以及副本管理。
• 一主一备的UpdateServer，存储增量更新数据。在部署时，UpdateServer进程和RootServer进程往往共用物理服务器。
• ChunkServer存储基线数据一般需要存储两到三个副本。
• MergeServer用于接收和解析用户的SQL请求，通过词法分析，语法分析，查新优化等操作后传递给ChunkServer和UpdateServer。

定期合并和数据分发：定期合并就是将UpdateServer中的增量更新分发到ChunkServer中，步骤是由UpdateServer先冻结活跃表在生成冻结内存后在开启新的活跃表后通知RootServer再有RootServer控制MergeServer进行保存或者分发。
一致性：OceanBase是强一致性的。其拥有操作日志主库和备库同binlog时，主库只有在收到备库的成功响应之后，才能够向客户端反馈提交成功。
可用性和可靠性：UpdateServer主备之间为热备，同一时刻只有一台机器为主提供写服务，当发生故障也能在几秒钟之内检测并将服务切换到备机。