ps-lite項目實現了參數服務器框架中的通信模塊，簡化了原paper中的設計，將集羣中節點分爲scheduler, worker和server三類，主要解決節點間的通信問題。
核心類
| 類名 | 功能 | 代碼位置 |
|---|---|---|
| SimpleApp | 基礎消息通信類，消息包括一個int類型的head和一個string類型的body | ps-lite/include/ps/simple_app.h |
| KVWorker | 表示一個Worker節點，繼承自SimpleApp類，實現了key-value鍵值對數組的Pull和Push操作 | ps-lite/include/ps/kv_app.h |
| KVServer | 表示一個Server節點，也繼承自SimpleApp類，所有的Server節點一起維護全局的key-value鍵值對數組 | ps-lite/include/ps/kv_app.h |
| Customer | 客戶類，負責處理所在節點內接收到的msg.meta.customed_id等於自身customer_id的所有消息，負責維護所有request和response消息的狀態信息 | ps-lite/include/internal/customer.h |
| Postoffice | 全局管理類，單例對象，讀取啓動時的環境變量配置集羣的全局信息，如server，worker數量，角色 | ps-lite/include/internal/postoffice.h |
| Van | Postoffice的核心成員變量，實現集羣內節點間的通信，底層依賴zmq庫，實現對socket等通信細節的封裝 | ps-lite/include/internal/van.h |
| KVPirs | 主要有keys,values,lens3個數組類型的成員變量 | ps-lite/include/ps/common.h |
| SArray | 數組的實現類，爲了避免了數組的深拷貝做了特別是設計 | ps-lite/include/ps/sarry.h |
通信機制
按照參數服務器框架設計和實現的分佈式訓練算法，訓練過程中節點間會有很多的通信，主要分爲control控制類的通信和數據類通信.
控制類的通信主要用於管理和協調集羣工作，比如啓動同步，容錯恢復，節點註冊，心跳同步，等等；數據類的通信主要用於worker和server節點間參數的拉取和推送操作。另外，開發者還可以自定義自己的消息類型。
本文以參數的pull操作爲例，分一下ps-lite中的通信機制。
- pull操作由worker端發起，因爲若干個server節點共同維護參數，所以pull操作會根據每個server負責維護的參數key的範圍，切分請求後發往若干個不同的server節點。
- server節點處理並返回worker端請求的key的參數值.
- server返回的參數值經過合併後，返回給worker端pull操作的調用者。
- pull操作是異步操作，不等待server處理返回，調用者可以選擇傳入回掉函數，或則接着調用wait操作來等待server節點的返回值。
push操作的過程比較類似，不再介紹。
數據一致性
pslite並沒有實現paper中非常靈活的數據一致性方面的設計，而是簡化了這方面的設計，不支持有限延遲一致性。因此當我們採用同步wait方式的時候，就選擇了線性一致性，當我們不採用wait方式的時候，就選擇了最終一致性。
集羣性能調優指南
衡量分佈式機器學習集羣性能的指標包括：
| 指標 | 含義 | |
|---|---|---|
| 集羣QPS | 集羣整體訓練數據的吞吐效率 | |
| 單機負載 | 單機的負載 |
集羣性能調優目標一般來說，就是提高集羣QPS，同時要保證單機負載控制在安全合理的範圍內。單機的負載太低，說明集羣資源的利用率低，負載太高，加大了機器故障的概率，同樣不合理。
採用pslite的訓練集羣，爲了提高性能，可以從幾個方面考慮：
- 參數更新採用異步還是同步： 同步更新會導致性能高的節點等待性能差的節點，所以一般來說，異步更新集羣的QPS更高。
- 訓練數據的切分是否合理： 數據切分不均勻會導致部分節點利用率低，延長整體的訓練時間。
- server，worker節點的數量比例是否匹配： 需要根據worker和server的運算量設置合理的節點數量比例，否則會造成參數推拉操作延遲高的問題。
- server，worker節點的絕對數量是否合理： 一般來說更多的節點數量會造成通信次數的增加，但同時單次通信的數據量可能會變小。pslite通過節點間的長連接的方式一定程度克服了鏈接建立和斷開的開銷。