在上篇 spark 源码分析之五 -- Spark内置RPC机制剖析之一创建NettyRPCEnv 中，涉及到了Diapatcher 内容，未做过多的剖析。本篇来剖析一下它的工作原理。
Dispatcher 是消息的分发器，负责将消息分发给适合的 endpoint
其实这个类还是比较简单的，先来看它的类图：
我们从成员变量入手分析整个类的内部构造和机理：
1. endpoints是一个 ConcurrentMap[String, EndpointData]， 负责存储 endpoint name 和 EndpointData 的映射关系。其中，EndpointData又包含了 endpoint name， RpcEndpoint 以及 NettyRpcEndpointRef 的引用以及Inbox 对象（包含了RpcEndpoint 以及 NettyRpcEndpointRef 的引用）。
2. endpointRefs: ConcurrentMap[RpcEndpoint, RpcEndpointRef] 包含了 RpcEndpoint 和 RpcEndpointRef 的映射关系。
3. receivers 是一个 LinkedBlockingQueue[EndpointData] 消息阻塞队列，用于存放 EndpointData 对象。它主要用于追踪 那些可能会包含需要处理消息receiver（即EndpointData）。在post消息到Dispatcher 时，一般会先post 到 EndpointData 的 Inbox 中， 然后，再将 EndpointData对象放入 receivers 中，源码如下：
// Posts a message to a specific endpoint.
private def postMessage(
endpointName: String,
message: InboxMessage,
callbackIfStopped: (Exception) => Unit): Unit = {
val error = synchronized {
// 1. 先根据endpoint name从路由中找到data
val data = endpoints.get(endpointName)
if (stopped) {
Some(new RpcEnvStoppedException())
} else if (data == null) {
Some(new SparkException(s"Could not find $endpointName."))
} else {
// 2. 将待消费的消息发送到 inbox中
data.inbox.post(message)
// 3. 将 data 放到待消费的receiver 中
receivers.offer(data)
None
}
}
// We don't need to call `onStop` in the `synchronized` block
error.foreach(callbackIfStopped)
}
4. stopped 标志 Dispatcher 是否已经停止了
5. threadpool 是 ThreadPoolExecutor 对象， 其中的 线程的 core 数量的计算如下：
val availableCores = if (numUsableCores > 0) numUsableCores else Runtime.getRuntime.availableProcessors()val numThreads = nettyEnv.conf.getInt("spark.rpc.netty.dispatcher.numThreads", math.max(2, availableCores))
获取到线程数之后， 会初始化 一个固定的线程池，用来执行 MessageLoop 任务，MessageLoop 是一个Runnable 对象。它会不停地从 receiver 堵塞队列中， 把放入的 EndpointData对象取出来，并且去调用其inbox成员变量的 process 方法。
6. PoisonPill 是一个空的EndpointData对象，起了一个标志位的作用，如果想要停止 Diapatcher ，会把PoisonPill 喂给 receiver 吃，当threadpool 执行 MessageLoop 任务时， 吃到了毒药，马上退出，线程也就死掉了。PoisonPill命名很形象，关闭线程池的方式也是优雅的，是值得我们在工作中去学习和应用的。
从上面的成员变量分析部分可以知道，数据通过 postMessage 方法将 InboxMessage 数据 post 到 EndpointData的Inbox对象中，并将待处理的EndpointData 对象放入到 receivers 中，线程池会不断从这个队列中拿数据，分发数据。
引出Inbox
其实，data 就包含了 RpcEndpoint 和 RpcEndpointRef 对象，本可以在Dispatcher 中就可以调用 endpoint 的方法去处理。为什么还要设计出来一个 Inbox 层次的抽象呢？
下面我们就趁热剖析一下 Inbox 这个对象。
Inbox剖析
Inbox 的官方解释：
An inbox that stores messages for an RpcEndpoint and posts messages to it thread-safely.
其实就是它为RpcEndpoint 对象保存了消息，并且将消息 post给 RpcEndpoint，同时保证了线程的安全性。
类图如下：
跟 put 和 get 语义相似的有两个方法， 分别是post 和 process。其实这两个方法都是给 Dispatcher 对象调用的。post 将数据 存放到 堵塞消息队列队尾， pocess 则堵塞式 从消息队列中取出数据来，并处理之。
这两个关键方法源码如下：
def post(message: InboxMessage): Unit = inbox.synchronized {
if (stopped) {
// We already put "OnStop" into "messages", so we should drop further messages
onDrop(message)
} else {
messages.add(message)
false
}
}
/**
* Calls action closure, and calls the endpoint's onError function in the case of exceptions.
*/
private def safelyCall(endpoint: RpcEndpoint)(action: => Unit): Unit = {
try action catch {
case NonFatal(e) =>
try endpoint.onError(e) catch {
case NonFatal(ee) =>
if (stopped) {
logDebug("Ignoring error", ee)
} else {
logError("Ignoring error", ee)
}
}
}
}
/**
* Process stored messages.
*/
def process(dispatcher: Dispatcher): Unit = {
var message: InboxMessage = null
inbox.synchronized {
if (!enableConcurrent && numActiveThreads != 0) {
return
}
message = messages.poll()
if (message != null) {
numActiveThreads += 1
} else {
return
}
}
while (true) {
safelyCall(endpoint) {
message match {
case RpcMessage(_sender, content, context) =>
try {
endpoint.receiveAndReply(context).applyOrElse[Any, Unit](content, { msg =>
throw new SparkException(s"Unsupported message $message from ${_sender}")
})
} catch {
case e: Throwable =>
context.sendFailure(e)
// Throw the exception -- this exception will be caught by the safelyCall function.
// The endpoint's onError function will be called.
throw e
}
case OneWayMessage(_sender, content) =>
endpoint.receive.applyOrElse[Any, Unit](content, { msg =>
throw new SparkException(s"Unsupported message $message from ${_sender}")
})
case OnStart =>
endpoint.onStart()
if (!endpoint.isInstanceOf[ThreadSafeRpcEndpoint]) {
inbox.synchronized {
if (!stopped) {
enableConcurrent = true
}
}
}
case OnStop =>
val activeThreads = inbox.synchronized { inbox.numActiveThreads }
assert(activeThreads == 1,
s"There should be only a single active thread but found $activeThreads threads.")
dispatcher.removeRpcEndpointRef(endpoint)
endpoint.onStop()
assert(isEmpty, "OnStop should be the last message")
case RemoteProcessConnected(remoteAddress) =>
endpoint.onConnected(remoteAddress)
case RemoteProcessDisconnected(remoteAddress) =>
endpoint.onDisconnected(remoteAddress)
case RemoteProcessConnectionError(cause, remoteAddress) =>
endpoint.onNetworkError(cause, remoteAddress)
}
}
inbox.synchronized {
// "enableConcurrent" will be set to false after `onStop` is called, so we should check it
// every time.
if (!enableConcurrent && numActiveThreads != 1) {
// If we are not the only one worker, exit
numActiveThreads -= 1
return
}
message = messages.poll()
if (message == null) {
numActiveThreads -= 1
return
}
}
}
}
其中，InboxMessage 继承关系如下：
这些InboxMessage子类型在process 方法源码中有体现。其中OneWayMessage和RpcMessage 都是自带消息content 的，其他的几种都是消息事件，本身不带任何除事件类型信息之外的信息。
在process 处理过程中，考虑到了 一次性批量处理消息问题、多线程安全问题、异常抛出问题，多消息分支处理问题等等。
此时可以回答上面我们的疑问了，抽象出来 Inbox 的原因在于，Diapatcher 的职责变得单一，只需要把数据分发就可以了。具体分发数据要如何处理的问题留给了 Inbox，Inbox 把关注点放在了 如何处理这些消息上。考虑并解决了 一次性批量处理消息问题、多线程安全问题、异常抛出问题，多消息分支处理问题等等问题。
Outbox
下面看一下Outbox， 它的内部构造和Inbox很类似，不再剖析。
OutboxMessage的继承关系如下：
其中，OneWayOutboxMessage 的行为是特定的。源码如下：
它没有回调方法。
RpcOutboxMessage 的回调则是通过构造方法传进来的。其源码如下：
RpcOutboxMessage 是有回调的，回调方法通过构造方法指定，内部onFailure和onSuccess是模板方法。