分布式要解决的问题

分布式要解决什么问题呢？解决持久化数据太大，单个节点的硬盘没法存储的问题；解决运算量太大，单个节点的内存、CPU没法处理的问题。

数据分片
数据冗余

解决这些问题，有两种思路：scale up，scale out。前者就是提高单个节点的能力，更大的磁盘，更快的CPU，定制的软硬件，然而这意味着更高的价格，并且再怎么scaleup 也是有上限的。后者就是把存储、计算任务分担到普通的机器上，经过动态增长节点来应对数据量的增加，但缺点是多个节点的管理、任务的调度比较麻烦，这也是分布式系统研究和解决的问题。只有当数据量达到单机没法存储、处理的状况下才考虑分布式，否则都是自找麻烦。

　　状态的维护比计算要难不少，所谓状态就是须要持久化的数据。所以主要考虑分布式存储，何况即便是分布式计算，为了节省带宽须要尽可能保证data locality，也是须要分布式存储。

　　如今有一堆数据，多是结构化或者半结构化，须要将数据分片（segment、fragment、shard），造成一个个的数据子集，存储到一组物理节点上，物理节点之间经过网络通讯。那么须要考虑两个问题：
　　第一：数据如何划分;
　　第二：数据的可靠性、可用性问题

数据分片
　　数据分片是指将数据子集尽量均衡的划分到各个物理节点上。那么会有哪些挑战呢？
　　（1）若是某个物理节点宕机，如何将该物理节点负责的数据尽快的转移到其余物理节点；
　　（2）若是新增了物理节点，怎么从其余节点迁移数据到新节点；
　　（3）对于可修改的数据（即不是只能追加的数据），好比数据库数据，若是某节点数据量变大，怎么将部分数据迁移到其余负载较小的节点，及达到动态均衡的效果。
　　（4）元数据的管理问题：当数据分布在各个节点，那么当用户使用的时候须要知道具体的数据在哪个节点上。所以，系统须要维护数据的元数据：即每个数据所在的位置、状态等信息。当用户须要具体的数据时，先查询元数据，而后再去具体的节点上查询。当数据在节点之间迁移的时候，也须要更新元数据。元数据的管理节点这里称之为meta server。元数据的管理也带来了新的挑战：
　　　　（4.1）如何抽取数据的特征（特征是分片的依据，也是用户查询数据时的key），或者支持用户自定义数据特征；
　　　　（4.2）如何保证meta server的高性能和高可用，是单点仍是复制集
　　（5）分片的粒度，即数据子集的大小，也是数据迁移的基本单位。粒度过粗，不利于数据均衡；粒度过细，管理、迁移成本又会比较大。

数据冗余
　　前面提到，分布式系统中的节点都是普通的节点，所以有必定的几率会出现物理故障，好比断电、网络不可用，这些故障致使数据的暂时不可用；另一些故障更严重，会致使数据的丢失，好比磁盘损坏。即便单个节点的故障是小几率，当集群中的节点数目不少是，故障就成为了一个大几率事件。所以，保证数据的高可用和可靠性是分布式系统必须解决的问题。
　　为了不单点故障，可行的办法就是数据冗余（复制集），即将同一份数据放在不一样的物理节点，甚至是不一样的数据中心。若是数据是一次写，屡次读那很好办，随便从哪一个副本读取都行。但对于不少分布式存储系统，好比数据库，数据是持续变化的，有读有写。那么复制集会带来什么样的挑战呢，须要如何权衡呢，假设有三个副本：
　　（1）三个副本的地位，你们都是平等的仍是有主（primary、master）有次（secondary、slave），若是是平等的，那么每一个节点均可以接收写操做；若是不平等，能够一个节点负责全部的写操做，全部节点都提供读操做，
　　（2）在平等的状况下，怎么保证写入操做不冲突，保证各个节点的数据是一致的，怎么保证能读取到最新的数据
　　（3）不平等的状况下
　　　　（3.1）写节点怎么将变动的数据同步到其余节点，同步仍是异步；
　　　　（3.2）非写节点可否提供读数据，若是可以容许，会不会读取到过期的数据。
　　　　（3.3）主节点是怎么产生的，当主节点宕机的时候，怎么选择出新的主节点。是有统一的复制集管理中心（记录谁主谁次，各自的状态），仍是复制集本身选举出一个主节点？
　　（4）无论复制集内部的节点是平等的，仍是有集中式节点的，只要有多个数据副本，就须要考虑数据的一致性可用性问题。按照CAP理论，只能同时知足一致性 可用性 分区容错性之间的两者，不一样的分布式系统须要权衡。