分布式范式总结


Scalability,可伸缩

垂直伸缩: scale up, scale down

建议初期用这个,不用升级代码。 如果有Iaas云系统,那么硬件升级利用率也会很高。 可以内存加大,升级cpu等。

水平伸缩: scale in, scale out

伸缩性好,但是运维和实现比较难。适合有专人维护的大型系统,特别是大型分布式网站。 在应用层,数据层都可进行伸缩。 可用复制伸缩也可以分区伸缩。

数据分区

其实网上大部分说法都是偏理论的。个人认为,随机分区,hash 分区,范围分区等都是适合数据量不太大的情况下,而组合分区和自定义分区则适合海量数据的分布式集群的情况。 针对大规模分布式系统,存储这各种各样的数据,首先会根据业务进行数据划分,不同的业务会有不同的数据集群,不同热点的数据会有不同的配置(NVME, SSD, HDD),然后同一个业务相同数据会用hash分区,范围分区等一种或者几种,并且会做相应的索引文件。

分区的目的

一定要知道目的。分布存储,还是读写分离,还是加大IO吞吐。分布存储是偏均衡分布还是写满一个分区再启动另外一个分区。 数据分区后要支持的操作,譬如是否要支持按范围查询或者多个维度的范围查询 ? 是否要支持Join 操作等 ?

分区的方法

  • 随机分区

指定个随机函数。把数据分配到随机ID的分区里面。 

  • Round Robin/轮流分区

地球人都知道。

  • 哈希分区(包括一致性hash)
易于规划和实现,且均衡性较好。但是过于trivial的函数,容易导致分布不平衡譬如取模、按时间戳分配全局ID等。 取模也好,一致性hash也好,都要对某个全局ID进行Hash。 这个hash可以是注册名、注册邮箱、QQ号等。 
普通的hash取模的方法,一旦添加和减少节点,会面临大规模的数据迁移(如果是cache服务,那么大部分cache服务会失效),所以不可取。
一致性hash可以部分解决这个问题,节点个数变动只会导致部分数据迁移。  如果在一致性hash里面加入虚拟节点,可以更进一步减少数据迁移量。添加/减少一个节点只导致一个节点得数迁移。 换句话说,如果添加一个节点只能分流某个节点数据,容易不均衡。
    新增加的用户会随机的被分配到不同的机器上去,每个机器上的用户数、负载会增加。 譬如,Dynamo是采用DHT(分布哈希表)
  • 范围分区

  难以提前规划,系统是动态变化的,你很难知道范围到底是多大,并且分多少个区。数据变大后,某些过大分区还得进行裂变。而且会出现局部数据过大、局部过热等。譬如地理分区,年龄性别等。 但是按时间分区,注册邮件ID等很常用。

  如果是新增加的用户的ID是自增的,譬如腾讯QQ登录模块,根据机器性能的估算,可以让每台机器负责N(10W)个用户的登录,那么Node0(,1-100000) Node1(100001-200000), Node 2(20001-300000),那么随着用户增加,很自然的一台机器一台机器的添加。

  但是如果海量用户已经有ID,你不能保证他们会不会使用新的业务,以及来注册的先后顺序,那么必须使用hash等方式。如果某个Qzone的应用,假设当前已经有100W个QQ号被注册了,你不能保证第一来开通Qzone的一定是QQ号为1,所以你就不能采用上面这种分区方法。

   可以采用二分法进行分区,前提条件是你要估计最大的用户数。 假设某个应用最多160W个用户,按经验1台机器可以服务多少用户,先规划的分区个数为10x机器数然后去2的幂次数, (1台*10)和 2的4方近。  分区0(1-100000), 分区1(100001-200000),.........。  刚开始,分区0-15都在一台机器上; 然后两台机器,分区0-7在原来机器0,分区8-15在机器1; 4台机器,分区0-3在原机器0,分区4-7在机器新加机器1,以此类推等。

  • 组合分区

综合各个因数进行分区。

  • 自定义分区(极致就是主控服务集群控制数据的分区存储和读写)

海量,大规模建议自定义分区。譬如几倍PB的数据,支持业务种类繁多,建议自定义。其实最好的分区是有个分区模块,一个独立模块负载分区逻辑和数据迁移。应用程序首先得向该模块获取机器地址/名字空间等。 譬如GFS的控制模块。

读写分离

实现难度中等。 节点同步,部分节点进行写,部分进行读。节点间进行批量同步。适合于数据实时性不高的地方。 读多些少的应用。

数据迁移和扩容

基于数据库的复制和扩容

譬如基于mysql的复制进行进行一分为二扩容。在线迁移,不影响可用性,性能不错。但是伸缩性不好。 mysql的在线复制和水平分区。 在线复制也可以进行分区,在目的节点建立待迁移分区数据的复制,完全同步后修改路由信息。  路由表的改变可以由版本号来确定。

基于总控节点数据无迁移扩容

譬如GFS, HADOOP, Bigtable等添加节点不需要进行数据迁移。 但是总控节点得元数据如果存放不下的话,还是需要迁移的,但是量会少很多。至于总控节点如何实现,则不讨论。 对于Bigtable扩容问题Google本身的论文描述有些暧昧,但却可在另一个类Bigtable系统——hypertable——那里看到比较清晰的说法。Hypertable是Bigtable的开源C++实现。由于Hypertable中记录存储是被集合成固定大小的tablet(默认的最大值是每个200M)存在DFS上——而DFS本身具有可扩容性(允许在线添加新机器到server farm中)—— 因此Hypertable存储总空间的扩容不存任何问题。

高可靠、高可用

相关数据

可以采用google公布的数据。 软件/OS 故障:>10%. 硬盘故障:8%。 内存、网卡故障> 1%.  交换机故障<1%。

可靠性与副本数、故障周期成正比;与故障恢复时间,故障率,组合(串行系数)成反比。

不建议做很多块磁盘的RAID, 会降低速度。 而且要减少组合。

 

多复本读写

读一写全,读全写一,Quorum读写等。  可以使用两阶段提交达到副本数据写的强一致性。 热备等。 Quorum读写无法保证强一致性。

数据一致性

参考笔者这篇文章: http://blog.csdn.net/dellme99/article/details/15340955

 

负载均衡

参考笔者这篇文章: http://blog.csdn.net/dellme99/article/details/14644521

性能数据



你可能感兴趣的:(互联网,分布式,架构)