http環(huán)境本身是一種無連接狀態(tài)的架構(gòu),在這種架構(gòu)下服務(wù)器只能是被動的接受客戶端的請求,返回結(jié)果,而無法主動的給客戶端發(fā)送數(shù)據(jù)。而在很多需要實時數(shù)據(jù)交互(比如web im)的場景中,我們卻希望能及時得到服務(wù)器給我們返回的數(shù)據(jù)。此時,一種最為普遍的做法是:在客戶端用定時器,定時去請求服務(wù)器的服務(wù),來得到最新數(shù)據(jù)。而這樣一來,很多時候卻是在做無用功,頻繁的請求也會無端的增加服務(wù)器和客戶端在請求web服務(wù)上的消耗。那么是否有一種更好的辦法,既可以及時得到服務(wù)器的返回,同時又可以減少做無用功,以及頻繁請求帶來的性能問題呢?
記得前不久,在園子里有這樣的一篇文章,介紹了幾種web環(huán)境定時刷新數(shù)據(jù)的機(jī)制。其中就有提到google gmail的一種比較巧妙的做法,現(xiàn)在記不得當(dāng)時是怎么理解這種做法了,只記得有“保持長連接”的基本做法。(當(dāng)然現(xiàn)在也找不到這篇文章了,希望了解的朋友能提醒一下)。今天由于架構(gòu)方案的需要,再來仔細(xì)思考連接保持方案,以及參考gmail的請求行為,總結(jié)了一下,應(yīng)該是這樣的:客戶端一直保持一個與服務(wù)器的連接,這個連接一直保持著對服務(wù)器的請求動作,直到服務(wù)器發(fā)現(xiàn)有數(shù)據(jù)后給它返回后,才結(jié)束返回這一次請求??蛻舳嗽诮邮盏秸埱蠓祷睾?,在處理這些返回之前,又向服務(wù)器發(fā)送了一次連接請求,直到下一次有數(shù)據(jù)返回。不可避免的有一種情況,就是如果服務(wù)器長時間沒有需要給客戶端發(fā)送數(shù)據(jù)的話,那么可以就會造成請求失敗(超時或其它原因)。對于這種情況的處理也是一樣的,在錯誤的回調(diào)事件中重新發(fā)送一次請求連接。這樣就可以模擬保持連接狀態(tài)了。
用偽代碼來描述一下思路吧:
客戶端腳本:
1: function request()
2: {
3: ajax.request(url,onsuccessed,onfailed);
4: }
5: function onsuccessed(response)
6: {
7: //重新發(fā)送一次請求
8: request();
9: //處理返回數(shù)據(jù)
10: }
11: function onfailed()
12: {
13: //錯誤(超時)重新請求
14: request();
15: }
web服務(wù):
1: public class imservice : ihttphandler
2: {
3: public bool isreusable{return false;}
4: public void processrequest(httpcontext context)
5: {
6: //讀取最新數(shù)據(jù)
7: while(true)
8: {
9: string message = getmessage();
10: if(!string.isnullorempty(message))
11: {
12: context.response.write(message);
13: break;
14: }
15: thread.sleep(500);//等待一段時間再重新讀取。
16: }
17: }
18: private string getmessage()
19: {
20: //取得最新數(shù)據(jù)
21: }
22: }
這種方案的好處有:客戶端可以第一時間得到服務(wù)器需要給客戶端發(fā)送的數(shù)據(jù)(而至于web服務(wù)怎么知道要給客戶端發(fā)送數(shù)據(jù),也就是服務(wù)器的輪循設(shè)計,則是另一個需要考慮的方案);可以減化客戶端邏輯,無需要創(chuàng)建和釋放定時器,并減小由此產(chǎn)生的對客戶端性能的損失;減少去服務(wù)器的請求次數(shù),減少做無用功,節(jié)約節(jié)省帶寬和減少服務(wù)器資源需要處理的連接請求。
相信在此之前,已經(jīng)有很多人在使用這種方案了。歡迎大家就此方案發(fā)表自己的見解。
補充:服務(wù)器部分的設(shè)計,除了使用輪循外,也可以考慮使用資源互斥訪問的方式來設(shè)計,這樣做可以獲得更佳性能,更高實時性,具體的方案應(yīng)當(dāng)根據(jù)實際情況來考慮。