资深架构师技术分享：一文详解分布式系统的分区

2019-08-27 11:00:38数据的复制是冗余的过程,冗余会增加可用性,并且可以有效均衡读取负载。而数据的分区是一个整体转换为局部的过程,这种拆解就像你拥有大量图书,但你的书架放不下,所以需要再加几个书架存储是一个道理。

数据的复制是冗余的过程,冗余会增加可用性,并且可以有效均衡读取负载。而数据的分区是一个整体转换为局部的过程,这种拆解就像你拥有大量图书,但你的书架放不下,所以需要再加几个书架存储是一个道理。

将整体拆分,局部存储在多个较小空间内。这种思想映射到计算机上也是一样的,当数据量过大,单个存储节点不足与存储这些数据(更大容量的磁盘没有或者太贵)时,人们想要继续存储就需要将数据集拆解并规整。这就是数据分区的意义,它是用来提高数据系统的可扩展性而引入的技术方法。

如何分区?

分区的关键在于采用一种统一的规则,这种规则可以计算出将数据放在哪个节点,并且在读取时也能计算出去哪个节点读取数据。

要做到这几点目前有三种分区方式:

分区方法看似完美的对数据的存储进行了扩展,但也引入了另外的复杂度,那就是在查询数据的时候,如果数据恰巧不在同一个分区内,就需要访问多次不同的分区这样就会加大请求的延迟,或者当我们需要对关系模型中的数据进行join操作时,由于数据在不同的分区中的不同表内,进行join的难度就会非常大,增加了多表查询的复杂程度,一种折中的解决方案是,从业务上来看,将会被join或者同时读取的数据尽量放在同一个分区上,来减少跨分区调用的性能损耗,这就相当于降低磁盘寻址寻道的次数是一样的道理,都是在降低最耗时操作的发生次数。

二级索引的分区如何设计?

上述的三种分区方案,仅仅是对主键的分区,也就是一条记录的唯一标识进行分区,但从数据库功能的角度来看,我们还需要可以根据一条记录的任意字段建立索引,以便灵活高效的查询.这样的索引,就称之为二级索引。那么二级索引在分区数据库的设计上应该如何实现呢?通常有两种设计,本地索引与全局索引。

本地索引

当写入与读取二级索引时都在本分区上进行时,我们就说这样的二级索引为本地索引,也就是说每个分区上的二级索引文件仅存储本分区上的索引数据。这样做的好处是,在写入数据时更新一条记录的二级索引会很方便,因为关于本记录的所有二级索引都在这个节点上.但是以二级索引读取某条记录时,我们没办法知道记录在哪个分区,因此我们需要进行并行查询然后将查询结果进行合并,这样做无疑放大了读取的延迟。

全局索引

与之相对的是全局索引,即对于某个二级索引,其全部的字段都在同一个分区之中(不同的全局索引在不同的分区上),当我们查询某个二级索引时,我们可以只去唯一的一个节点上进行读取数据即可,不需要并行查询,这样读取的效率会很高,但是在写入数据的时候,由于一条记录涉及的二级索引可能在多个分区上,所以需要操作多个分区这就涉及到分布式的事务一致性等问题,复杂度大大增加并影响性能。全局索引在读取数据时,如何找到索引所在分区呢?答案是,对于全局的二级索引我们可以对其采用相同的分区策略,范围分区,散列分区或者散列范围分区等. 不同的分区策略同样会影响其对区间查询的效率。

分区再平衡

多个节点上拥有多个分区,当随着数据负载的增加,每个分区的大小就会不断的增加,这样就造成了隐患,一旦一个节点失效,其上分区都将失效,占比很大的一部分数据都将失效,再比如现在向集群中加入或剔除一个新的节点,那么数据需要可以被均匀的转移到新的节点上(新节点不转移数据,而是接受新的写请求是否可行?这样做会使在一段时间内,写入请求不能均衡的请求不同的节点,大量的请求新节点会使其负载不平衡),上述问题都概括起来就是引入分区再平衡特性的原因,即为了可用性与扩展性,分区再平衡都是必不可少的特性。

固定数量的分区

