在spark内部，rpc可以用来实现不同组件（Driver， executor，client）之间的远程交互。而在同一组件内，spark还有事件监听机制，如spark中各种指标的采集主要就是通过事件监听机制获取的。另外，本文也会spark中metrics的采集过程做一个简要分析。
1，spark事件监听机制
spark的事件监听主要是通过总线机制将不同的监听事件和 事件监听器连接起来的。总体设计如下图所示：
SparkListenerEvent具体包含的事件很多,如SparkListenerStageSubmitted，SparkListenerStageCompleted，SparkListenerTaskStart等等。
同理，SparkListenerInterface具体的实现也很多，如AppStatusListener，HeartbeatReceiver等。
下面以DAGScheduler中的JobSubmitted为例，梳理下整个过程：
1，在DAGScheduler处理JobSubmitted消息的函数在handleJobSubmitted中，在submitStage之前，会通过消息总线将SparkListenerJobStart监控事件发送到消息总线。
2，在LiveListenerBus内部，会将SparkListenerJobStart事件依次塞入到所有多列中（上图中的AsyncEventQueue中的Queue）。
3，与此同时，每个AsyncEventQueue中的Queue对应一个Thread，该线程将持续从队列中取出监听事件，将该事件发送给与该列队相连的所有事件监听器。
4，各个事件监听器根据不同的event类型，进行对应的处理。
以上就是事件响应处理的整体流程。
此外，还有一个问题是：监听器是怎么注册到消息总线内部的队列的？
以DAGScheduler中的ListenerBus为例，这个listenerbus是在SparkContext中初始化的，并且通过调用addToEventLogQueue，addToStatusQueue，addToManagementQueue，addToSharedQueue函数将各个监听器加入到不同的队列中去。
2， metrics实现机制
metrics实现机制和listener的机制有点类似，在spark的内部实现中，通过MetricsSystem连接Source和Sink。Source顾名思义就是收集数据的地方，而Sink则是采集数据落地的地方，Sink中一般而言会有一个Reporter周期性的将source采集的数据发送给sink，而MetricsSystem则可以简单理解为一个容器。
在SparkContext启动的时候，将会创建MetricSystem对象，并且在该对象启动的时候，将配置文件（默认metrics.properties）中的所有source和sink就注册到MetricsSystem中。对于Sink只能通过读取配置中所有sink，一次性注册。而对于Source，单独开放了接口，可以随时注册到MetricSystem中（在SparkContext中就有大量单独的source注册）。
对于source的具体实现，下面以BlockManagerSource为例简要阐述几点：
1，具体实现都实现了Source这个trait，实现Soure中定义的MetricRegistry和sourceName接口。
2，在Source中可以定义不同类型的metrics（Gauges，Counters，Meters，Histograms, Timers). 这些都是来自第三方的metrics库（https://github.com/dropwizard/metrics）。
3，在BlockManagerSource就定义了大量Gauge类型的metric。将name和value组成的kv值注册到MetricRegistry中。
而Sink中比较核心的就是有SchedulerReporter的对象（具体包括ConsoleReporter，CsvReporter，GraphiteReporter，JmxReporter），它会定期将source中采集的数据落到不同的目的地。
3， 小结
本文简要描述了spark中listener和metric的内部实现机制。metrics的实现了解有助于后续进一步对spark做数值类型的定制化监控。