InfoQ深入浅出Spark（三）：Spark调度系统之“权力的游戏”( 九 )

在第 14 步中，拜老板将每个 TaskDescription 通过 LaunchTask 消息分发到与其对应的 Executor 中，众小弟在接收到老板的 LaunchTask 消息后立即调用 Executor 的 launchTask 方法开始干活。 launchTask 首先把 TaskDescription 封装为 TaskRunner（TaskRunner 实现了 Java Runnable 接口，用于多线程并发），随即将封装好的 TaskRunner 交由 Executor 线程池，线程池则调用 TaskRunner 的 run 方法来执行任务。 Java 并发编程规范提供了多种线程池支持，例如 newFixedThreadPool、newCachedThreadPool ， Spark Executor 的实现选择了后者。
不同的线程池有不同的应用场景，不同开发者对于不同的线程池也有自己的理解和偏好，不过，采用线程池来实现高并发的特性是没什么太多争议的。抛开不同线程池的优劣对比不谈，咱们重点来说说 TaskRunner 的 run 方法都做了哪些事情。
首先， TaskRunner 先对 TaskDescription 中的 serializedTask 进行反序列化得到 Task；然后，为该 Task 指定内存管理器 MemoryManager ， MemoryManager 维护一个 Executor 中所有 Tasks 的内存占用以及回收情况。接着调用 Task 的 run 方法来执行任务并获取任务结果， TaskRunner 最终将任务结果封装为 DirectTaskResult 或 IndirectTaskResult 并通过调用 ExecutorBackend 的 statusUpdate 方法将执行状态和结果返回。
到此为止，任务提交阶段的调度与执行就走完了，不过，结束即开始，一个阶段的终结意味着另一个阶段的开始， statusUpdate 以相反的方向、沿着权力越来越集中的方向一路北上，直到触达权力的最核心。 statusUpdate 的整条调用路径会涉及 ExecutorBackend 的 statusUpdate 方法、SchedulerBackend 处理 StatusUpdate 消息、SchedulerBackend 尝试 makeOffers、TaskScheduler 的 statusUpdate 方法、TaskResultGetter 的 enqueue(Successful/Failed)Task 方法、TaskScheduler 的 handleTaskGettingResult 方法、最终调用到 TaskSetManager 的 handleTaskGettingResult 方法， TaskSetManager 在对任务状态进行维护之后随即通过调用 DAGScheduler 的 taskGettingResult 通知 DAGScheduler 获取任务结果。
鉴于篇幅的限制， statusUpdate 代码调用的完整路径以及路上发生的故事，咱们就不再详细展开了，这块留给感兴趣的看官们去深入探索（笔者厚着脸皮赤裸裸地准备开始偷懒了 [允悲]）。

本文插图
任务提交代码调用流程图 —— Executor 内部调用Postscript本篇是《深入浅出 Spark：原理详解与开发实践》的第三篇，笔者学浅才疏、疏漏难免。如果您有任何疑问，或是觉得文章中的描述有所遗漏或不妥，欢迎在评论区留言、讨论。掌握一门技术，书本中的知识往往只占两成，三成靠讨论，五成靠实践。更多的讨论能激发更多的观点、视角与洞察，也只有这样，对于一门技术的认知与理解才能更深入、牢固。
在本篇博文中，我们先通过虚构的斯巴克国际建筑集团公司以及公司里的各位大佬介绍了 Spark 调度系统中的主要角色：DAGScheduler、TaskScheduler 和 SchedulerBackend ，然后通过派系的划分和立场带出了辅佐三位大佬的各种秘书、助手如 EventProcessLoop、SchedulableBuilder、TasSetManager、ExecutorBackend 等等。 Spark 调度系统中涉及的对象、角色多如繁星，笔者反复思考如何以更好的方式把他们之间复杂而微妙的联系说清楚，真心希望斯巴克国际建筑集团公司“权力争斗”的故事能帮您更好地理解 Spark 调度系统。
如果您觉得斯巴克公司的类比过于牵强亦或是哪里用力过猛，欢迎您随时拍砖，更欢迎您一起讨论从而让故事的逻辑更加自洽。在后续的专栏文章中，我们会继续对 Spark 的核心概念与原理进行探讨，尽可能地还原 Spark 分布式内存计算引擎的全貌。