在前两篇中，咱们通过官网的example体验了livy的性能，留下了一个疑难，到底livy是如何做到的呢？这一篇从源码外面找一下答案。

在间接剖析源码前，先把论断通过时序图画进去，有个直观的映像：

  1. 客户端创立session，LivyServer收到申请后启动一个RpcServer。RpcServer会程序抉择一个从10000~10010之间的可用端口启动监听，假如此时是10000。
  2. LivyServer随后通过SparkSubimit提交Application。Application在远端，最终会启动RSCDrvier。
  3. RSCDrvier首先也从10000~10010之间程序抉择一个可用的端口，启动RpcServer。图中打出了要害的日志，第二篇中已经提到过这个日志。
  4. RSCDrvier实现bind后，反向连贯到LivyServer端的RpcServer。图中打出了要害的日志，第二篇中同样提到过。
  5. RSCDrvier次要向LivyServer所在的RpcServer上报本人bind的端口和ip。这一步其实就是最要害的步骤。
  6. RpcServer收到申请后将RSCDrvier的端口和ip封装成ContextInfo返回给LivyServer。同时敞开RpcServer。
  7. LivyServer通过RSCDrvier的端口和ip连贯到RSCDriver，从而实现tcp连贯。至此session建设实现

以上就是简化的外围工作原理，能够通过netstat证实一下网络连接关系。vm3198是livyServer，vm3196是driver所在机器

下图是driver上的相干连贯：

能够看到driver启用了10000端口的监听

下图是livyServer上的相干连贯：

能够看到livyServer有一条连贯到driver的链路，端口是能够对应上的

读者可能留神到，这里Driver的监听端口并不是10001，而是10000。这是因为尽管livyServer会率先占用10000，但因为Driver与livyServer不在一台机器上，所以对于Driver来说，10000过后并没有被占用，所以就应用10000端口了

留神到，咱们在livyServer上并没有找到10000端口的监听。这是因为，一旦driver将本人的地址回发过来（通过回发RemoteDriverAddress音讯），livyServer的Rpc监听就敞开了。

读者可能会思考，RSCDrvier是如何晓得livyServer的Rpc监听端点的呢？答案在启动Spark工作时上送的配置文件，咱们摘取其中要害的配置项：

spark.__livy__.livy.rsc.launcher.address=vm3198spark.__livy__.livy.rsc.launcher.port=10000

launcher.address/port；就是livyServer启动的Rpc监听端点。从RSCDriver的源码能够看到，程序从配置文件中读取了信息：

...// Address for the RSC driver to connect back with it's connection info.LAUNCHER_ADDRESS("launcher.address", null)LAUNCHER_PORT("launcher.port", -1)...String launcherAddress = livyConf.get(LAUNCHER_ADDRESS);int launcherPort = livyConf.getInt(LAUNCHER_PORT);...LOG.info("Connecting to: {}:{}", launcherAddress, launcherPort);

总结

本篇咱们探索了livy的外围工作机制，理解了建设session时，在livyServer和Driver之间是如何建设连贯关系的。更多对于rpc通信的细节有机会还会再基于源码具体开展剖析