分区数与节点数应当不同,这样做是为了方便其扩展。理由是:假设分区数与节点数相同,那么通过对节点数取模来决定数据被分配到哪个分区上,这种取模会造成隐患.当我们添加或者删除一个节点时,取模的数发生变化,之前的数据不能被路由到正确的分区,所以必须进行再平衡对,所有数据重新分区(类似,hashmap 的再哈希),这会导致所有数据都处于迁移的状态,整个集群将不可用。

因此,我们必须将节点数与分区数进行解耦合,在一个节点上分配固定数量的分区数,例如在集群初始化时指定一个有1024个分区,现在有三个节点,那么每个节点应该拥有341个分区,最后一个节点可能拥有342个分区,这时添加一个节点,集群拥有4个节点后,我们需要对其进行分区再平衡,仅需要将原来的三个节点上的分区各取一半即可,这样就仅仅有一半的数据在迁移的过程中(比例经过复杂的算法可以动态调整),就可以降低分区再平衡过程中的复杂度了。节点删除也是同样的道理,将该节点上的分区平均的分散在其他节点上即可,固定数量的分区方案解决了节点数与分区数的耦合,我们对分区数进行取模即可很快的确定数据所在分区,并且在迁移前后相对分区保持不变,redis的集群模式就是采用这种方式进行的分区再平衡。

动态数量分区

固定数量分区不能很好的应对热点问题,当一个分区存储的数据量远多于其他节点时,这是不合理的。由于节点数量固定,这些数据无法迁移,因此引入类似B+树节点分裂与合并的概念,我们对分区也可以根据其数据量的多少进行分裂与合并,当某个分区负载高于一个指定的阈值时,我们就会对其进行分裂,变成两个分区,这样分区的数量就发生了变化,此种方案就不能使用分区数取模的方式进行数据的散列了,仅能根据关键字区间或者哈希进行分区。但这是值得的,他可以有效的平衡各个分区的数据负载。

按节点比例进行分区

动态分区同样拥有一个弊端,那就是其分区的数量与数据量成正比,数据量的增加会不断的增加新的分区,分区数量的变多将会成为新的性能瓶颈。

因此,引入一种新的方案,结合上述两种方案,当节点数固定不变时,分区数也是固定不变的,每个节点上的分区数永远是固定数量的,这样当节点数不变时,随着数据负载的增加,其分区的大小也会不断变大,当有新的节点加入或者剔除时,会随机(可以有某些复杂的策略)选择一些节点上的分区进行分裂,一分为二的分区,一半被移动到新的节点,另一半留在原地,这样做的好处是分区的数量被节点数所限定了,不会无限的增长成为瓶颈。

手动与自动的再平衡

是否应该有数据系统自动的完成分区再平衡?这样做无疑是方便的,也有很多数据库采用,但其复杂度确是非常之高的,例如,当发生节点分区平衡时,被系统检测到节点不可用时,那么就会造成级联崩溃的情况,触发剔除节点逻辑,又会触发新的分区平衡致使整个集群崩溃。

基于简单性的原则,有管理员手动的分区再平衡是一种折中的选择。

请求路由

引入复杂的分区方案后,客户端如何知道请求的数据在哪个分区上?一般有三种方式:

无论哪种方式,只不过是路由决策的逻辑交由谁来完成的问题。

对于客户端的请求路由,需要让客户端感知到分区与节点的映射关系的变化,通常基于分布式的一致性共识组件完成,例如zk,etcd等。当分区节点启动时向zk注册自己的元数据,然后zk会将信息传播到订阅了此变化的客户端上,客户端更新分区与节点的映射关系,当有请求时直接访问对应的分区即可。其优点在于这样网络调用次数最少最高效,但依赖第三方一致性共识组件。

另一种不同的做法是,让客户端请求任意节点,分区节点根据自身持有的元数据信息判断请求的数据是否在自己的分区,在则直接处理并返回,不在则将请求转发给拥有分区的请求进行处理并返回给客户端。这样做的优点在于不依赖共识组件,但最坏情况下网络的调用次数翻倍,影响性能。

并行查询处理

当需要对多个字段进行联合查询时,分区数据库应该怎么做,我们一直探讨如何通过单独的key进行查询,但是对于大量的针对数据仓库的查询,更多的是复杂的join等多表操作.分区数据库能表现的很好吗?这就涉及到分布式数据库的分区并行查询的问题,理论上当请求到达路由层后,由路由层中并行查询优化器等组件制定并行查询计划,并委派给对应的分区,并把结果做最后的合并。这个过程中的细节非常之多,我将在之后的文章中详细介绍。

