带着问题学习分布式系统-36大数据

36大数据 • 7年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

带着问题学习分布式系统-36大数据

正文

很长一段时间，对分布式系统都比较感兴趣，也听说过、了解过其中一些相关的知识点，但都比较零碎。一直想系统的学习一下，但是一拖再拖，写下本文，也是希望能督促自己。

写在前面

听过很多道理，却依然过不好这一生。

看过很多关于学习的技巧、方法，却没应用到自己的学习中。

随着年纪变大，记忆力越来越差，整块的时间也越来越少，于是，越来越希望能够更高效的学习。学习是一种习惯也是一种能力，这种能力在上学期间养成是最好的，毕竟那个时候绝大部分时间都在学习。但很遗憾，我没有养成适合自己的、好的学习习惯。工作之后，除了在日常工作中用到的知识技术，很难通过自学掌握新的知识（偏向于专业知识，即技术）。而互联网行业的分支、知识点又是如此之多，于是会出现这样的情况，遇到一个新的知识，觉得很厉害很感兴趣，看两天，但很快就忘记了。另外，对于一些比较庞杂的技术，又无从下手，也很难坚持下去。

根本的问题在于学习不系统，没有把一个个的知识点连接起来，本来这些新的知识就很少在工作中实践，如果又是一个个的信息孤岛，很快就会被遗忘。另一个问题，没有良好的规划，今天看看这里，明天看看哪里，纠结于细枝末节，忘了从整体上把握。

幸好，差不多半年前开始意识到了这个问题，开始看书，看别人的博客，开始思考如何充分利用好有限的时间。自己也实践了一些想法，比如写博客，坚持写博客。也有很多没做好，比如如何学习掌握一门新技术。关于这一点，其实看了许多文章，也有很多印象深刻，觉得很有道理；也有一些好书，比如《study more，learn less》。纸上得来终觉浅，绝知此事要躬行，别人的办法再好也需要亲身实践才知道是否对自己适用。

需要学习的技术很多，要自学新知识也不是一件容易的事，选择一个自己比较感兴趣的会是一个比较好的开端，于是，打算学一学分布式系统。

带着问题，有目的的学习，先了解整体架构，在深入感兴趣的细节 ，这是我的计划。

首先得有问题，如果每日重复相同的工作，也不主动去学习，很难发现新的问题。不怕自己无知，就怕不知道自己无知，只有不断的学习，才会发现更多未知的知识领域！

带着问题出发

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

状态的维护比计算要难很多，所谓状态就是需要持久化的数据。因此主要考虑分布式存储，况且即使是分布式计算，为了节省带宽需要尽量保证data locality，也是需要分布式存储。

现在有一堆数据，可能是结构化或者半结构化，需要将数据分片（segment、fragment、shard），形成一个个的数据子集，存储到一组物理节点上，物理节点之间通过网络通信。那么需要考虑两个问题：

第一：数据如何划分;

第二：数据的可靠性、可用性问题

数据分片

数据分片是指将数据子集尽可能均衡的划分到各个物理节点上。那么会有哪些挑战呢？

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

自问自答（2017 06 28）：

带着问题学习分布式系统之数据分片

数据冗余

前面提到，分布式系统中的节点都是普通的节点，因此有一定的概率会出现物理故障，比如断电、网络不可用，这些故障导致数据的暂时不可用；另外一些故障更严重，会导致数据的丢失，比如磁盘损坏。即使单个节点的故障是小概率，当集群中的节点数目很多是，故障就成为了一个大概率事件。因此，保证数据的高可用和可靠性是分布式系统必须解决的问题。

为了避免单点故障，可行的办法就是数据冗余（复制集），即将同一份数据放在不同的物理节点，甚至是不同的数据中心。如果数据是一次写，多次读那很好办，随便从哪个副本读取都行。但对于很多分布式存储系统，比如数据库，数据是持续变化的，有读有写。那么复制集会带来什么样的挑战呢，需要如何权衡呢，假设有三个副本：

（1）三个副本的地位，大家都是平等的还是有主（primary、master）有次（secondary、slave），如果是平等的，那么每个节点都可以接收写操作；如果不平等，可以一个节点负责所有的写操作，所有节点都提供读操作，
（2）在平等的情况下，怎么保证写入操作不冲突，保证各个节点的数据是一致的，怎么保证能读取到最新的数据
（3）不平等的情况下。（3.1）写节点怎么将变更的数据同步到其他节点，同步还是异步；（3.2）非写节点能否提供读数据，如果能够允许，会不会读取到过时的数据。（3.3）主节点是怎么产生的，当主节点宕机的时候，怎么选择出新的主节点。是有统一的复制集管理中心（记录谁主谁次，各自的状态），还是复制集自己选举出一个主节点？
不管复制集内部的节点是平等的，还是有集中式节点的，只要有多个数据副本，就需要考虑数据的一致性可用性问题。按照CAP理论，只能同时满足一致性可用性分区容错性之间的二者，不同的分布式系统需要权衡。

自问自答（2017 08 30）

带着问题学习分布式之中心化复制集