m0_73904819的博客

12.调用requestHeartbeat（）方法，传进去两个参数，一个是resourceid（每一个tm后者jobmaster都有唯一resourceid），另一个payload，是发送的消息数据，下面的whencompleteAsync是心跳消息发送后，失败或者成功的逻辑就在这里面，我们继续点进requestheartbeat（）方法。11.这个时候我们再回头看这个定时调度的任务，此时map中有值，会调用requestHeartbeat（）方法，点进这个方法。Flink1.19心跳机制实现原理。

JobGraph在客户端生成后，需要发送到服务端，首先会被JobSubmitHandler（WebMonitor内处理http请求的处理类）接收处理，然后会发送到Dispatcher进一步处理

首先启动JobMaster，初始化jobMaster对象时，会将JobGraph转化ExectionGraph并且生成Execution拓扑图，调度器根据拓扑图进行调度，先向ResourceManager申请资源后，而RM会向TaskExecutor申请资源，资源申请完成后，部署Flink任务。schedulingStrategy调度策略接口，当前为流处理模式，PipelinedRegionSchedulingStrategy。->startScheduling() 开始调度资源申请和任务部署。

12.我们可以看见这是leaderContender接口的一个方法，我们之前说过凡是要实现高可用的组件都必须实现leaderContender接口，从图中可以看到leaderContender有四种实现，分别是我之前所说的JM，RM，WbE，DP，我们这里只看RM的。到这里我们看到了选举机制是如何帮助我们启动组件的，接下来看高可用是怎么做的，组件故障了怎么办，如果RM leader故障了，会发生什么。4.这里先进行了参数的检查，随后进行注册，继续往里点。凡是要实现高可用的组件都要实现这个接口。

这张图是我从网上找来的，Flink1.19版本中ExecutionGraph的ExecutionEdge已经被移除，改为了EdgeManager，也就是说IngermediateResult和ExecutionJobVertex之间没有了很多个ExecutionEdge，取而代之的是只有一个的EdgeManager。第一行，我们可以看到，入参是this，就是我们刚刚构建的ExecutionGraph对象，将其转换为一个拓扑结构图，并封装为ExecutionGraph对象的一个属性，这是真正用来执行的。

16.在这么多代码中，最为核心的就是这一行代码，setChaining（）这个方法从名字上看，就是设置算子链，在这个方法里，完成了JobGraph整体结构的创建和算子任务的合并，由于比较复杂，我这一篇就不赘述了，后面会出一篇单独讲。14.回退出来，调用createJobGraph，对这个jobgraph进行属性的赋值，这一步才算真正的创建了JobGraph，我们进入这个方法。这里是我准备的一个很简单的flink程序，我们以这个job任务为例，讲述flink的jobgraph是如何生成的。

10.通过rpcService获取RM的代理对象，这是FlinkRpc通信相关的知识，前面的一篇文章有讲，这里不过多赘述，将代理对象传入register()方法中。12.接下来会走Rpc通信，这里前面一篇文章讲过，最终会调用到RM的registerTaskExecutor()方法完成注册。4.第一次启动，会调用notifyOfNewResourceManagerLeader()方法，继续点进去。TaskExecutor的注册过程看起来很绕，其实也很简单，就是方法的不断调用，厘清楚就很清晰了。

以ResourceManager和TaskManager通信为例，底层TaskManager(实际上是TaskExecutor)要向ResourceMananger发送消息，首先要获取到rm的网关（动态代理对象），然后调用动态代理对象的invoke方法，将。Rpc通信是flink的重要机制之一，在底层很多地方都用到了上面的内容，例如RM和TM的通信，RM和JobMaster的通信，心跳机制，组件的启动等等。所有能进行RPC通信的组件都需要实现RpcEndpoint这个抽象类，才能实现通信。