02Master启动流程
2.1MasterServer的启动
在正式开始前，笔者想先鼓励一下大家。我们知道启动Master其实就是启动MasterServer，本质上与其他SpringBoot项目相似，即启动里面的main函数。但想要开始实操前，肯定有不少的人，尤其是初学者会突然发现这里面有十多个由bean注入的autowired。
被多个bean的注入搞到一头雾水，甚至感觉一脸懵逼的不是少数。但笔者就想说是，这些其实都是吓唬你们的，不用害怕，接下来将带领你们把这些bean分别解剖并归类，那么我们就正式开始。
第一类：MasterConfig、MasterRegistryClient、MasterSchedulerService、Scheduler这些bean。从字面意思来说，MasterConfig就是跟Master配置相关的，MasterRegistryClient就是负责注册相关的内容，MasterSchedulerService肯定跟Master调度有关的，说白了就是Master内部的东西。
第二类：是那些后缀名为一堆Processor的，例如taskExecuteRunningProcessor等。相同后缀一定处理同样的task，在以后肯定被某个东西一起加载的。
第三类：是EventExecuteService以及FailoverExecuteThread，这些根据名字可以大胆猜一下是与事件执行相关以及灾备转换相关的东西，这些肯定也是Master内部的东西，理论上应该归到第一类。
第四类：至于LoggerRequestProcessor就是与打印日志相关的了，至于这类具体干的内容，后面会有详细的介绍。
main方法执行完成后，基于spring特性，执行run方法。在run方法中，创建nettyRemotingServer对象(这个对象不是spring管理的，而是直接new创建的)。然后将第二类的一堆Processor放到netty的Processor里面去。从这里就可以推断，Master和Worker的通信一定是通过netty的。
我们可以看看下面的代码，其实就是将第一类的那些bean执行init以及start方法。
总结其实Master这就像一个总司令，这个总司令就调用这里面的bean的start方法，这些bean开始执行自己的功能，至于这些bean里面执行啥样的功能，MasterServer是懒得管，也没必要管了。
本节总结：
至此MasterServer就运行完了，下一节我们将逐个分析各个bean的用途以及功能的了。
2.2MasterConfig的信息以及MasterRegistryClient的注册
MasterConfig从application.yml中获取配置信息加载到MasterConfig类中，获取到的具体配置信息如下。
在MasterServer里，MasterRegisterConfig会执行init()以及start()方法。
init()方法新建了一个心跳线程池。注意，此时只是建了一个线程池，里面还没有心跳任务。
start()方法从zk获取了锁(getLock)，注册信息(registry)以及监听注册的信息(subscribe)。
注册信息做了两件事情：
第一：构建心跳信息，并丢到线程池中运行心跳任务的。
第二：在zk临时注册该Master信息，并移除没用的Master信息。
心跳任务就是检查是否有死亡节点以及每隔10s(heartbeatInterval)将最新的机器信息，包括机器CPU，内存，PID等等信息注册到zk上去的。
监听订阅的信息，只要注册的信息有变化，就会立马感知，如果是增加了机器，则会打印日志。减少了机器，移除并同时打印日志。本节如下图所示:
2.3ServerNodeManger的运行
前面两节是从MasterServer启动过程以及MasterRegisterConfig的注册过程的。注册完成之后Master，Worker如何管理呢，如何同步保存到数据库的呢。ServerNodeManager的作用就是负责这一部分的内容。
ServerNodeManager实现了InitializingBean接口的。基于spring的特性，构建此对象后，会执行AfterPropertiesSet()方法。做了三件事情：
load()。从zk加载节点信息通过UpdateMasterNodes()到MasterPriorityQueue。
新建线程每十秒钟将zk的节点信息同步数据到数据库中。
监听zk节点，实时把最新数据通过UpdateMasterNodes()方法更新到MasterPriorityQueue队列中去。
几乎所有的更新操作都是通过重入锁来实现的，这样就能确保多线程下系统是安全的。此外，还有一个细节是如果是移除节点会发送警告信息。
MasterProrityQueue里面有个HashMap，每台机器对应一个index，以这样的方式构建了槽位。后面去找Master信息的时候就是通过这index去找的。
至于MasterBlockingQueue队列的内容，如何同步到数据库的，如何将数据放到队列和队列中移除数据等，这些都是纯crud的内容，读者可以自行阅读的。
2.4MasterSchedulerService的启动
2.1到2.3讲述都是由zk管理的节点信息的事情。为什么我们要在Master启动之后会先讲节点信息的？
理由其实很简单，因为不管是Master还是Worker归根结底都是机器。如果这些机器崩了或者增加了，DS不知道的话，那这机器岂不是浪费了。只有机器运行正常，配置正常，都管理好了，那DS运行才能够顺畅地运行。同样，其他大数据组件也是类似的道理。
前面MasterServer里MasterRegisterClient执行完init()以及start()方法之后，紧接着MasterSchedulerService执行了init()和start()方法。从这里开始就真正的进入了Master干活的阶段了。
init()方法是创建了一个Master-Pre-Exec-Thread线程池以及netty客户端的。
Pre-exec-Thread线程池里面有固定的10个线程(在2.1中对应的是MasterConfig配置里面的pre-exec-threads)。这些线程处理就是从