分布式范式总结

Scalability，可伸缩

垂直伸缩： scale up, scale down

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

水平伸缩： scale in, scale out

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

数据分区

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

分区的目的

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

分区的方法

随机分区

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

Round Robin/轮流分区

地球人都知道。

哈希分区（包括一致性hash）

[align=left]易于规划和实现，且均衡性较好。但是过于trivial的函数，容易导致分布不平衡譬如取模、按时间戳分配全局ID等。 取模也好，一致性hash也好，都要对某个全局ID进行Hash。 这个hash可以是注册名、注册邮箱、QQ号等。 [/align]
[align=left]普通的hash取模的方法，一旦添加和减少节点，会面临大规模的数据迁移（如果是cache服务，那么大部分cache服务会失效)，所以不可取。[/align]
一致性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

性能数据