分布式储存系统能力浅谈 (分布式存储架构)

异常分类　　分布式储存*所关心的异常类型和单体*不一样，有如下几种：　　服务器死机：规划储存*时需要考虑如何通过读取持久化介质(如机械硬盘，固态硬盘)中的数据来恢复内存信息。　　网络异常：规划容错*的一个基本原则是：网络永远是不可靠的，任何一个消息只有收到对方的回复后才可以认为发送成功，*规划时总是假设网络将会出现异常并采取相应的处理措施。　　磁盘问题：对于磁盘数据错误，往往可以采用校验和(checksum)机制来搞定。　　除了异常之外，还存在“超时”状态，RPC执行的结果有三种状态：“成功”、“失败”、“超时”(未知状态)，也称为分布式储存*的三态。

整理分享分布式储存系统能力浅谈 (分布式存储架构)，希望有所帮助，仅作参考，欢迎阅读内容。

内容相关其他词:分布式存储架构,ipfs分布式存储服务器,集中式存储和分布式存储的区别,集中式存储和分布式存储的优缺点,分布式存储排名前十名,ipfs分布式存储服务器,分布式存储和集中式存储的区别,集中存储和分布式存储区别,内容如对您有帮助，希望把内容链接给更多的朋友！

　　一致性保证　　副本是分布式储存*容错技术的唯一手段。由于多个副本的存在，如何保证副本之间的一致性是整个分布式*的理论核心。从客户端的角度来看，一致性包含如下三种情况：　　1、强一致性：　　2、弱一致性：　　3、最终一致性：最终一致性是弱一致性的一种特例。“最终”一致性有一个“不一致窗口”(时间延迟)，最终一致性描述比较粗略，其常见的变体如下：　　读写(Read-your-writes)-致性　　会话(Session)-致性　　单调读(Monotonicread)-致性　　单调写(Monotonicwrite)-致性　　从储存*的角度看，一致性主要包含如下几个方面：　　1)副本一致性：储存*的多个副本之间的数据是否一致，不一致的时间窗口等;　　2)更新顺序一致性：储存*的多个副本之间是否按拍照同的顺序执行更新*作。　　衡量指标　　评价分布式储存*有一些常用的指标:　　性能：吞吐能力(QPS、TPS)、响应延迟。　　可用性：*的可用性可以用*停服务的时间与正常服务的时间的比例来衡量。　　一致性：越是强的一致性模型，用户运用起来越简单。如果*部署在同一个数据中心，只要*规划合理，在保证强一致性的前提下，不会对性能和可用性造成太大的影响。　　可扩展性：*的可扩展性(scalability)指分布式储存*通过扩展集群服务器规模来提升*储存容量、计算量和性能的能力。　　性能分析　　一般来说，对分布式*的性能分析的结果是不精确的，然而，至少可以保证，估算的结果与实际值不会相差一个数量级。举个例子，Google的BigTable中随机写和顺序写的性能是差不多的，写入*作需要首先将*作日志写入到GFS，接着修改本地内存。为了提升性能，BigTable实现了成组提示技术。　　只有理解储存*的底层规划和实现，并在实践中不断地练习，性能估算才会越来越准。　　数据分布　　1、哈希分布(代表：Dynomo)：如果哈希函数的散列特点很好，哈希方式可以将数据比较均匀地分布到集群中去。然而，找出一个散列特点很好的哈希函数是很难的。这是因为，如果按照主键散列，那么同一个用户id下的数据可能被分散到多台服务器，这会使得一次*作同一个用户id下的多条记录变得困难;如果按照用户id散列，容易出现“数据倾斜”(dataskew)问题，即某些大用户的数据量很大，无论集群的规模有多大，这些用户始终由一台服务器处理。另一种思路就是采用一致性哈希(DistributedHashTable，DHT)算法(顺时针查找)。一致性哈希的优点在于节点加入/删除时只会影响到在哈希环中相邻的节点，而对其他节点没影响。一致性哈希算法在很大程度上避免了数据迁移。Dynamo*通过牺牲空间换时间，在每台服务器维护整个集群中所有服务器的位置信息，将查找服务器的时间复杂度降为O(l)。一致性哈希还需要考虑负载均衡，比较好的做法是引入“虚拟节点”的概念。　　2、顺序分布(代表：BigTable)：哈希散列*了数据的有序性，只支持随机读取*作，不能够支持顺序扫描。顺序分布在分布式表格*中比较常见，一般的做法是将大表顺序划分为连续的范围，每个范围称为一个子表。Bigtable将一张大表根据主键切分为有序的范围，每个有序范围是一个子表。为了支持更大的集群规模，Bigtable这样的*将索引分为两级：根表以及元数据表(Meta表)，由Meta表维护User表的位置信息。顺序分布与B+树数据结构比较相似，每个子表相当于叶子节点，随着数据的*和删除，某些子表可能变得很大，某些变得很小，数据分布不均匀。如果采用顺序分布，*规划时需要考虑子表的*与合并。子表合并的目的是为了防止*中出现过多太小的子表，减少*中的元数据。　　3、负载均衡：工作节点通过心跳包(Heartbeat，定时发送)将节点负载相关的信息，如处理器，内存，磁盘，网络等资源运用率，读写次数及读写数据量等发送给主控节点。负载均衡*作需要控制节奏，负载均衡*作需要做到比较平滑，一般来说，从新定位器器加入，到集群负载达到比较均衡的状态需要较长一段时间，比如分钟到一个小时。　　*　　*协议分为两种：强同步*和异步*，如图1。

