1.ResourceManager（RM）
yarn的资源控制框架的中心模块，负责集群中所有的资源的统一管理和分配。
包含调度器和应用管理器
2.调度器（ResourceScheduler）
根据各个应用程序的资源需求，进行分配。
3.应用管理器（Applications Manager）
负责监控或跟踪AM的执行状态
4.NodeManager（NM）
是ResourceManager每台机器上的代理，负责容器的管理，并监控他们的资源使用情况（CPU，内存，磁盘，网络等等），以及向RM提供这些资源的使用汇报
5.ApplicationMaster（AM）
yarn中每个应用都会启动一个AM，负责向RM申请资源。请求NM启动container，并告诉container需要做什么。
6.container
这是一个虚拟的概念
yarn中所有应用都是在container之上运行的，包括ApplicationMaster
（1）container是yarn中资源的抽象，它封装了某个节点上一定的资源（CPU，内存，磁盘，网络等等）
（2）container由AM向RM申请，由RM中的ResourceScheduler分配给AM
运行AM的container、运行各类任务的container，由AM向RM申请的
MapReduce on yarn
1.client向RM提交应用程序，其中包括
AM主程序，启动AM的命令，用户的程序（如wordcount）
2.RM为该应用分配第一个container，并与NM通信，要求NM在这个container中启动AM
3.AM首先向RM注册，这样用户可以直接通过RM来查看程序的运行状态
4.AM通过RPC协议向ResourceScheduler申请资源
5.一旦AM申请到了资源，与NM通信，要求NM启动任务
6.NM为任务设置好运行环境（环境变量，jar包等），将任务的启动命令写到一个脚本中，并通过脚本触发启动任务
7.各个container的Task（Map Task，Reduce Task），通过RPC向AM进行进度和状态汇报，以便AM随时可以掌握任务的运行状态，失败的时候，也会重启container任务
8.应用程序运行完成后，AM会向RM申请注销和关闭
1-4.启动ApplicationMaster，领取资源
5-8.运行任务，直到任务完成
Scheduler理想情况下，我们应用对yarn资源的请求应该立刻被满足，但是实际上，资源有限。特别是很忙的集群。
yarn中负责分配资源的就是Scheduler
调度本身就是一个大难题，很难找到完美的解决方案，所以yarn提供了三种调度器
1.FIFO Scheduler
FIFO = first in first out 队列
这种调度器把应用提交按顺序排成-一个队列，先进先出的队列，在进行资源分配的时候，先给队列中最头部的应用非配资源等到应用满足了，再给下一-个分配，以此类推。
问题:大的应用可能会占用所有的资源，造成阻塞，不适合集群
2.Capacity Scheduler
专门有一个队列来运行小任务，但是为小任务专门设置的队列会占用一定的集群资源，导致大任务的执行时间会落后与FIFO
3.Fair Scheduler
不需要预先占用一定资源，会动态调整
比如第一 个是大任务，且只有这个大任务在运行，那么把所有资源都给它，然后第二个小任务提交了，Fair Scheduler就会分配一半资源给小任务，公平的共享资源，小任务跑完了，还是会把所有资源给到大任务
默认是Capacity Scheduler。
作业1.进程和线程的区别
（1）定义不一样,进程是执行中的一段程序，而一个进程中执行中的每个任务即为一个线程
（2）一个线程只可以属于一个进程，但一个进程能包含多个线程
（3）线程无地址空间，它包括在进程的地址空间里
（4）线程的开销或代价比进程的小
2.Zookeeper
2.1作用
（1）命名服务
在zookeeper的文件系统里创建一个目录，即有唯一的path。在我们使用tborg无法确定上游程序的部署机器时即可与下游程序约定好path，通过path即能互相探索发现。
（2）配置管理
程序总是需要配置的，如果程序分散部署在多台机器上，要逐个改变配置就变得困难。好吧，现在把这些配置全部放到zookeeper上去，保存在 Zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中就好。
（3）集群管理
所谓集群管理无在乎两点：是否有机器退出和加入、选举master。
对于第一点，所有机器约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。新机器加入 也是类似，所有机器收到通知：新兄弟目录加入，highcount又有了。
对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master就好。
（4）分布式锁
有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。厕所有言：来也冲冲，去也冲冲，用完删除掉自己创建的distribute_lock 节点就释放出锁。
对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。
（5）队列管理
两种类型的队列：
1、 同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。
2、队列按照 FIFO 方式进行入队和出队操作。
2.2有几种角色？分别有什么作用
有三种角色：群首（leader），追随者（follower），观察者（observer）。
Leader服务器为客户端提供读服务和写服务。
Follower服务器为客户端提供读服务，参与Leader选举过程，参与写操作“过半写成功”策略。
Observer服务器为客户端提供读服务，不参与Leader选举过程，不参与写操作“过半写成功”策略。
2.3 有几种状态？分别是什么？
ZooKeeper 服务器有四种工作状态：
（1） LOOKING：寻找 Leader 状态。当服务器处于该状态时，它会认为当前服务器没有 Leader，因此需要进入 Leader 选举状态。
（2）FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。
（3） LEADING：领导者状态。表明当前服务器角色是 Leader。
（4） OBSERVING：观察者状态。表明当前服务器角色是 Observer。
2.4选举流程和选举算法
选举流程：
（1）每个server发起一个投票
（2）接受到其他服务端实例发来的选票
（3）校验处理选票
（4）统计每一次选票
（5）同步服务端实例状态
选举算法：
在zookeeper中，提供了三种Leader选举的算法，分别是LeaderElection、UDP版本的FastLeaderElection以及TCP版本的FastLeaderElection三种选举算法。而选举算法，则是可以在zoo.cfg配置文件中的electionAlg属性来指定，这三种选举算法分别对应值为0-3，其中0为LeaderElection算法，使用的是UDP协议实现，1代表UDP版本的FastLeaderElection算法，这种算法是非授权模式，2代表的也是UDP版本的FastLeaderElection算法，不过这种使用的是授权模式，3代表是TCP协议实现的FastLeaderElection算法。
3.SQL
4.spu、sku、pv、uv的意思
spu在商品管理中通常被解释为“Standard Product Unit ”，即“标准产品单元”，是指商品基本属性一致的同一组商品。
sku的标准解释是“Stock Keeping Unit”，即最小库存单位的意思。
pv代表访问量，英文全称Page View，即页面访问量，每打开一次页面PV计数+1，刷新页面也是。
uv代表访问数，英语全称Unique Visitor，是指独立访客访问数，一台电脑终端为一个访客。
