一、MR - 同流合污的技术
MapReduce：大而化小，分而治之。Map负责把大任务分割为小任务，Reduce负责对Map结果进行汇总。子问题相互独立，子问题的解合并后可得到原问题的解。
架构：MRMater负责分配任务、协调任务，并为Mapper分配map()函数操作，为Reducer分配reduce()函数操作。Mapper Worker负责map函数功能，即执行子任务。Reducer Worker负责reduce函数功能，即负责汇总任务。

二、Stream - 流式计算。
流数据：源源不断的、具有时效性的数据。
特点：实时加载数据，不存储数据，处理过程计算逻辑不可更改，逻辑一旦修改之前的数据无法重新计算，低时延。适合对时间敏感的实时计算，数据密集型但可以拆分为小批量数据的任务。如Storm、IBM、淘宝银河等。
Storm：Nimbus运行在主节点负责分发代码和任务分配。Worker进程分为Spout用来接收数据和Bolt用来处理数据。

三、Actor - 封装的实现
开发分布式模式时，需要维护进程之间的状态、数据等，工作量巨大。而Actor就帮我们实现了。指定了Actor内部的计算逻辑和多个Actor之间的通信规则。
多个Actor以消息传递，每个Actor都有个信箱。
实现了更高级别的抽象、非阻塞、无锁、并发高、易扩展。但代码重用性小、系统开销大、实现复杂、不适用严格要求消息顺序的系统。
应用有：Erlang/OTP、Akka、Quasar等。

四、流水线
节点1处理任务A第一步 -> 随后，节点2处理任务A第二步，空闲的节点1处理任务B第一步。把同个任务拆分为多个步骤交由不同节点执行。每个节点顺序的处理多个任务中特定的某一步。
MapReduce强调大任务拆分为小任务，任务间执行相同的逻辑且无依赖。流水线强调同一个任务分为不同的步骤，一个节点的输出是下一个节点的输入。
例如：TensorFlow的机器学习流水线来讲：

• 节点1处理第N任务的数据的输入，然后交由节点2，节点1继续处理第N+1个任务的输入。
• 节点2执行数据转换，然后交由节点3。节点2继续做下一个任务的数据转换。
• 节点3做特征提取，然后交由节点4。节点3继续做下一个任务的特征提取
• 节点4做模型训练。

一、分布式结构体系 - 集中式
把多个服务器管理起来，作为一个统一的资源提供服务，即主从结构。
1、Borg：Google内部使用的集群管理系统，负责提交、调度、开始、重启等。闭源，单层调度框架，基本调度单元是Job，基本操作单元是Task。客户有Google。
2、Kubernetes：用于自动部署、扩展、容器管理。开源，单层调度框架，基于Borg实现。消除编排计算、网路和存储设施负担。基本调度单元是Pod，基本操作单元是Service。客户有网易云、华为等
3、Mesos：Apache旗下开源分布式资源管理框架，被称为分布式系统内核。开源，双层调度框架。为用户的数据中心提供动态的资源分配。基本调度单元是容器、Jon，基本操作单元是Task。客户有Twitter、Apple、爱奇艺等

二、分布式结构体系 - 非集中式
服务的执行和数据的存储被分散到不同的服务器集群，集群间通过消息通信。没有中央服务器和节点服务器之分，所有服务器地位平等。
1、Akka：完全去中心化的集群管理系统，每个节点进行数据处理和任务执行，节点间可通信。使用Gossip协议，成员之间P2P结构的网络拓扑。需要选主。
2、Redis集群：使用Gossip协议，基于哈希槽的网络拓扑。需要选主。为高可用每个节点都需要有一个从库。
3、Cassandra：一致性哈希的P2P结构，使用Gossip协议，不需要选主。

三、分布式调度 - 单体调度
一个集群中只有一个节点运行调度进程，该节点可访问其他节点，搜集其他节点的资源信息和状态。根据用户下发的任务需求选择最合适的节点执行。单体调度器拥有全局资源视图和全局任务，可以很容易地实现对任务的约束并实施全局性的调度策略。如Borg、Kubernetes等。
调度设计：以任务为单位调度。
调度算法：

• 筛选可行：如某任务指定在1、3、5节点执行，并需要内存多少CPU多少。
• 评分取优，包括最差匹配：选择资源最宽松的节点，但会导致每个节点都有无法满足其他任务的资源碎片；最优匹配：先把一个节点的资源用满，在选择其他节点。

四、分布式调度 - 两层调度
解决单体调度的性能瓶颈，部署在节点集群中的一层负责收集资源信息，并同步给二层，二层和业务部署在一起，二层来根据资源和任务进行节点选择，选择的节点和任务再下发给一层，由一层下发给执行节点。
1、Apache Mesos：每个集群只有一个Master节点，用于管理Slave节点。并对接上层框架（如Hadoop）。