XFS分布式存储系统主要解决了那些问题？

你好，XFS分布式存储系统主要了一下5个方面的问题：1、数据完全性采用XFS文件系统，当意想不到的宕机发生后，首先，由于文件系统开启了日志功能，所以你磁盘上的文件不再会意外宕机而遭到破坏了。 不论目前文件系统上存储的文件与数据有多少，文件系统都可以根据所记录的日志在很短的时间内迅速恢复磁盘文件内容。 2、传输特性XFS文件系统采用优化算法，日志记录对整体文件操作影响非常小。 XFS查询与分配存储空间非常快。 xfs文件系统能连续提供快速的反应时间。 3、可扩展性XFS是一个全64-bit的文件系统，它可以支持上百万T字节的存储空间。 对特大文件及小尺寸文件的支持都表现出众，支持特大数量的目录。 最大可支持的文件大小为263=9x1018=9exabytes，最大文件系统尺寸为18exabytes。 4、数据结构XFS使用高效的表结构(B+树)，保证了文件系统可以快速搜索与快速空间分配。 XFS能够持续提供高速操作，文件系统的性能不受目录中目录及文件数量的限制。 5、传输带宽XFS能以接近裸设备I/O的性能存储数据。 在单个文件系统的测试中，其吞吐量最高可达7GB每秒，对单个文件的读写操作，其吞吐量可达4GB每秒。

OSS网管主要是用来做什么的？

OSS网管全称是综合业务支撑平台(移动是BOSS，联通是UNICSS)。 目前主要采用爱立信的设备。 综合业务支撑平台主要是针对移动通讯行业开发的支撑平台，综合营运商各个方面的业务管理，整合各方面的资源，使资源得以充分共享。 1、平台总体介绍：综合业务支撑平台主要应用于电信行业，帮助运营商实现灵活多变的营销策略，支撑营运商“以客户为中心”的管理理念，是一个有机的企业核心级支撑系统。 2、系统介绍：综合业务支撑平台由专业计费、综合营业、综合帐务、综合结算、客户资料统一管理、统一支付、系统监控等子系统组成：1、各专业计费子系统完成各种业务数据的采集与计费；2、综合帐务子系统实现各业务优惠、出帐、多业务合帐、帐单级优惠、交叉优惠、实时信用度控制等多功能、多业务的“一单清”；3、综合营业子系统实现多业务统一的营业受理、帐务支付和综合查询等“一台清”业务受理功能；4、综合结算子系统实现各业务国内、国际结算及各业务间结算；5、客户资料统一管理子系统提供统一的客户数据管理接口，实现多业务的客户资料共享，综合营业子系统是客户信息的初始唯一入口；6、客户支付子系统实现多业务的统一收费，并基于多服务渠道的接入扩展用户支付途径和支付手段（现金、托收、预付款、语音交费、网上交费等）；7、监控子系统通过实时采集网络上各个监控节点的信息，实现对系统中运行的各个部分、各个层次的监控告警功能。 可基于J2EE架构并采用JAVA总线式结构开发，内部各子系统模块化、标准化设计，各个子系统和其他子系统间的接口实现规范化、统一化，为其他子系统提供标准的数据接口和通讯接口，增加系统的灵活性和易扩展性。 J2EE体系架构是当前成熟、稳定的企业级应用平台，可提供多层的分布式应用模型、组件重用、一致化的安全模型、连接管理、性能优化以及灵活的事务控制，平台独立的、基于组件的J2EE解决方案不依赖于任何一个厂商的产品和API，便于系统的移植与分布。 支撑平台总体特点如下：1、分布式技术，扩展能力强，根据实际情况，结合硬件实时进行负载均衡；2、数据实体封装技术；3、系统整体设计：表现层、应用层、数据管理层、数据层相对独立实现；4、业务数据支持大容量数据库并提供与第三方数据库互连接口；5、与现有通信网相接，提供开放的标准接口；

content manager是什么意思

content manager 内容管理器；内容管理；内容经理 内容管理器例句筛选: A poor mans content managerXM：穷人的内容管理器. java is a utility class FOR connecting to the Content Manager 是用来连接ContentManager服务器的实用程序类。