Master/Slave分布式计算模式

在分布式系统中，一个比较常用的计算结构就是Master/Slave模式。简单来说，Master/Slave与进程与线程的关系类似，在这个结构中，由一台机器作为Master，其他机器作为Slave，因为这些计算单元同时工作，所以也就出现了“集群”的概念。Master作为任务调度者，给多个Slave分配计算任务（Map），最后由Master汇集结果（Reduce），这其实也MapReduce思想所在。

Master负责读写请求，即资源调度。真正处理数据的是Slave.

Yarn和Standalone的区别和联系

1. Yarn和Standalone都是集群资源管理器，Standalone符合意思的翻译应该是“独立”而不是“单机”。
2. Yarn和Standalone都是基于zookeeper的，也是有master/salve结构。
3. Standalone模式下，资源调度归程序所有，如spark集群的Standalone模式。而spark的Yarn模式，资源调度归Yarn所有。这也就是“独立”的意思，看资源调度是否归程序自己拥有。
   1. Spark的Standalone模式下，需要构建一个由Master+Slave构成的Spark集群，Spark运行在集群中。 分布式部署集群，自带完整的服务，资源管理和任务监控是Spark自己监控，这个模式也是其他模式的基础。
   2. Spark on Yarn模式下，Spark客户端直接连接Yarn，不需要额外构建Spark集群。 分布式部署集群，资源和任务监控交给yarn管理，但是目前仅支持粗粒度资源分配方式，包含cluster和client运行模式，cluster适合生产，driver运行在集群子节点，具有容错功能，client适合调试，dirver运行在客户端。

zookeeper与yarn的区别和联系

参考https://www.nndev.cn/archives/669
zookeeper和Yarn都有着管理的功能，很容易让人混淆。因此要明白它俩是为了解决什么问题而产生的，应用场景分别是什么，如何结合使用等等问题。

总的来说：YARN是从资源分配和调度的角度进行集群的管理，Zookeeper则干别的事情：作为一个中心配置服务，维护配置信息、名称服务、分布式同步、组服务等。Zookeeper本身也是一个有着3、5个节点的集群，它并不管理其他集群，从表面上看像个数据库，允许读写，并保持一致性的。所以Yarn和Standalone也是基于zookeeper来实现__相关功能的。

先看YARN的架构图：

第一步：客户端提交任务(MapReduce, Java应用，Apache Spark任务等)到ResourceManager，同时传递一个命令，用于在NodeManager节点中启动任意一个container来运行ApplicationMaster；
第二步：Master节点上的ApplicationManager验证Job请求，然后传递给Scheduler进程进行资源分配；
第三步：Scheduler进程从某个Slave节点分配一个container来运行ApplicationMaster；
第四步: NodeManager后台进程在其中一个container中启动ApplicationMaster，使用第一步传递过来的命令。ApplicationMaster于是成为了任何应用的第一个container；
第五步: ApplicationMaster将数据的位置(如保存着哪个Slave节点上)、所需CPU、内存量等信息提供给ResourceManager，与其协商如何分配其他container；
第六步: ReourceManager在Slave节点中进行最合理的资源分配，然后将节点详细信息等返回给ApplicationMaster；
第七步: 然后，ApplicationMaster将请求(如建议在哪个Slave上启动container)发给NodeManagers；
第八步: ApplicationMaster管理所请求container运行时的资源使用情况，并在任务完成后通知ResourceManager；
第九步: NodeManagers周期性地将自身的状态(如可使用资源情况)通知ResourceManager，作为Scheduler在集群中协调新应用的依据；
第十步: 任意一个Slave节点失败时，ResourceManager会试图在一个最合适的Slave节点上分配一个新的container，这样ApplicationMaster可使用新的container继续工作下去；
再看另一张图：

可以看到，HDFS是分布式存储，YARN是资源管理器，MapReduce等一些东西属于处理框架。有童鞋不禁要问了，如果没有YARN，Hadoop还能转吗？当然了，YARN是Hadoop V2才引入的，Hadoop V1的时候，通过JobTracker和TaskTracker来协调资源，然而人们发现，JobTracker做了太多的事情，以致于它快撑不住。怎么办呢，刚刚好，YARN过来拯救它了。更具体的，还是建议去对比下Hadoop不同版本的架构图。
上面这张图里没有Zookeeper，Zookeeper又是干嘛的呀？我从这里看到一些解释，感觉蛮不错，翻译过来大意就是：

因此，YARN是从资源分配和调度的角度进行集群的管理，Zookeeper则干别的事情：作为一个中心配置服务，维护配置信息、名称服务、分布式同步、组服务等。Zookeeper本身也是一个有着3、5个节点的集群，它并不管理其他集群，从表面上看像个数据库，允许读写，并保持一致性的(从CAP的角度看，它是一个CP系统)。 那么它们的关系就是： YARN本身使用了一个HA的变种，在这个HA的设置中，自动故障处理(Automatic failover，包含选主) 是通过Zookeeper来实现的。那这个自动故障处理是如何通过Zookeeper工作的呢？(我们假设不局限于YARN，可以是其他的集群)：你可以想象，在Zookeeper中，有一项信息“what yarn nodes are there”，答案也许是0(糟，挂掉了)、1(OK，起来了)、2(不错，现在列表中的第一个节点是YARN Master，另外一个节点作为Standby，等待Failover，平时它就从Master节点同步更新的信息)。这只是关于选主的一个例子：节点列表中的第一个节点作为Master。可见，Zookeeper为分布式系统提供了一个分布式配置服务，一个同步服务和一个名字注册表，很多后台daemons(包括YARN)使用它来管理多节点以实现集群的高可用。

_

单机、集群(cluster)、高可用(HA)

以flink为例，spark等服务是一致，概念类似。
flink中有jobmanager和tastmanager的概念，jobmanager用来资源调度，taskmanager用来执行具体的tasks。
单机：一台服务器，安装一个flink，配置一个jobmanager和至少一个taskmanagert
集群：多台服务器，分别安装一个flink，其中一台机器配置一个jobmanager，其他机器配置至少一个taskmanager，每台机器上的三个文件要一致：conf/masters、conf/slaves、conf/flink-conf.yaml
高可用：使用zookeeper搭建集群，这样就有多个jobmanager和多个taskmanager了