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