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