分布式系统里得数据分片

数据分片考虑得问题

      ① 具体如何划分原始数据集？
      ② 当原问题的规模变大的时候，能否通过增加节点来动态适应？
      ③ 当某个节点故障的时候，能否将该节点上的任务均衡的分摊到其他节点？
      ④ 对于可修改的数据（比如数据库数据），如果某节点数据量变大，能否以及如何将部分数据迁移到其他负载较小的节点，    及达到动态均衡的效果？
      ⑤ 元数据的管理（即数据与物理节点的对应关系）规模？元数据更新的频率以及复杂度？

实现方式

    ① Hash方式：按照数据的某一特征（key）来计算哈希值，并将哈希值与系统中的节点建立映射关系,从而将哈希值不同的数据分布到不同的节点上。
优点：映射关系非常简单；需要管理的元数据也非常之少，只需要记录节点的数目以及hash方式就行了。
缺点：当加入或者删除一个节点的时候，大量的数据需要移动。比如在这里增加一个节点N3，因此hash方式变为了mod 4；很难解决数据不均衡的问题。有两种情况：原始数据的特征值分布不均匀，导致大量的数据集中到一个物理节点上；第二，对于可修改的记录数据，单条记录的数据变大。

     ② 一致hash：将数据按照特征值映射到一个首尾相接的hash环上，同时也将节点（按照IP地址或者机器名hash）映射到这个环上。对于数据，从数据在环上的位置开始，顺时针找到的第一个节点即为数据的存储节点。

          一致性hash在增加或者删除节点的时候，受到影响的数据是比较有限的，比如这里增加一个节点N3，其在环上的位置为600，因此，原来N2负责的范围段（400， 800］现在由N3（400， 600] N2(600, 800]负责，因此只需要将记录R7(id:533) 从N2,迁移到N3。

          一致性hash方式在增加节点的时候，只能分摊一个已存在节点的压力；同样，在其中一个节点挂掉的时候，该节点的压力也会被全部转移到下一个节点。
③ Range based：就是按照关键值划分成不同的区间，每个物理节点负责一个或者多个区间。以数据量的大小为片段标准。

分片特征值的选择：

在应用中，大量的数据操作都是通过这个特征值进行，那么数据分片就能提供两个额外的好处：
（1）提升性能和并发，操作被分发到不同的分片，相互独立
（2）提升系统的可用性，即使部分分片不能用，其他分片不会受到影响
还有一个问题就是：在多条数据拥有相同的特征值（如id）的情况下，这些数据一定都会分布到同一个节点上。在这种情况下有两个问题，一是不能达到节点间数据的均衡，二是如果数据超过了单个节点的存储能力。---------采用联合特征值

元数据服务器

元数据服务器的高性能、高可用，要达到这两个目标，元数据服务器就得高可扩展 -- 以此应对元数据的增长。元数据的高可用要求元数据服务器不能成为故障单点（single point of failure），因此需要元数据服务器有多个备份，并且能够在故障的时候迅速切换。
多个副本的数据一致性：
第一：主从同步，首先选出主服务器，只有主服务器提供对外服务，主服务器将元数据的变革信息以日志的方式持久化到共享存储（例如nfs），然后从服务器从共享存储读取日志并应用，达到与主服务器一致的状态，如果主服务器被检测到故障（比如通过心跳），那么会重新选出新的主服务器。
第二：通过分布式一致性协议来达到多个副本件的一致，比如大名鼎鼎的Paxos协议，以及工程中使用较多的Paxos的特化版本 -- Raft协议，协议可以实现所有备份均可以提供对外服务，并且保证强一致性。
Hadoop分布式文件系统元数据：

HDFS中的元数据服务器称为namenode，图中的NN即为NameNode，DN为Data Node（实际存储数据节点）。DataNode 会同时向主 NameNode 和备 NameNode 上报数据块的位置信息。 两台 NameNode 形成互备，一台处于 Active 状态，为主 NameNode，另外一台处于 Standby 状态，为备 NameNode，只有主 NameNode 才能对外提供读写服务。
Active NN与standby NN之间的数据同步通过共享存储实现，共享存储系统保证了Namenode的高可用。为了保证元数据的强一致性，在进行准备切换的时候，新的Active NN必须要在确认元数据完全同步之后才能继续对外提供服务。
主备切换控制器ZKFailoverController：ZKFailoverController 作为独立的进程运行，对 NameNode 的主备切换进行总体控制。ZKFailoverController 能及时检测到 NameNode 的健康状况，在主 NameNode 故障时借助 Zookeeper 实现自动的主备选举和切换，当然 NameNode 目前也支持不依赖于 Zookeeper 的手动主备切换。
Zookeeper 集群：为主备切换控制器提供主备选举支持。
共享存储系统：共享存储系统是实现 NameNode 的高可用最为关键的部分，共享存储系统保存了 NameNode 在运行过程中所产生的 HDFS 的元数据。主 NameNode 和备NameNode 通过共享存储系统实现元数据同步。
详细介绍查看 https://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-name-node/

元数据的缓存

每次对数据的请求都经过元数据服务器的话，元数据服务器的压力也是非常大的。很多应用场景，元数据的变化并不是很频繁，因此可以在访问节点上做缓存，这样应用可以直接利用缓存数据进行数据读写，减轻元数据服务器压力。存在的问题-------缓存的元数据必须与元数据服务器上的元数据一致，缓存的元数据必须是准确的，未过时的。
怎么达到缓存的强一致性呢？
① 当metadata变化的时候立即通知所有的缓存服务器（mongos），但问题是通信有延时，不可靠。
② 在缓存一致性的问题上，也可以使用版本号，基本思路是请求的时候带上缓存的版本号，路由到具体节点之后比较实际数据的版本号，如果版本号不一致，那么表示缓存信息过旧，此时需要从元数据服务器重新拉取元数据并缓存。
③ Lease机制提出的时候是为了解决分布式存储系统中缓存一致性的问题

Lease机制：

① 服务器向所有客户端发送缓存数据的同时，颁发一个lease，lease包含一个有限期（即过期时间）
② lease的含义是：在这个有效期内，服务器保证元数据不会发生变化
③ 因此客户端在这个有效期内可以放心大胆的使用缓存的元数据，如果超过了有效期，就不能使用数据了，就得去服务器请求。
④ 如果外部请求修改服务器上的元数据（元数据的修改一定在服务器上进行），那么服务器会阻塞修改请求，直到所有已颁发的lease过期，然后修改元数据，并将新的元数据和新的lease发送到客户端
⑤ 如果元数据没有发生变化，那么服务器也需要在之前已颁发的lease到期之间，重新给客户端颁发新的lease（只有lease，没有数据）

参考：

http://www.cnblogs.com/xybaby/p/7076731.html