分布式系统学习笔记

概念：

分布式系统：

       组件分布在网络计算机上，组件之间仅仅经过消息传递来通讯并协调行动。

节点：

       完成一组完整逻辑的程序个体，对应于server上的一个独立进程。

异常：

       在分布式系统中还存在着一种状态：超时，意味着结果彻底不肯定。分布式协议就是保证系统在各类异常情形下仍能正常的工做。

CAP理论：

1. C（Consistency：一致性）：强一致性，保证数据中的数据彻底一致；
2. A（Available：可用性）：在系统异常时，仍然能够提供服务，注：这儿的可用性，一方面要求系统能够正常的运行返回结果，另外一方面一样对响应速度有必定的保障；
3. P（Tolerance to the partition of network：分区容错性）：既然是分布式系统，不少组件都是部署在不一样的server中，经过网络通讯协调工做，这就要求在某些节点服发生网络分区异常，系统仍然能够正常工做。

 

强一致性和强可用性在实际的系统中每每不能同时兼得，须要根据需求来权衡选择；

数据存储系统：

也即数据的分布式存储方式，主要有如下几个方式：

哈希方式：

每条数据经过某种计算方式计算出Hash值并分配到对应的服务器上；

int serverId = data.hashcode % serverTotalNum; 经过这种方式就能够将数据对应到不一样的服务器上；

优势：简单易用，只须要根据数据的键值计算出serverid便可；

缺点：可扩展性不高，当须要增长服务器时会出现大量数据迁移；并且容易形成数据倾斜的问题；

数据范围分布方式：

将数据的某个特征值按照值域分为不一样区间。好比按时间、区间分割，不一样时间范围划分到不一样server上。

优势：数据区间能够自由分割，当出现数据倾斜时，即某一个区间的数据量很是大，则能够将该区间split而后将数据进行重分配；集群方便扩展，当添加新的节点，只需将数据量多的节点数据迁移到新节点便可。

缺点：须要存储大量的元信息（数据区间和server的对应关系）。

 

数据量分布方式：

这样的存储方式和数据的特征类型没有关系，能够理解成将一个大的文件分红固定大小的多个block。

优势：不会有数据倾斜的问题，并且数据迁移时速度很是快（由于一个文件由多个block组成，block在不一样的server上，迁移一个文件能够多个server并行复制这些block）。

缺点：须要存储大量的meta信息（文件和block的对应关系，block和server的对应关系）。

 

一致性哈希方式：

 

 

把数据用hash函数（如MD5），映射到一个很大的空间里，如图所示。数据的存储时，先获得一个hash值，对应到这个环中的每一个位置。一致性哈希和哈希的数据分布方式大概一致，惟一不一样的是一致性哈希hash的值域是个环。

优势：集群可扩展性好，当增长删除节点，只影响相邻的数据节点。

缺点：当一个节点挂掉时，将压力所有转移到相邻节点，有可能将相邻节点压垮。

 

副本控制问题：

当某台服务器出现故障时，这台服务器上的数据就不可访问，为了保证系统仍谈能正常运转，须要对数据存储多个副本。

引入多个副本后，引来了一系列问题：多个副本之间，读取时以哪一个副本的数据为准呢，更新时什么才算更新成功，是全部副本都更新成功仍是部分副本更新成功便可认为更新成功？这些问题其实就是CAP理论中可用性和一致性的问题。其中primary-secondary副本控制模型则是解决这类问题行之有效的方法。

 

副本的更新：

副本更新基本流程：数据更新操做发到primary节点，由primary将数据更新操做同步到其余secondary副本，根据其余副本的同步结果返回客户端响应。

以mysql的master slave简单说明下，一般状况下，mysql的更新只须要master更新成功便可响应客户端，slave能够经过binlog慢慢同步，这种情形读取slave会有必定的延迟，一致性相对较弱，可是系统的可用性有了保证；另外一种slave更新策略，数据的更新操做不只要求master更新成功，同时要求slave也要更新成功，primary和secondray数据保持同步，系统保证强一致性，但可用性相对较差，响应时间变长。

根据quorum协议，在保证必定的可用性同时又保证必定的一致性的情形下，设置副本更新成功数为总副本数的一半（即N/2+1）性价比最高。

副本的读取：

副本的读取策略和一致性的选择有关，若是须要强一致性，咱们能够只从primary副本读取，若是须要最终一致性，能够从secondary副本读取结果，若是须要读取最新数据，则按照quorum协议要求，读取相应的副本数。

副本的切换：

当系统中某个副本不可用时，须要从剩余的副本之中选取一个做为primary副原本保证后续系统的正常执行。

存储模型：

 

 

Client模块：负责用户和系统内部模块的通讯。

Master模块：负责元数据的存储以及节点健康状态的管理。

Data节点模块：用于数据的存储和数据查询返回。

 

数据的查询流程一般分两步：

1. 向master节点查询数据对应的节点信息；

2. 根据返回的节点信息链接对应节点，返回相应的数据。

数据计算处理系统：

数据投递策略：

1. at most once：数据处理最多一次，这种语义在异常状况下会有数据丢失；
2. at least once：数据处理最少一次，这种语义会形成数据的重复；
3. exactly once：数据只处理一次，这种语义支持是最复杂的，要想完成这一目标须要在数据处理的各个环节作到保障。

如何作到exactly once， 须要在数据处理各个阶段作些保证：

1. 数据接收：由不一样的数据源保证。
2. 数据传输：数据传输能够保证exactly once。
3. 数据输出：根据数据输出的类型肯定，若是数据的输出操做对于一样的数据输入保证幂等性，这样就很简单（好比能够把kafka的offset做为输出mysql的id），若是不是，要提供额外的分布式事务机制如两阶段提交等等。

异常任务的处理：

由于数据计算的节点都是无状态的，只要启动任务副本便可。

其中任务恢复策略有如下几种：

1. 简单暴力，重启任务从新计算相关数据；当某个数据执行超时或失败，则将该数据从源头开始在拓扑中从新计算。
2. 根据checkpoint重试出错的任务，典型应用：mapreduce，一个完整的数据处理是分多个阶段完成的，每一个阶段（map 或者reduce）的输出结果都会保存到相应的存储中，只要重启任务从新读取上一阶段的输出结果便可继续开始运行，没必要从开始从新执行该任务。

背压——Backpressure：

在数据处理中，常常会担忧这样一个问题：数据处理的上游消费数据速度太快，会不会压垮下游数据输出端如mysql等。 一般的解决方案：上线前期咱们会作详细的测试，评估数据下游系统承受的最大压力，而后对数据上游进行限流的配置，好比限制每秒最多消费多少数据。

数据处理通用架构：

 

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