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