1 Dive into TensorFlow系列-静态图运行原理( 二 ) _生活百科

def run(self, fetches, feed_dict=None, options=None, run_metadata=https://www.huyubaike.com/biancheng/None):run()方法的参数说明如下：
?fetches：指定要执行的tf.Operation或评估的tf.Tensor，可以是单个元素或是列表、字典。?feed_dict：一个占位符到填充值的映射。?options：RunOptions的protocol buffer 。?run_metadata：RunMetadata的protocol buffer，用来收集执行过程的元数据信息。当Session指定fetches后，根据要获取的结果决定tf.Graph实际执行的subgraph（并非整个tf.Graph都要执行）。执行静态图还有三个要点：
?训练阶段用一个静态图，而预测/评估阶段用另一个静态图。?一个session实例只能运行一个graph实例，但一个graph可以运行在多个session中。?session之间可通过共享graph的方式来提高运行效率。创建session时若不指定graph，则运行的是default graph 。如果新创建的session也不指定graph ，则只需要对default graph的引用计数加1即可；当此session close时，default graph引用计数减1 。2.3 Session类前后端设计首先我们看一下和用户直接打交道的前端Session，具体分为普通Session和交互式InteractiveSession 。前者全称为tf.Session，需要在启动之前先构建完整的计算图；后者全称为tf.InteractiveSession，它是先构建一个session ，然后再定义各种操作，适用于shell和IPython等交互式环境。这两个类均继承自BaseSession，这个基类实现了整个生命周期的所有会话逻辑（相关代码在tensorflow/python/client/session.py中）。前端Session类的继承关系如下图：

文章插图
TensorFlow后端会根据前端tf.Session(target='', graph=None, config=None)创建时指定的target来创建不同的后端Session 。target是要连接的TF后端执行引擎，默认为空字符串。后端Session的创建采用抽象工厂模式，如果为空字符串，则创建本地DirectionSession；如果是grpc://开头的URL串，则创建分布式GrpcSession 。DirectSession只能利用本地设备，将任务调度到本地的CPU/GPU设备上；GrpcSession可利用远程设备，将任务分发到不同机器的CPU/GPU上，然后机器之间通过gRPC进行通信。显而易见，DirectionSession的定义应在core/common_runtime/direction_session.h中；GrpcSession的定义在core/distributed_runtime/rpc/grpc_session.h中。后端Session的类图关系如下所示：

文章插图
三、静态图执行过程3.1 执行框架为便于大家理解，我们先给出粗粒度的静态图执行原理如下：
1.客户端程序定义基于数据流的计算图，然后创建session并初始化计算引擎。2.分布式Master依次完成四项工作：抽取实际执行的subgraph、切分subgraph形成若干子图片段、调度子图片段至集群、每个子图片段执行前的初始化工作。3.集群中的Worker节点调度子图片段中Operation的执行，与其他Worker节点通过send/recv节点对进行通信。

文章插图
3.2 若干执行细节静态图的实际执行过程要比3.1节描述的复杂得多。由于本篇的初衷不是做源码的完整剖析，因此我们仅就Client向Master的处理过程做详细说明，旨在让读者亲身体会一下交互过程的复杂性。
Client创建GrpcSession ，控制Client会话的生命周期；Master运行时被MasterSession控制。GrpcSession通过抽象工厂模式得到，首先得到工厂类GrpcSessionFactory的对象，并用SessionFactory句柄factory存储。然后通过factory的多态方法生成GrpcSession，如果target为grpc://的话。Master本质上是一个Server，每个Server均有一个MasterService和一个WorkerService 。
Client通过GrpcSession调用Master节点的MasterService，这个过程需借助MasterInterface才可完成。MasterInterface用来和MasterService进行通信，它有两种不同的场景实现：
?如果Client和Master在同一个进程中，则用LocalMaster实现进程内的直接通信。?GrpcRemoteMaster则使用gRPC来和MasterService进行通信，此时Master和Client在两个不同的进程中。GrpcRemoteMaster的角色是gRPC客户端，它通过stub访问远程Master节点上的MasterService服务。

文章插图
如果读者想对上述过程做更为深入的了解，可以参考几个关键类的源码：
?GrpcSession：core/distributed_runtime/rpc/grpc_session.h?LocalMaster：core/distributed_runtime/local_master.h?GrpcRemoteMaster：core/distributed_runtime/rpc/grpc_remote_master.cc?GrpcMasterService：core/distributed_runtime/rpc/grpc_master_service.cc其实Client到Master的处理过程还涉及MasterSession的创建，以及GrpcSession与MasterSession的交互与标识问题。篇幅所限，不展开了。