图1主备*协议示范　　强同步*和异步*都是将主副本的数据以某种形式发送到其他副本，这种*协议称为基于主副本的*协议(Primary-basedprotocol)。这种方式要求在任何时刻只能有一个副本为主副本，由它来确定写*作之间的顺序。如果主副本出现问题，需要选举一个备副本成为新的主副本，这步*作称为选举，经典的选举协议为Paxos协议。　　主备副本之间的*一般通过*作日志来实现。*作日志的原理很简单：为了利用好磁盘的顺序读写特点，将客户端的写*作先顺序写入到磁盘中，然后使用到内存中，由于内存是随机读写设备，可以很容易通过各种数据结构，比如B+树将数据有效地组织起来。当服务器死机重新启动时，只需要回放*作日志就可以恢复内存状态。为了提升*的并发能力，*会积攒一定的*作日志再批量写入到磁盘中，这种技术一般称为成组提交。　　如果每次服务器出现问题都需要回放所有的*作日志，效率是无法忍受的，检查点(CheckPoint)正是为了搞定这个问题。*定期将内存状态以检查点文件的形式dump到磁盘中，并记录检查点时刻对应的*作日志回放点。检查点文件成功创建后，回放点之前的日志可以被垃圾回收，以后如果服务器出现问题，只需要回放检查点之后的*作日志。(内存中只有“检查点”之后的数据)　　分布式储存*要求能够自动容错，也就是说，CAP理论中的“分区可容忍性”总是需要满足的，因此，一致性和写*作的可用性不能同时满足。例如，Oracle教据库的DataGuard*组件包含三种模式：　　最大保护模式(MaximumProtection)：即强同步*模式，写*作要求主库先将*作日志(数据库的redo/undo日志)同步到至少一个备库才可以返回客户端成功。　　最大性能模式(MaximumPerformance)：即异步*模式，写*作只需要在主库上执行成功就可以返回客户端成功。　　最大可用性模式(MaximumAvailability)：上述两种模式的折衷。　　容错　　常见问题中，单机问题和磁盘问题发生概率最高。在分布式*中，可以通过租约(Lease)机制进行问题检测。　　租约机制就是带有超时时间的一种授权。假设机器A需要检测机器B是否发生问题，机器A可以给机器B发放租约，机器B持有的租约在有效期内才允许提供服务，否则主动停止服务。需要注意的是，实现租约机制时需要考虑一个提前量。　　问题恢复中，总控节点一般需要等待一段时间，比如1个小时，如果之前下线的节点重新上线，可以认为是临时性问题，否则，认为是永久性问题。停服务时间包含两个部分，问题检测时间以及问题恢复时间。问题检测时间一般在几秒到十几秒，和集群规模密切相关，集群规模越大，问题检测对总控节点造成的压力就越大，问题检测时间就越长。

图2问题恢复　　可扩展性　　分布式储存*大多都带有总控节点，基于这点，很多人会自然地认为总控节点存在瓶颈问题，认为去中心化的P2P架构更有优势。然而，事实却并非如此，主流的分布式储存*大多带有总控节点，且能够支持成千上万台的集群规模。可扩展性应该综合考虑节点问题后的恢复时间，扩容的自动化程度，扩容的灵活性等。　　分布式储存*中往往有一个总控节点用于维护数据分布信息，执行工作机管理，数据定位，问题检测和恢复，负载均衡等全局调度工作。通过引入总控节点，可以使得*的规划更加简单，并且更加容易做到强一致性，对用户友好。那么，总控节点是否会成为性能瓶颈呢?如果总控节点成为瓶颈，例如需要支持超过一万台的集群规模，或者需要支持海量的小文件，那么，可以采用两级结构，如图3所示。

图3两级元数据结构　　在数据库的扩容中，如果*的读取能力不够，可以通过增加副本的方式搞定，如果*的写入能力不够，可以根据业务的特点重新拆分数据，常见的做法为双倍扩容，即将每个分片的数据拆分为两个分片，扩容的过程中需要迁移一半的数据到新加入的储存节点。传统的数据库架构在可扩展性上面临如下问题：　　1.扩容不够灵活。　　2.扩容不够自动化。　　3.增加副本时间长。　　同一个组内的节点服务相同的数据，这样的*称为同构*。同构*的问题在于增加副本需要迁移的数据量太大，由于拷贝数据的过程中储存节点再次发生问题的概率很高，所以这样的架构很难做到自动化，不适用大规模分布式储存*。而异构*将数据划分为很多大小接近的分片，每个分片的多个副本可以分布到集群中的任何一个储存节点。由于整个集群都参与到节点的问题恢复过程，问题恢复时间很短，而且集群规模越大，优势就会越显著。

