数据分布_分布式存储--数据分布

1. 写在前面

随着数据量增大，单机的最大容量已经不能满足庞大的数据存储需求，因此寻求分布式存储作为解决方案，分布式存储通过组合很多服务器，形成一个系统对外提供服务。由于引入大量的服务器，那么分布式系统出现故障的概率就大大增加了，GFS论文中提到，在分布式系统中机器宕机故障已经不是一种少见的行为，而是一种必须要考虑进去的常见错误。我们希望分布式系统能够通过在软件层面处理这种硬件故障带来的系统错误，也就是常说的容错能力。我们希望通过系统的高容错能力给我们带来数据的高可靠和服务的高可用。
高可靠通俗的来说就是我们写下去的数据不会丢。
高可用通俗的来说就是我们可以一直进行读写服务，而不受某个节点宕机的影响。
那么既然单机故障在庞大的分布式系统中是一种常见的故障，那么我们需要将数据进行一定策略的分布，来防止单机故障引入的数据丢失风险。
高可用要求我们在即使有节点出现故障的时候也能提供服务，那么如果数据只是单纯放在一个节点，节点挂了也就无法提供服务了，同时如果数据分布不够好，也会对造成系统访问热点，影响可用性。因此数据分布的重要性不言而喻。

2. 数据分布方法

数据分布影响到系统的读写时延、负载均衡、可靠性、可用性、并发性能、可扩展性以及数据恢复等方面。通常数据分布有两种方式，partition和replication。

• partition
  Splitting a big database into smaller subsets called partitions so that different partitions can be assigned to different nodes (also known as sharding).[4]
  partition就是将一大块数据切片分配到不同的机器上。
  partition好处在于可以提高处理的并发性，减少系统热点，同时能够提高系统横向扩展能力。
• replication
  Keeping a copy of the same data on several different nodes, potentially in different locations. Replication provides redundancy: if some nodes are unavailable, the data can still be served from the remaining nodes.[4]
  replication就是将同一份数据复制相同的一份到其他机器上。
  replication好处在于能够提高数据可靠性和可用性，数据恢复可以分布式并发恢复等。缺点就是因为引入多个副本，需要一定策略保证多副本间的一致性，同时因为提供冗余也增加了系统成本。
• partition and replication
  通常在系统设计实现中是将partition和replication两种方法结合在一起，充分利用两者的优势。由于引入了partition和replication，也为系统引入了新的问题。

3. partition带来的问题

3.1 partition将存储目标切分到不同节点，如何切分，怎么保证数据均衡？

partition本之目的是为了提高扩展性，系统的能力可以随着系统的规模近线性增加，partition目的也就是为了充分利用一台机器上的多个核，或者说一套系统的多个物理机资源， 使其能力能够通过增加核数或者物理机个数得到近线性提升。
一个好的分区算法我们希望其能够使这些切片在物理资源中被均匀分配，通常在做partition的时候有以下几种方式可以选择：

• • hash
    • hash算法就是需要用户将自己的partition设置对应的key，同时需要将对应的物力资源进行编号排序，然后通过hash(key)获取这个key对应的partition所要分配的物力资源index。这种算法好处就是在物理资源不变的情况下，切片分布会非常均匀。但是对于物理资源变动的情况下，不是那么友好，比如一台物理机宕机下线，下次切片的时候如何为原本要放在这个物理机的partition切片选取新的物理机。
    • 切片均匀也不能避免系统热点问题，如果系统对于某一个partition的访问出现局部热点，会导致系统性能整体下降。
  • consistency hash
    • 一致性哈希提出的目的也是为了解决上述原始hash方式在节点变更时引起的抖动。
    • [6]原始hash算法通常使用mod的方式hash(key)%n来进行映射，就像上面说的，这种方式对于节点变更的场景不友好，consistency hash将目标分配节点通过hash分布到一个圆环，然后将hash(key)得出的结果插入这个圆环，按照顺时针的方式找到第一个节点，那么这个key就被分配到这个节点，为了使负载更均匀，又引入了虚拟节点，在真实节点很少的情况下增加虚拟节点可以增加hash的均匀度，如果真实节点很多，一个节点对应的虚拟节点可以只有一个。
  • random
    • 随机分配当然也是一种方式，在数据量较大情况下总体上来说也是均匀的
    • random的切分方式需要引入元数据存储，我们需要知道这些切片存放的位置，而hash算法则可以通过hash直接计算得到

