分布式时代

前序

在大数据、大并发的背景下，分布式系统 在互联网大公司中的应用 已经非常普遍了。
常见的分布式系统 总的可以分为：

• 数据存储系统 如hdfs，hbase；
• 数据处理计算系统 如storm、spark、flink；

还有一些 存储兼计算的系统 如elastic search等，这里不做讨论先。

核心概念

CAP理论

分布式系统中需要重要理解的理论，
CAP理论，三个字母代表了系统中三个相互矛盾的属性：

• C（Consistency）: 强一致性，保证数据中的数据完全一致
• A（Available）：在系统异常时，仍然可以提供服务，
  注：这儿的可用性，一方面要求系统可以正常的运行返回结果，另一方面同样对响应速度有一定的保障
• P（Tolerance to the partition of network ）：既然是分布式系统，很多组件都是部署在不同的server中，通过网络通信协调工作，这就要求在某些节点服发生网络分区异常，系统仍然可以正常工作。

CAP 理论指出，无法设计一种分布式协议同时 完全具备 CAP属性

从以上CAP的概念我们得出一个结论，在技术选型时，根据你的需求来判断是需要AP高可用性的系统（容忍返回不一致的数据）还是CP强一致性的系统，或者根据系统提供的参数在AC之间权衡。（可能会有读者会问，为什么一定需要P呢？既然是分布式系统，在网络分区异常情况下仍然正常提供服务是必须的。）

分布式系统

其基本概念就是组件 分布 在 网络计算机上，组件 之间仅仅通过消息 传递来通信并协调行动。

节点

节点可以理解为上述概念提到的组件，集群中的个体中 完成一组逻辑的 程序个体，对应于server上的一个独立进程。
节点分为 有状态 和 无状态。

异常

分布式系统 比较突出的一个核心问题就是 异常处理。
因为 不同于 单机系统，在分布式环境中，处理结果除了明确返回成功或失败，还有另外一种状态：超时。
超时 意味着处理结果 完全不确定，有可能成功执行，也有可能执行失败，也有可能根本没执行，这给系统开发带来了很大的难度。
其实各种各样的 分布式协议 就是保证系统在 各种异常情形 下仍能正常的工作，所以在学习分布式系统时，要着重看一下 文档异常处理 的 部分。

数据存储系统

在大数据背景下的今天，单机处理能力的极限 远远不足以应付。
所以就用到 数据存储分布式系统。

数据分布方式

数据分布方式 指的是 数据时如何分布式化的。

• 哈希方式

哈希方式是最常见的数据分布方式。可以想象有一个大的hash表，其中每个桶对应的一台存储服务器，每条数据通过某种方式计算出其hash值分配到对应的桶中。

优点：

• 不需要存储数据和server映射关系的meta信息，只需记录serverId和server ip映射关系即可。

缺点：

• 可扩展性不高，当集群规模需要扩展时，集群中所有的数据需要迁移

• 一致性哈希

哈希方式下， 当添加、删除节点时候，所有节点都会参与到数据的迁移，整个集群都会受到影响。
一致性哈希 就很好地解决这个问题。一致性哈希 和 哈希 的数据分布方式大概一致，
唯一不同的是一致性哈希hash的 值域 是个 环。
比如：
一致性哈希算法下，可以认为 服务器都在一个 环上，缓存请求 落点 顺时针 寻找最近的服务器，这样的好处就是，如果一台服务器down了，只会影响一段缓存，其他的不受影响，加减服务器成本降到最低，
如果是 哈希算法，只要down掉一台缓存失败率上升至少80%

优点：

• 集群可扩展性好，当增加删除节点，只影响相邻的数据节点。。

缺点：

• 上面的优点同时也是缺点，当一个节点挂掉时，将压力全部转移到相邻节点，有可能将相邻节点压垮。

• 数据范围分布

整合数据 获得的一个特征值，然后 划分 特征值区间。

优点：

• 数据区间可以自由分割。
• 当某一个区间的数据量非常大，可将该区间进一步 切割后，进行重分配。
• 集群方便扩展，当添加新的节点，只需将数据量多的节点数据迁移到新节点即可。

缺点：

• 需要存储大量的元信息（数据区间和server的对应关系）

• 数据量分布

类似于 linux系统的日志文件的处理方式，当文件大小 达到一定值，就将文件固定封存，然后产生一个 新的文件， 把后序新的数据 写入到 新产生的 文件中。
总的来看，就是愚公移山的形式，把一个巨型文件 分解成一个一个小文件（block）。