• Master进程收集所有节点信息并上报给注册的上层框架，上层框架进行任务调度，并将匹配结果下发给Master，由Master转发给执行器。
• 调度算法：最大最小公平算法：兼顾公平的同时尽可能让更多人满足资源分配。主导资源公平算法：考虑公平性的前提下考虑任务具体需求（CPU密集任务主要用CPU，内存密集型任务主要用内存）

五、分布式调度 - 共享状态调度
基于单体调度模式，分解为多个调度器，每个调度器都有全局的资源信息。解决了单体调度的瓶颈问题，解决了两层调度的无法匹配最优解，但存在资源冲突的问题且实现复杂。如Google Omega。

一、分布式互斥
多个请求只有第一个可以取得资源，其他请求需要等待资源释放，这种资源称为临界资源。
1、霸道总裁式：引入一个协调者，先来先得。简单高效，但可用性低。适用于协调者可靠性和性能有一定保障的前提下的广泛场景。
2、民主协商式：征得其他请求同意后使用临界资源。可用性高，但复杂度高、通信成本高。适用于系统规模小且资源使用频率低。
3、轮值CEO（令牌环）：所有参与者为一个环，轮流使用。单个参与者通信效率高可用性高，但当参与者使用频率低时有较多的无用通信。适用于系统规模小且每个程序使用资源频率高时间短。

二、分布式选举
分布式系统中多节点选举出有一个主，负责数据同步，保持各节点的一致性。本质上选举问题就是传统的分布式共识方法，主要是基于多数投票策略实现的。
1、Bully：节点ID最大的的为leader。易于实现复杂度低，但信息存储量大且频繁易主。适用小规模场景如MongoDB集群。
2、Raft：少数服从多数。速度快复杂度低，但系统需要全链且通信量大。适用于中小规模场景如k8s集群三节点选举。
3、ZAB：倾向于数组最新或节点ID最大的作为主。性能高无环境特殊需求，但选举时间长复杂度高。适用于大规模分布式场景如Zookeeper

三、分布式共识 - 求同存异
基于多数投票策略的分布式选举方法，用于分布式在线记账一致性问题中，那么记账权通常会完全掌握到主节点的手里，这使得主节点容易造假且存在性能瓶颈。分布式在线记账，是指没有集中的发行方（银行），任意一台电脑都能参与买卖，所有看到该交易的服务器都可以记录这笔交易，并且记录信息最终都是一致的，以保证交易的准确性。如区块链技术。
共识描述的是达成一致的过程，一致性强调的是结果。
1、PoW：按劳分配，每节点靠算力竞争记账权。相对公平、有容错、去中心，但不适合私有链、共识效率低、交易服务费高。如比特币。
2、PoS：由系统权益代替算力决定区块记账权的共识机制，权益越大越容易。资源消耗低、服务费低、达成共识周期短，但交易量较低、容易垄断、无法处理分叉连。如以太坊、点点币。
3、DPoS：解决PoS垄断问题，由持币人进行投票选出一个节点作为代表来参与竞争。能耗低、交易量高、无垄断、服务费低，但持币人投票积极性不高、故障解决效率低。如太股、EOS等。

四、分布式事务
ACID：原子性、一致性、隔离性、持久性。强调的是强一致性。即刚性事务。
BASE：基本可用（Basically Available）、柔性状态、最终一致性。弱化后ACID，强调的是最终一致性。即柔性事务。
1、基于XA的二阶段提交协议：一个中央协调者，先把请求发给各节点，节点处理完毕后返回YES/NO；各节点都返回YES时，协调者发送提交请求。强一致性、同步执行、简单，但同步阻塞、单点故障、性能低、数据不一致问题。
2、三阶段提交协议：引入了超时机制，二阶段中间增加了准备机制，解决了同步阻塞和单点故障问题。强一致性、同步执行、无同步阻塞、无单点故障，但性能低、数据不一致。
3、基于分布式消息的最终一致性：事务通过消息或日志来异步执行，通过业务规则进行业务重试，增加多种中间状态，如已下单未付款、已付款商家未确认等。先请求MQ，MQ执行下单；再请求MQ、MQ执行库存；再请求MQ、MQ执行通知仓储。最终一致性、异步执行、无同步阻塞、无单点故障、高性能，但算法复杂度高。

五、分布式锁
1、数据库：创建一张锁表。容易理解，但单点故障、死锁问题、性能低、可靠性低。适用于性能和并发量低的场景。
2、redis缓存：通过setnx实现，并设置过期时间。性能高、有集群、易于实现，但可靠性不如Zookeeper、锁失效时间的控制不稳定。适用于高并发、高性能的场景。
3、ZooKeeper：对应的持久节点目录下为每个进程创建临时顺序节点，每个节点确定编号是否最小，最小编号获得锁，否则等待。无单点、无不可重入、无死锁、解决数据库锁和缓存锁的不足、可靠性高、易于实现，但性能不如内存缓存式高、难以理解。适用于大部分场景，但不适合极高性能要求的场景。