Created by: backyes

本issue 重点描述Parameter Server的端口范围问题，此问题在内部某些大业务的生产环境会有较大影响。

目前， Parameter Server要求所有逻辑pserver instances 监听端口范围保持强一致。

它主要受三个参数控制:

• --ports_num, --port, --ports_num_for_sparse

上述三个参数选择了一个port range。

这种问题的影响特说明一下：

• 为了提高计算利用率或者提高可活跃作业的容量，部分平台可能会同时在同一台物理机上调度多个Paddle instance，同时可能会出现因为端口冲突导致服务启动失败，同时也可能出现早期的paddle作业因为重复instance的启动导致parameter server被重复初始化，最终整个集群出现undefined的问题。 这类问题一般出现在多个非虚机（virtual machine）、非容器（container）场景下。

• 对于基于container的集群调度，比如k8s等，由于端口资源是被映射的，所以不会出现上述冲突。同理， 对于虚机场景一般也不会出现这种冲突。

• 理论上，这种限制是可以完全打破的， 允许任意parameter server instance使用任意连续的端口范围，不同instance之间无需强一致，达到这种目的需要：

  • 需要调度平台（脚本）能预留相关端口资源 （需要在任务启动前，原子性分配任意的port range资源）
  • 需要paddle trainer支持连接parameter server的任意端口范围 （需要改动trainer 逻辑） 内部曾经实现过一个版本： http://cooder.baidu.com/3206819/， 但是由于历史原因，并未merge进 trunk，且距离当前开源版本差距较远，仅供参考。

• 未来paddle架构升级以后（比如采用基于master-worker架构）， 实现上述功能可能也要做较大的改动。 所以， 建议综合考虑此问题，希望在新设计中能去除这种限制。