Home Blogs Readings Notes Jupyter Seafile

parameter server核心源码解析

09 Sep 2018

启动过程

ps的启动过程关键在于理解postoffice,van,customer, app这四个抽象组件之间的关系。

ps中一个节点可选的角色有三种,scheduler,server,worker. scheduler负责所有节点的接入和心跳检测。

启动的时候,所有的节点都会先启动开始提到组件。其中postoffice负责环境信息和集群信息的维护,van负责 当前节点数据的发送和接受,而customer则是业务消息接受和发送管理的抽象,app则是基于customer对server和 worker具体执行函数的自定义入口。

van是基于zmq实现的pub-sub消息传递模式,主要作用是消息路由,对于集群控制类消息和数据类消息传递 给不同的对象,也就是scheduler或者customer。

整个启动过程,首先会执行app所在main函数作为入口,app启动的时候会直接创建一个customer实例, 并将具体的req和resp处理函数绑定到customer上。然后会进行postoffice初始化。

postoffice在类初始化的时候会直接初始化一个van实例。在启动的时候,主要步骤如下:

van则在启动中主要做的事情如下:

当所有节点都添加到scheduler端的时候,sceduler端根据节点的ip+port排序rank分别给每个节点 分配ID,每个节点收到ID分配消息后,更新自己的信息。

当所有节点信息更新完成,集群启动开始根据barrier参数进行固化。

键值传输分配

节点的key range是如何划分的?计算过程中一个key应该会分到哪个主机上?

先说key range划分问题。当配置了server和worker的数量后,server端的key range已经直接按照每个区间范围都是Max/numb_server的大小。具体可以看这部分源码,线上是server rank转成node id,然后直接将key range分给该node 来划分来。

那么一个key到底会分到哪个机器上呢?

一个具体的物理机信息要经过两步才能和真正的key range对应起来。

其中另外一个比较需要注意的点是test_kv_app.cc中key的生成方式其实也是比较有意思的。

其实以上过程就包含了一个worker对数据进行PUSH的过程:

-->
Fork me on GitHub