优点：

• 不会有数据倾斜的问题，即 某一个区间的数据量非常大。
• 便于 数据迁移。
• 集群方便扩展，当添加新的节点，只需将数据量多的节点数据迁移到新节点即可。

缺点：

• 需要存储大量的meta信息（文件和block的对应关系，block和server的对应关系）。

数据分布的 高可用

上面说的是 数据分布问题，对于 数据存储系统 还有一个重点要关注的点就是 高可用，
即 当某个节点服务不可达的时候系统仍然可以正常工作。
用的最多的解决方法就是 将数据的存储增加多个副本，而且分布在不同的节点上，当某个节点挂掉的时候，可以从其他数据副本读取。

引入多个副本后，会产生一系列的问题：

• 多个副本之间，读取时以哪个副本的数据为准
• 数据更新时，怎样才算更新成功，是所有副本都更新成功还是部分副本更新成功即可认为更新成功
• 要保证副本数据的一致性

主从（primary-secondary）和去中心化（decentralized）结构 都可以 解决 上述 副本问题，其中 主从结构较为常见。

• 主从

是一种常见的 副本更新 读取 模型，这种模型相对来说简单，
所有的副本相关控制都由中心节点控制，
数据的并发修改同样都由主节点控制，这样问题就可以简化成单机问题，
极大的简化系统复杂性。
常用的代表例子就是 mysql数据库的 主从复制 。

• 去中心化

把这个中心去掉，使原来属于中心化角色的权力分散化，个点之间能自由的进行点对点交互。

数据存储系统 的 两种 架构

中心化的 节点管理 构架

这类系统主要分为三个模块：

• client模块，负责用户和系统内部模块的通信；
• master节点模块，负责元数据的存储以及节点健康状态的管理；
• data节点模块，用于数据的存储和数据查询返回。

.

数据的查询流程通常分两步：

1. 向master节点查询数据对应的节点信息；
2. 根据返回的节点信息连接对应节点，返回相应的数据。

去中心化的 节点管理 构架

与上一模型比较，其最大的变化就是该架构中不存在任何master节点，系统中的每个节点可以做类似master的任务：存储系统元信息以及管理集群节点。

.
数据的查询方式也有所不同，client可以访问系统中的任意节点，而不再局限于master节点，具体查询流程如下：

1. 查询系统中任意节点，如果该数据在此节点上则返回相应的数据，如果不在该节点，则返回对应数据的 节点地址，执行第二步；
2. 获得数据对应的地址后向相关请求数据。

数据计算处理系统

常用的数据计算主要分为两种：

• 离线批量计算
• 准实时计算

虽然开源的系统很多，且每个系统都有其侧重点，但有些问题却是共性相通的。

数据投递策略

在数据处理中首先要考虑一个问题，我们的数据记录在系统中会被处理几次

• at most once：数据处理最多一次，这种语义在异常情况下会有数据丢失
• at least once：数据处理最少一次，这种语义会造成数据的重复
• exactly once: 数据只处理一次，这种语义支持是最复杂的，要想完成这一目标需要在数据处理的各个环节做到保障。

这一点 对应 用过kafka 生产者 向 topic中 推送消息的同学来说 很好理解。

异常处理

在分布式系统中，多台服务器配合 共同完成一个功能，难免会出现一些异常，
但是异常处理 相对 数据存储系统 来说简单很多，因为 数据计算的节点 都是无状态的。
多数情况下的 异常处理思路是 以 事物的行为准则，重启任务 重新计算相关数据。

背压——Backpressure

在 数据处理 过程中，经常会担心这样一个问题：
数据处理的 上游 消费数据速度太快，会不会压垮下游数据输出端如mysql等。
通常的解决方案：根据 下游系统承受的最大压力，对 上游进行 限流的配置。
在各个实时数据处理系统都 提供了背压的功能，包括spark streaming、storm等，当下游的数据处理速度过慢，系统会自动降低上游数据的消费速度。

数据处理通用 架构

数据处理系统 的架构 大都是相似的，通常包含以下几个模块：

1. client： 负责计算任务的提交。
2. scheduler ： 计算任务的生成和计算资源的调度，同时还包含计算任务运行状况的监控和异常任务的重启。
3. worker：计算任务会分成很多小的task， worker负责这些小task的执行同时向scheduler汇报当前node可用资源及task的执行状况。