網(wǎng)頁(yè)端收消息，究竟是推還是拉？
任何脫離業(yè)務(wù)的架構(gòu)設(shè)計(jì)都是耍流氓。
網(wǎng)頁(yè)端收消息，究竟是推還是拉?
什么業(yè)務(wù)場(chǎng)景?
對(duì)于在網(wǎng)頁(yè)端登錄的用戶(hù)A，發(fā)送方，也就是消息的來(lái)源有幾方面：
- 系統(tǒng)發(fā)給A的“系統(tǒng)通知”，可能對(duì)實(shí)時(shí)性要求沒(méi)這么高;
- 用戶(hù)發(fā)給A的“聊天消息”，有對(duì)實(shí)時(shí)性要求比較高，越實(shí)時(shí)越好。
消息的處理方，也就是系統(tǒng)側(cè)，一般來(lái)說(shuō)：
- 有服務(wù)對(duì)消息進(jìn)行邏輯處理;
- 有數(shù)據(jù)庫(kù)對(duì)數(shù)據(jù)進(jìn)行落地;
- 有緩存對(duì)數(shù)據(jù)進(jìn)行加速。
拋開(kāi)這些技術(shù)細(xì)節(jié)不談，暫且認(rèn)為服務(wù)端對(duì)每一個(gè)用戶(hù)都有一個(gè)“待收消息”的隊(duì)列，里面存放了需要給這個(gè)用戶(hù)的一切消息。
消息的接收方，也就是用戶(hù)A，如果是在網(wǎng)頁(yè)端登錄，因?yàn)镠TTP協(xié)議是“請(qǐng)求-響應(yīng)”式的，服務(wù)端與網(wǎng)頁(yè)之間沒(méi)有消息通道，對(duì)于這類(lèi)“收消息”的需求，是如何處理的呢?
方案一：輪詢(xún)拉取
輪詢(xún)拉取，是最容易想到的實(shí)現(xiàn)方式：
- 發(fā)送方發(fā)送了消息，先入隊(duì)列;
- 網(wǎng)頁(yè)端起一個(gè)timer，每個(gè)一段時(shí)間(例如10秒)，發(fā)起一個(gè)輪詢(xún)請(qǐng)求，拉取隊(duì)列里的消息;
- 如果隊(duì)列里有消息，就返回消息;
- 如果隊(duì)列里無(wú)消息，就10秒后再次輪詢(xún)。
這種方式的優(yōu)勢(shì)是：實(shí)現(xiàn)簡(jiǎn)單，直觀且，容易理解，互聯(lián)網(wǎng)興起時(shí)，人數(shù)不多的聊天室就是這么玩的。畫(huà)外音：創(chuàng)辦于1996年的互聯(lián)網(wǎng)老站碧海銀沙，曾經(jīng)中國(guó)最火爆的聊天室，已于2017.9.27停止運(yùn)營(yíng)。
缺點(diǎn)也很明顯：
- 實(shí)時(shí)性差：最壞的情況下，1條消息進(jìn)入隊(duì)列后，10s之后才會(huì)收到;
- 效率低下：發(fā)消息是一個(gè)低頻動(dòng)作，如果10次輪詢(xún)才收到1條消息，請(qǐng)求有效性只有10%，浪費(fèi)了大量服務(wù)器資源。
更要命的是，在這種方案下，實(shí)時(shí)性與效率是一對(duì)不可調(diào)和的矛盾：如果將輪詢(xún)周期設(shè)為1/10，將時(shí)延縮短到1秒，意味著100次輪詢(xún)才會(huì)收到1條消息，請(qǐng)求有效性則降為了1%。
方案二：建立長(zhǎng)連接
如果要兼顧實(shí)時(shí)性和效率，長(zhǎng)連接是最佳之選，PC端聊天軟件基本都是使用長(zhǎng)連接。網(wǎng)頁(yè)端常見(jiàn)的實(shí)現(xiàn)長(zhǎng)連接的方式有兩種：
- WebSocket
- FlashSocket
這兩種方案的細(xì)節(jié)不再展開(kāi)，ta們均有一定的局限性。
更為通用的方式，是“長(zhǎng)輪詢(xún)”。
長(zhǎng)輪詢(xún)，是通過(guò)拼裝HTTP短連接來(lái)達(dá)到長(zhǎng)連接的效果，即保證了消息100%實(shí)時(shí)，又最大化的系統(tǒng)效率。
方案三：HTTP長(zhǎng)輪詢(xún)
HTTP長(zhǎng)輪詢(xún)的核心在于，瀏覽器與服務(wù)端之間建立了一條“通知連接”，它的特點(diǎn)是：
- 這是一條browser發(fā)往web-server的HTTP連接;
- 這條連接只用來(lái)收取推送通知;
- 不像普通的“請(qǐng)求-響應(yīng)”式HTTP請(qǐng)求，這個(gè)HTTP會(huì)被服務(wù)端夯住，直到有推送通知到達(dá)，或者超過(guò)約定的時(shí)間。
畫(huà)外音：對(duì)于HTTP請(qǐng)求，為了提高效率，一般來(lái)說(shuō)browser和web-server都會(huì)有一些設(shè)置，如果一條HTTP請(qǐng)求長(zhǎng)時(shí)間沒(méi)有數(shù)據(jù)(例如，150秒)，會(huì)被斷開(kāi)。“通知連接”為了不被browser和web-server粗暴斷開(kāi)，一般會(huì)設(shè)置一個(gè)約定閾值(例如，小于150秒)，由系統(tǒng)返回一個(gè)空消息，以便“優(yōu)雅返回”。
更具體的，對(duì)于這條“夯住”與“只收推送通知”的“通知連接”，是怎么玩的呢?
場(chǎng)景一，發(fā)起通知連接時(shí)，隊(duì)列里正好有消息，則：
- 發(fā)起通知連接，正好隊(duì)列里有消息;
- 實(shí)時(shí)把隊(duì)列里的消息帶回;
- 立馬再發(fā)起通知連接。
場(chǎng)景二，發(fā)起通知連接時(shí)，隊(duì)列里無(wú)消息，則：
- 發(fā)起通知連接時(shí)，隊(duì)列里無(wú)消息;
- 一直等待，直到觸發(fā)“時(shí)間閾值”，返回?zé)o消息;
- 立馬再發(fā)起通知連接。
場(chǎng)景三，新消息來(lái)時(shí)，正好有通知連接在，則：
- 新消息來(lái)時(shí)，正好有通知連接在;
- 通知連接實(shí)時(shí)將消息帶回;
- 立馬再發(fā)起通知連接。
上面三個(gè)場(chǎng)景的最終狀態(tài)，都是“一定，永遠(yuǎn)，會(huì)有一條通知連接，連接在瀏覽器與服務(wù)器之間”，這樣就能夠保證消息的實(shí)時(shí)性。當(dāng)然，有人會(huì)說(shuō)，HTTP的返回與再次發(fā)起會(huì)有一個(gè)時(shí)間差，如果這個(gè)時(shí)間差，恰巧有新消息過(guò)來(lái)呢?
場(chǎng)景四，新消息來(lái)時(shí)，沒(méi)有通知連接，則：
- 新消息來(lái)時(shí)，沒(méi)有通知連接;
- 把新消息放入隊(duì)列。
最后這個(gè)場(chǎng)景，發(fā)生的概率非常小，但也確保了在“HTTP的返回與再次發(fā)起會(huì)有一個(gè)時(shí)間差”內(nèi)，消息不會(huì)丟失，在通知連接發(fā)起后，消息能夠?qū)崟r(shí)返回。
總結(jié)
網(wǎng)頁(yè)端收消息，究竟是推還是拉?
- 最容易想到的是拉，但實(shí)時(shí)性和效率是一對(duì)無(wú)法調(diào)和的矛盾;
- 最佳的方式是推，但WebSocket和FlashSocket各有局限性;
- 最通用的方式是長(zhǎng)輪詢(xún)，通過(guò)HTTP短連接拼裝長(zhǎng)連接，具體是通過(guò)“夯住”“只收推送通知”的“通知連接”來(lái)實(shí)現(xiàn)的，能夠做到消息的實(shí)時(shí)性到達(dá)。
【本文為51CTO專(zhuān)欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
