無論是消息係統，還是配置管理中心，甚至存儲係統，你都要麵臨這樣一個選擇，push模型 or pull模型?是服務端主動給客戶端推送數據，還是客戶端去服務器拉數據，一張圖表對比如下：
|
push模型 |
pull模型 |
| 描述 |
服務端主動發送數據給客戶端 |
客戶端主動從服務端拉取數據，通常客戶端會定時拉取 |
| 實時性 |
較好，收到數據後可立即發送給客戶端 |
一般，取決於pull的間隔時間 |
| 服務端狀態 |
需要保存push狀態，哪些客戶端已經發送成功，哪些發送失敗 |
服務端無狀態 |
| 客戶端狀態 |
無需額外保存狀態 |
需保存當前拉取的信息的狀態，以便在故障或者重啟的時候恢複 |
| 狀態保存 |
集中式，集中在服務端 |
分布式，分散在各個客戶端 |
| 負載均衡 |
服務端統一處理和控製 |
客戶端之間做分配，需要協調機製，如使用zookeeper |
| 其他 |
服務端需要做流量控製，無法最大化客戶端的處理能力。
其次，在客戶端故障情況下，無效的push對服務端有一定負載。
|
客戶端的請求可能很多無效或者沒有數據可供傳輸，浪費帶寬和服務器處理能力 |
| 缺點方案 |
服務器端的狀態存儲是個難點，可以將這些狀態轉移到DB或者key-value存儲，來減輕server壓力。 |
針對實時性的問題，可以將push加入進來，push小數據的通知信息，讓客戶端再來主動pull。
針對無效請求的問題，可以設置逐漸延長間隔時間的策略，以及合理設計協議盡量縮小請求數據包來節省帶寬。
|
在麵對大量甚至海量客戶端的時候，使用push模型，保存大量的狀態信息是個沉重的負擔，加上複製N份數據分發的壓力，也會使得實時性這唯一的優點也被放小。使用pull模型，通過將客戶端狀態保存在客戶端，大大減輕了服務器端壓力，通過客戶端自身做流量控製也更容易，更能發揮客戶端的處理能力，但是需要麵對如何在這些客戶端之間做協調的難題。
909