图4同构*和异构*的分别　　分布式协议　　在计算机世界里，为了搞定一件事情，另外的问题就会接踵而至，从另一个层面印证了IT架构永远是一种平衡的艺术。　　“BASE”其核心思想是根据业务特点，采用适当的方式来使*达到最终一致性(Eventualconsistency);在互联网领域，通常需要牺牲强一致性来换取*的高可用性，只需要保证数据的“最终一致”，只是这个最终时间需要在用户可以接受的范围内;但在金融相关的交易领域，依旧需要采用强一致性的方式来保障交易的准确性与可靠性。　　业界常见的事务处理模式很多，包括两阶段提交、三阶段提交、Sagas长事务、补偿模式、可靠事件模式(本地事件表、外部事件表)、可靠事件模式(非事务消息、事务消息)、TCC、Paxos及其相关变种等等。不一样的事务模型支持不一样的数据一致性，这里我们不对每种协议都展开详细讨论，在分布式储存方面，用的最多的是两阶段提交协议及Paxos协议，以下重点介绍这两种协议。　　1、两阶段提交协议(Two-phaseCommit，2PC)：经常用来实现分布式事务，在两阶段协议中，*一般包含两类节点：一类为协调者(coordinator)，通常一个*中只有一个;另一类为事务参与者(participants，cohorts或workers)，一般包含多个。　　协议中假设每个节点都会记录*作日志并持久化到非易失性储存介质，即使节点发生问题日志也不会遗失。在提交阶段，协调者将基于第一个阶段的*结果进行决策：提交或者取消。并通过引入事务的超时机制防止资源一直不能释放的情况。　　两阶段提交协议可能面临两种问题：　　事务参与者发生问题。给每个事务设置一个超时时间，如果某个事务参与者一直不响应，到达超时时间后整个事务失败。　　协调者发生问题。协调者需要将事务相关信息记录到*作日志并同步到备用协调者，假如协调者发生问题，备用协调者可以接替它完成后续的工作。如果没有备用协调者，协调者又发生了永久性问题，事务参与者将无法完成事务而一直等待下去。　　总而言之，两阶段提交协议是阻塞协议。　　2、Paxos协议：用于搞定多个节点之间的一致性问题。只要保证了多个节点之间*作日志的一致性，就能够在这些节点上构建高可用的全局服务，例如分布式锁服务，全局命名和配置服务等。为了实现高可用性，主节点往往将数据以*作日志的形式同步到备节点。如果主节点发生问题，备节点会提议自己成为主节点。网络分区的时候，可能会存在多个备节点提议(Proposer，提议者)自己成为主节点。Paxos协议保证，即使同时存在多个proposer，也能够保证所有节点最终达成一致，即选举出唯一的主节点。　　(3)Paxos与2PC的分别：Paxos协议和2PC协议在分布式*中所起的作用并不相同。Paxos协议用于保证同一个数据分片的多个副本之间的数据一致性。当这些副本分布到不一样的数据中心时，这个需要尤其强烈。2PC协议用于保证属于多个数据分片上的*作的原子性。这些数据分片可能分布在不一样的服务器上，2PC协议保证多台眼务器上的*作要么所有成功，要么所有失败。　　Paxos协议有两种用法：一种用法是用它来实现全局的锁服务或者命名和配置服务，例如GoogleChubby以及ApacheZookeeper。另外一种用法是用它来将用户数据*到多个数据中心，例如GoogleMegastore以及GoogleSpanner。　　2PC协议最大的*在于无法处理协调者死机问题。如果协调者死机，那么，2PC协议中的每个参与者可能都不知道事务应该提交还是回滚，整个协议被阻塞，执行过程中申请的资源都无法释放。因此，常见的做法是将2PC和Paxos协议结合起来，通过2PC保证多个数据分片上的*作的原子性，通过Paxos协议实现同一个数据分片的多个副本之间的一致性。另外，通过Paxos协议搞定2PC协议中协调者死机问题。当2PC协议中的协调者出现问题时，通过Paxos协议选举出新的协调者继续提供服务。　　跨机房部署　　机房之间的数据同步方式可能为强同步或者异步。如果采用异步模式，那么，备机房的数据总是落后于主机房;如果采用强同步模式，那么，备机房的数据和主机房保持一致。当主机房出现问题时，除了手工切换，还可以采用自动切换的方式，即通过分布式锁服务检测主机房的服务，当主机房出现问题时，自动将备机房切换为主机房。