作者回复: 老师下个月会出一本源码解析的书，到时候可以关注下

作者回复: JobManager和TaskManager之间RPC通信只是为了发送一些控制信息，例如控制Task的启停，以及TaskManager的注册等，以及组件之间的HeartBeat操作等。而TaskManager之间不会直接进行RPC通信，TM之间主要是数据的交互，就是MapReduce中Shuffle，对数据的交互走的是基于Netty实现的Network Stack。 其实Akka问题还是比较多的，尤其是版本问题，而在Flink里面就是基于Flink实现了一下RPC通信功能，这里社区后期进行统一的，有可能就像Spark框架把Akka去掉，直接用Netty实现RPC即可，当然这个动作变动的比较大，影响面比较广，因此可能会放在未来版本中实现。

作者回复: 不管是在哪种模式下都需要上传Jar包，只不过App模式下Jar包可以提前传在分布式HDFS中，这样Client就不需要每次上传了，JM可以直接从HDFS上获取Jar包，本质上就是降低上传开销

作者回复: 这块后面会在DataStream章节中详细讲解

作者回复: 这个问题还是要看Client端主机具体情况的，通常情况下Client提交Jar包到Cluster的时候，最大的IO消耗就是Jar包的传输，Jar包越大传输时间IO也越高。传输的过程中还要看Session集群的情况，如果RPC网络连接出现异常重连等情况，会Block整个客户端的提交过程，这个时候会有重新提交的过程，IO通常也会很高，因此还是要具体问题具体分析，可以把Master的日志拿下来看看，里面针对Dispatcher的日志进行分析，看看有什么具体的原因。 谢谢

作者回复: Application模式主要解决的是Client负载的问题，包括JobGraph提交以及Jar ship的性能问题。另外Application更像Spark里面的Cluster模式，区别就是Driver是在Client本地还是在Cluster上，但是需要注意Spark里面的Driver是要和Executor之间交互的，在Flink里面只会通过JobManager和TaskManager交互，Client仅仅只是编译性的工作，生成JobGraph和提交作业，以及对Job的运行状况进行监控，所以还是和Spark有些区别的。

作者回复: 预计一月份，敬请期待

作者回复: 原理都是一样的，接口基本上都是些语法上的区别，没什么问题的，加油，后面我们看有时间把Python的接口讲一下

作者回复: 东西太多了，时间又比较有限，但是还是想尽可能的把Flink的很多精华讲给大家，后面可以适当的放慢点哈

作者回复: 这里先有一个大概的认识，Runtime章节会对这块进行深入的介绍