3.2 partition粒度如何选择？

• • partition能够提高系统的横向扩展能力，同时能够提高系统并发度。原来一个大块文件单独存放到一个节点，大量的操作达到这个节点会使其成为热点，那么通过partition可以将一大块文件拆分成若干小文件，然后打散到多个节点上存储即可，我们只要记录这些打散的小文件与源文件的LBA映射关系就可以了。
  • 粒度决定并发度
    那么既然打散文件可以提升并发度，那是不是打的越散越好，这个打散粒度要控制在什么范围？
    首先我们设想一种极限场景，一个文件被打散到底层所有的存储节点上，那么带来的结果就是只要任一个底层存储节点挂掉，这个节点的数据就丢了，打的太散会降低数据可靠性。假设一台server宕机概率为p，底层存储节点数量为n（n>3），如果数据被打散到所有节点，那么丢失数据的概率就是n*p,如果只打散到一个节点，那么其数据丢失概率为p，np>p。那这样看为了保证数据可靠打散越少越好？当然单机存储可靠性依赖于单机的物理可靠性，所以为了提高可靠性会增加副本数还会做一些故障域隔离，这里不详细讨论这些，举这个例子只是说明数据打散粒度并不是越散越好。对于random方式做打散的需要记录元数据，记录其余原文件LBA映射关系，那么打散粒度越小元数据存储的数据量就越大，所以打散粒度至少需要考虑三点：访问并发度、元数据存储量、数据可靠性。

4 replication带来的问题

replication通过增加冗余的方式提高系统可用性，当然这种方式也为系统带来了很多新的问题。我们假设副本冗余数为3（为什么副本数通常设置为3？首先冗余数越多带来的成本越高，这也是为什么很多系统使用ec来存储冷数据的原因，另外副本冗余度越高可靠性越高所以选择冗余度的时候需要中和成本与可靠性，两幅本也可以，但是对于需要强一致性的场景中只要挂掉一个副本系统就无法达成大多数，导致系统处于不可用的状态，在可用性方面欠佳），3个副本分布在不同的节点，甚至是不同的机架或者数据中心，那么这3个副本该怎么放置才能够最大化提高系统可用性和性能，是使用replication带来的其中一个问题，也就是副本放置问题。另外一点是三个副本我们该如何将用户数据复制到这三个副本呢，是有用户统一并发发给三个节点还是有一个节点负责发给其他节点，这也就是三个副本间消息传递方式问题。在深入一点就是，既然是三副本冗余，我们需要保证这三个副本数据是一样的，那如何保证这三个副本的数据一致性呢，这也就是副本一致性问题。
replication之所以会带来很多问题是因为我们会对这些replicas进行修改，如果数据一旦写入就不会修改，那么也就不会有这么多后续的tradeoff。

4.1 message transfer

多个副本间数据传输路径方式有多种，简单可以分为以下几种

