图解spark-local模式运行原理
local部署模式
首先spark运行时有4个角色，如下：
Driver:应用驱动程序, 是spark集群的客户
Master：Spark的主控节点，是spark集群的老板
Worker：Spark的工作节点，是集群的各个节点主管
Executor：Spark的工作进程，由worker监管，负责具体任务的执行
简单local模式运行流程（无集群）
我们先看下启动任务前， driver和executor之间，简单发生了什么（注意local模式下，executor是在driverApp里面的）：
localBackend可以理解成1个客户端
localActore可以理解成1个消息处理器，在这里处理消息并调用对应对象的方法
可以看到启动前，需要先向集群中心申请资源，足够的时候才调用executor的launTask启动任务。
看下任务启动后，发生了什么：
可以看到executor会不断更新当前的任务运行状态，并发送出去做状态更新。
local-custer运行流程
和简单local相比，有如下区别：
多了master角色和worker角色。
看一下master的创建流程：
可以看到首先进行了master注册，即告知启动了一个master。
从图中可以看到几个关键点：
- 为了可靠性，master要选举出主备
- 为了主备能顺利切换，会做信息持久化。
- actorSystem会定期发消息通知master做检测。
即检测的定时器是在actorSytem中启动的，而不是master自身启动的。 （为什么呢，如果as挂了，不是所有的心跳检测都无法进行了吗？）
master对worker的离线检测机制
看一下master的离线检测机制：
可以看到是确认离线后，会设置worker状态为dead，并清理内存。
如果离线时的worker已经是dead状态，则会过一段时间才从检测列表中移除。
几个疑问点：
- 为什么发现worker状态为已DEAD时，要过几个周期才把worker从检测列表移除？（个人理解是防止worker恢复？但非dead离线的worker为什么是直接移除）
- 发现非DEAD的worker离线时，为什么是要告知driver。（个人理解是告知driver有worker异常，需要等待新的worker注册）
worker挂掉后具体发生了什么，等后面的容错机制会介绍。
worker的启动过程
可以看到以下几点：
- 每个worker有一个独立的工作目录，用于缓存数据等
- 启动后同样需要反过来注册到master。
- 会通过metricsSystem定期上报自己的状态给master
worker如何注册到master
里面黄色标签可以看到自己当时的疑问
为什么worker要先给自己发心跳，然后再转发给master。
书里没说，个人理解是为了自身能确认心跳线程是否因为异常情况导致中断，所以要先发给自己来确认心跳情况。
针对这个问题， 其实就是之前提到的， 如果超时了，master会把worker清除， 但后来又收到了心跳，则说明worker没挂，可能只是网络异常，此时会需要worker发送连接请求，重新注册到master
master和worker启动之后
可以看到master和worker启动完成后， 会启动一个客户端专门和application通信。
master如何处理regsiterApplication
关键点在于：
- 注册过程是为了在master这绑定appid和appadress的关系（local-clster是本地集群的，但如果是真实的集群，则会有多个appid，所以需要这个诸恶过程）
完整流程图