分布式架构之“数据分发”
时间：2023-04-07 02:08:49
Linux
用心做序列化，拒绝碎片化文章上一篇文章提到为什么要
分布式，它解决了以下问题单机计算能力不足（大规模计算）、存储容量不足（大规模存储）、吞吐量低（高流量）、延迟时间长（低延迟）、并发量小（高并发）。解决了问题，同时引入了如何进行数据分发的问题。这里的“数据”是指请求流量、会话数据、存储的数据、计算、调度策略等，分布式的本质是每台机器负责原问题的一个子集，是分治的典型体现（分离与组合）思考。集群中的每台机器做同样的事情，但分布式系统中的每台机器做不同的事情。下面开始介绍本文主角分布式架构的“数据分发”。数据分发方式
1.公共散列的另一个名称是模数。可以把它想象成一个大哈希表，每一种机器都是一个桶，数据哈希值分布到每个桶中。哈希函数的可哈希性决定了数据分布的均匀性。不记录元数据信息，只记录需要知道计算方法和取模的机器总数。可扩展性低，当集群规模发生变化时，必须迁移所有数据并重新分布。集群规模扩大一倍，根据数据重新哈希，只将原来一半的数据迁移到另一台机器上。应用：Mola（https://developer.baidu.com/p...，Armor（分布式Key-Value系统），BigPipe（百度的消息传输系统）2.根据数据范围，数据看起来像一个BglobalTree，每个具体的server是一个叶子节点，metadataserver是一个中间节点，根据特征值的范围将数据划分到不同的区间，使得集群中的每个（组）server可以处理不同区间的数据，比如根据ID的取值域范围来划分。采用动态区间划分技术，每个区间的数据量尽可能多。相对于hash的方法，非常灵活。当集群扩展时，可以随意添加机器，不限于倍增方式，可以将网络上的部分数据分区迁移到新增加的机器上，完成机器扩容，需要专门的元数据服务器来维护一个大规模的集群数据分布信息。元数据会非常大，元数据服务器更容易成为瓶颈。还会出现某个区间内的数据非常大，偏斜的问题。如果某个区间内的数据量很大，则将该区间拆分为两个区间，保证每个区间内的数据都在一个固定的阈值以下。应用：大表（https://cloud.google.com/bigt...，Hbase（https://hbase.apache.org/），PNUTS（https://timyang.net/architect...3，根据数据量，不同于hash法和数据范围法，数据根据数据量分布与具体的数据特征无关.把数据看成是一个顺序增长的文件，而这个文件是按照一个相对固定的大小，分成若干个数据库（chunks），将不同的数据分布到不同的服务器上，还需要记录下具体的分布情况的数据块，并使用元数据服务器将分布信息作为元数据进行管理。一般不会出现数据偏斜的问题，将总数据量平均分配到集群中。当集群需要重新平衡时load，只需要迁移数据块，对集群的扩展没有太大的限制，只需要迁移部分数据块。扩容可以在新增加的机器上完成。缺点是需要管理复杂的元信息，元信息的高效管理将成为一个新的问题。应用：GFS(https://pdos.csail.mit.edu/6....,HDFS(https://hadoop.apache.org/doc...)4.Consistenthashing最初是作为一种通用的数据分布P2P网络分布式哈希表（DHT）算法，利用哈希函数计算数据或数据特征的哈希值，使哈希函数的输出值域成为一个闭环，随机分布在这个环上的节点，每个节点节点负责处理所有从自身顺时针到下一个节点希腊值域上的数据。普通哈希分布式数据集群的扩展非常复杂，节点数往往需要翻倍。一致性哈希可以动态添加并任意删除节点，每个节点只影响对应的Neighboring节点，节点的位置信息只与集群中机器的大小有关，元信息量通常远小于分发的元信息量根据数据范围和数据量。缺点是哈希值域很难均匀分布，即使原来均匀分布也很难保证后续会继续均匀分布。当某个节点出现异常时，该节点的所有压力都会转移到相邻的节点上，出现多米诺骨牌效应。引入虚拟节点的概念来改进算法。在系统启动之初，创建了许多虚拟节点。虚拟节点的数量一般远大于未来集群中的机器数量，虚拟节点均匀分布到一致性哈希值域环上。每个节点分片几个虚拟节点。在操作数据时，首先通过数据的哈希值找到环上对应的虚拟节点，然后通过元数据搜索找到对应的真实节点。一旦一个节点不可用，该节点的多个虚拟节点都不可用。应用：Dynamo（https://aws.amazon.com/cn/dyn...，Cassandra（http://cassandra.apache.org/）除了上面提到的四种数据分发方式，还有hashslots方法，及组合方法：如应用Doris(http://doris.incubator.apache....副本中的数据分发
分布式系统容错和可用性提升的基本手段是使用副本，数据副本的分布主要影响系统的可扩展性，下面我们会讲两种基本的数据副本分布，一个基本的数据副本策略是以机器为单位，几台机器互为副本，副本机器之间的数据是完全一样的。这种策略适用于上述各种数据分布方式，优点是简单，缺点是恢复副本数据时效率不高，可扩展性不高场景：假设有3台副本机，某时刻其中一台机器磁盘损坏丢失所有数据，并用一台新机器代替它对于一台故障机器，为了让新机器提供服务，如何从两台正常机器上复制数据？方案一：离线取一台可用的拷贝机，作为数据源拷贝数据。缺点是实际正常的作品只有一份，给数据安全带来了巨大的隐患。如果服务由于分布式协议设计或压力需要两份才能正常工作，这种方式是完全不可行的。选项2：使用较低的资源使用限制以快速方式从两个正常副本复制数据。这种方法不会停止服务，但可以选择服务压力较小的时间段。缺点是速度很慢。如果数据量很大（几个T），限速很小（1MB/s），往往需要几天时间才能完成恢复。总结：复制策略是基于机器的，不利于提高系统的扩展性。不利于系统容错。理想情况下，如果有N台机器，一台机器装好后，可以将这台机器的压力平均分配给剩下的N-1台机器，每台机器的压力只会增加1/N-1，但它可能会直接超过单机的处理能力。
更合适的做法是不以机器为复制单位，而是将数据拆分成更合理的数据段，以数据段为单位来制作复印件。控制每个数据段的大小尽可能相等，并在一定的大小之内。数据段的名称有很多，例如段、片段、块和分区。副本不再与机器硬关联，每台机器可以负责数据段的某个副本（o、p、q为数据段）。一旦副本分布与机器无关，数据丢失后的恢复效率会非常高。一旦某台机器的数据丢失，其上的数据段的副本将分布在整个集群的所有机器中，而不是仅仅分布在几台复制机器中，这样整个集群就可以同步复制和恢复数据，并且集群中的每个数据源机器都可以用非常低的资源完成复制。例如作为恢复数据源的机器限速1MB/s，100台机器参与恢复，恢复速度达到100MB/s。也有利于集群容错和集群扩展。假设集群规模为N台机器，当增加一台新机器时，只需要将每台机器的1/N-1/1/N+1个数据段迁移到新机器上即可实现新的负载均衡。从机器中的每台机器迁移数据，和数据恢复一样，效率也很高。在项目中，完全按照数据段创建副本会增加需要管理的元数据的开销，副本维护的难度也会增加。一种折衷方案是将一些数据段分组为一个数据段组，并将数据段分组为粒度以进行副本管理。这刻意将复制粒度控制在一个合适的范围内。LocalizedComputing
以上都是数据分布方式，很容易理解为分布方式只适用于数据存储。分布式计算除了要解决大规模存储问题外，还需要解决大规模计算问题。计算离不开数据，计算的规模往往与输入数据量或计算产生的中间结果数据量正相关。在分布式架构中，数据的分布方式也可以作用于计算。分布式架构中的计算节点和存储计算数据的存储节点可以位于同一台物理机上，也可以位于不同的物理机上。如果计算节点和存储节点位于不同的物理机上，计算后的数据需要通过网络传输，成本非常高，网络带宽将成为整体瓶颈架构。“移动数据不如移动计算”，这个思路是：尽量把计算调度到和存储节点在同一台物理机上的计算节点，这叫本地化计算.本地化计算是计算调度的重要优化，是分布式调度的重要思想。数据分布方式的选择
在实际工程实践中，可以根据需求和实现复杂度合理选择数据分布方式。如果能将以上几种数据分发方式灵活组合使用，往往能综合各种方式的优点，收到更好的综合效果。场景：如何解决分布式数据倾斜的问题？假设初始策略使用普通哈希，它不需要维护元数据信息。但是，可能存在数据倾斜。基于该策略，引入了按数据量分布数据的方法来解决数据倾斜问题。数据根据用户ID的哈希值进行划分。如果用户ID的数据量特别大，则统计该用户的数据量，将用户的数据按照一定的阈值划分为多个统一的数据段。这些数据段分布在集群中。大多数用户的数据量不会超过阈值，元数据中只存储超过阈值的用户的数据段分布信息。这种将普通哈希分布数据方式与数据量分布数据方式相结合的方法在实际系统中取得了很好的效果。参考资料：《分布式系统原理介绍》作者：刘杰想升职加薪？扫描下方二维码关注我推荐阅读：分布式架构“概念”新人，向大家问好
