关于spark:Livy探究三-核心架构细节探索

27次阅读

共计 1647 个字符，预计需要花费 5 分钟才能阅读完成。

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

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

客户端创立 session，LivyServer 收到申请后启动一个 RpcServer。RpcServer 会程序抉择一个从 10000~10010 之间的可用端口启动监听，假如此时是10000。
LivyServer 随后通过 SparkSubimit 提交 Application。Application 在远端，最终会启动RSCDrvier。
RSCDrvier首先也从 10000~10010 之间程序抉择一个可用的端口，启动 RpcServer。图中打出了要害的日志，第二篇中已经提到过这个日志。
RSCDrvier实现 bind 后，反向连贯到 LivyServer 端的 RpcServer。图中打出了要害的日志，第二篇中同样提到过。
RSCDrvier次要向 LivyServer 所在的 RpcServer 上报本人 bind 的端口和 ip。这一步其实就是最要害的步骤。
RpcServer 收到申请后将 RSCDrvier 的端口和 ip 封装成 ContextInfo 返回给 LivyServer。同时敞开 RpcServer。
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=vm3198
spark.__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 通信的细节有机会还会再基于源码具体开展剖析

正文完