// 未經博主本人允許，謝絕轉載，謝謝
目前mxnet支持多種分布式形式，根據官方文檔，支持的形式有ssh、mpirun、sge集群、yarn集群等幾種形式。ssh和mpirun是需要指定機器列表的，ssh需要提交機對其他機器有信任關系。如官方文檔所述：
『Launching a distributed job is a bit different from running on a single machine. MXNet providestools/launch.pyto start a job by usingssh,mpi,sge, oryarn.』
最近主要看了基于yarn的mxnet深度學習作業，下面做一個小結，記錄一些思考
可以使用mxnet/tools/launch.py向yarn集群提交一個mxnet，launch.py的參數--launcher指定為yarn即可
launch.py會調用mxnet/dmlc-core/tracker/dmlc_tracker/yarn.py中定義的submit，主要作用是export一些yarn作業需要的環境變量
最終都會調用tracker.py的submit函數，當提交時指定的server數量大于0時，會在當前提交機用一個線程啟動kvstore中的scheduler角色。
然后向yarn集群提交一個作業，這個作業的ApplicationMaster在dmlc-core中已經實現，會根據worker和server的數量向Yarn集群的RM申請資源，拿到資源后，啟動worker和server，在環境變量中export scheduler的地址、自身的角色（自己是worker還是server）等必要信息。這個AM會在worker或者server異常的時候重新啟動它們。
在機器上啟動了worker或者server后，單機也需要做計算的工作，如果角色是worker，那么計算后負責參數推送和拉取到server。
這里沒有輸入數據的切分和分配，每個計算節點讀取什么樣的輸入，是由計算節點自身的rank號來決定自己讀取總輸入的哪一部份。
個人的想法：
跟想象中的分布式作業相比，這里scheduler這樣具有『協調』功能的角色，和ApplicationMaster同樣具有『協調和管理』功能的角色是割裂的，同時對作業的總體進度也沒有把控，不具備分布式作業中常見的處理慢節點、控制進度、縮擴容等等的決策和實施能力，分布式的實現相對來說是比較簡單的。