• • leader base
    leader base的数据传输方式是基于在副本之间选取一个leader作为replication发起者，用户将数据发到leader，由leader分发给follower。leader在接收到用户数据之后在本地持久化的同时将数据分发给follower，分发给follower的方式可以是链式的，leader将数据传给followerA，然后followerA传给follower B。另一种是半星型式复制，leader接收到数据之后并发同时发给followerA和B。链式复制占用leader的网络带宽较少，但是会增加网络延时，因为需要client需要等待至少3个网络RTT才能返回，半星型复制则会占用较多的leader网络带宽，但是用户的时延会减少一个网络RTT的时间。不同的复制方式有各自的优点，系统需要根据场景选取合适的复制方式。
    leader base的方式优点是通过选取leader来进行复制，利用leader来做IO定序，但是leader base缺点在于用户必须连接到leader才能够写数据，那么这种可能会导致一些用户时延较大，比如多个replica分布在不同的数据中心，物理距离相差很大，那么距离leader较远的用户在写入数据的时候就会有较大的时延。
    目前大多数的存储系统都是用的这种leader base复制策略，比如GFS/HDFS/Ceph/MySQL等
  • multi leader
    multi leader方式就是在集群中有多个leader，用户可以写入任意leader，leader同样需要将数据分发到follower。这种方式好处就是不同的数据中心可以都是leader，用户写数据直接发向距离自己比较近的数据中心即可，写入时延很小，这种方式有较高的容错能力。但是这种方式很容易想到的就是如果多个leader同时写一个数据域，就会出现写冲突了。
  • leader less
    leader less就是在这个副本中没有leader概念，既然没有leader，数据就只能由client直接发给各个replica了。因为缺少leader定序，那么多个replica事件顺序如何确定，通常这种类型的分布式系统是通过版本(version)来确定其读写顺序，因为没有leader，client需要做的事情就更多一点。当前亚马逊著名的Dynamo分布式系统就是leader less的数据复制模型，其在读写的时候引入Quorum机制，即r+w>n，r读取的副本数，w为写入的副本数，n为副本总数，这个约束促使系统在写入和读取之间至少会有一个replica是读取和写入副本集合的交集。系统可以设置不同的w,r数值。

4.2 replica placement

replica放置影响集群的可用性和可靠性。

• • random
    随机分布，在很多策略中仿佛都会有随机这一种最原始的策略，随机数据分布最终会将数据均匀分布到底层多个存储节点上，但是随机分布数据并没有考虑到故障域隔离。极端情况下如果三个replica被同时放到一个存储节点上，那么只要这个节点出现问题，数据就丢了。这虽然是一种极端场景，但是随机分布不排除这种可能性。
  • random with failure zone
    因为纯随机的数据分布会导致一些场景下可靠性和可用性降低，因此hdfs在数据分布时在random的基础之上增加了故障域约束，hdfs的数据分布策略是第一个replica放在与client同一台节点，第二个replica放在与第一个节点同一个机架上，第三个节点放在与前两个节点不同的机架上，如果有更多的节点则直接随机选择节点放置。hdfs在数据分布中引入了机架感知机制，让其能够感知到故障域，从而进行数据分布约束。这种基于故障域约束的副本放置策略相比较纯随机策略提高了系统的可用性和可靠性。
  • copyset[6]
    有约束的随机副本分布虽然考虑了故障域，增加了系统的可靠性与可用性。但是random在集群出现多个机器同时失效情况下其数据丢失概率会达到将近100%[6]。copyset的提出的目的就是在相同规模机器宕机情况下做到数据丢失概率最小。
    举个例子，因为通常我们的存储数据都是以chunk为单位进行partition的，每个chunk都会有3个副本，如果同一机架上9个节点，我们的以random方式从这9个节点中挑选三个节点存放chunk数据，那么在极端充分打散状况下只要这9个节点上任3个节点失效了，我们就会丢数据。显然这种数据丢失概率很大。
    同时copyset replication对于系统数据恢复层面也加入约束。数据恢复是指如果一个节点宕机损坏，新加一个节点替换当前节点，数据需要从其他节点上复制过来，那么数据恢复时间与数据恢复规模有很大关系，恢复规模是指有多少个节点并发向这个新增加的节点复制数据。
    基于降低数据丢失概率和提高数据恢复效率两方面，提出了copyset replication, copyset的主旨就是通过降低复制组的数量来降低数据丢失概率。
    copyset replication将一定数量的chunk归为一组管理，这些chunk被统一放到R个节点，(R是副本数)，这R个节点组成的单元被称之为copyset。也就是说copyset有R个节点组成，管理一批chunk。R个节点互为冗余，当一个节点挂了其他R-1个节点可以并发将这批chunk数据拷贝到新加入copyset的节点上，提高数据恢复效率。同时copyset算法引入另一个约束，ScatterWidth S。这个变量是指当前一个node上的数据会被复制到多少个其他node节点上。这个变量约束了在一个node宕机被替换时，会从多少个node上并发恢复数据。
    算法输入是冗余度R，ScatterWidth S，以及node列表，输出就是符合R和S两个约束的所有copyset。
    如下图所示，一个copyset只管理一个node上的部分chunk，一个node由多个copyset共同管理。

• • CRUSH
    CRUSH是ceph提出的一种数据分布算法，通过计算的方式实现replica在osd上的分配，同时由于引入这种计算方式，ceph实现了块存储及对象存储下去中心化的系统模型，因为所有的元数据都可以通过CRUSH计算得出。具体CRUSH算法后续会再做总结。

4.3 replica consensus

因为多个副本分布在不同节点上，提高了数据可靠性。前提是我们应该确保这些冗余副本数据是一致的，否则所谓的提高可靠性就没有意义了。当然正常情况下，网络正常、磁盘正常等等一切都正常的情况下，数据在多个副本之间肯定是一致的，但实际生产场景中没那么理想，我们需要考虑各种异常，比如网络丢包，乱序，节点宕机等等，这些异常事件会导致数据副本之间出现不一致。

• • 一致性需求级别
    数据一致性是分布式存储的基本问题之一，这个一致性基础条件是多个副本需要对某一个操作是达成共识。但是根据实际条件或者应用场景系统所要提供的一致性级别有所不同，因为越高的一致性带来的性能损失也越多。一致性有很多分类，在分布式存储一致性总结中有详细总结。
    非事物场景下线性一致性是最高要求的一致性，他的目标就是让多个副本看起来就像是只有一个副本在工作。此外还有最终一致性，最终一致性并不要求用户写入之后立马能读到自己写入的数据，而是在一定时间之后，多个副本数据才能真正达成一致。
    越强的一致性要求给上层开发者或者使用者带来越简单的使用体验，同样越强的一致性要求带来的性能损失也越大。这也是为什么在多处理器场景中，基本不会使用线性一致性的原因。
  • 如何实现线性一致性
    虽然线性一致性带来的性能损失最大，但是在一些使用场景中我们需要向用户提供强一致性数据保障，比如数据库系统。线性一致性要求用户始终能够读取最新写入的数据。raft、paxos这些共识算法可以用来实现线性一致性，基于raft为什么能够实现线性一致性，是因为raft的实现是基于atomic broadcast（原子广播）消息传递模型，这个模型也被称之为total order broadcast（全序广播）。
    原子广播是节点间消息传递协议，这个协议主要有两点：可靠传递和全序传递，可靠传递是指消息不会丢，全序传递是指消息被传递到各节点的顺序是一致的。
    线性一致性需要保证两点一个是用户的操作在各个节点的执行顺序是一样的，另一个是事件间的real time需要被保留（可参考分布式存储一致性总结）这也是原子广播与线性一致性之间的区别。
    原子广播如何实现消息被传递到各个节点的顺序是一致的，一种方法就是state machine + replication log，当前很多存储系统是基于这种模式实现线性一致性，比如etcd、tidb。

5 总结

本文针对两种常用的数据分布方法做了总结，在大型分布式存储场景中通常是两种方式结合来提高系统可用性和性能。最重要的还是根据用户场景做取舍，比如非常在意时延且对强一致性没有特别要求的场景既可以退一步提供相对较弱的一致性，如最终一致性等。

• reference

1. Distributed systems for fun and profit
2. Replication：theory and practice
3. replication and pratice pdf
4. Design Data intensive system
5. consistency hash
6. Copysets: Reducing the Frequency of Data Loss in Cloud Storage
7. Copysets and Chainsets: A Better Way to Replicate