客戶端向服務(wù)器請(qǐng)求數(shù)據(jù)，服務(wù)器立即將數(shù)據(jù)返回給客戶端。 如果客戶端沒有得到想要的數(shù)據(jù)（比如返回的結(jié)果告訴客戶端正在處理數(shù)據(jù)），客戶端繼續(xù)發(fā)送請(qǐng)求，服務(wù)器繼續(xù)立即響應(yīng)，周而復(fù)始。
這種實(shí)時(shí)獲取數(shù)據(jù)的方式比較粗糙，優(yōu)點(diǎn)是編程簡單，客戶端發(fā)送請(qǐng)求，服務(wù)端實(shí)時(shí)響應(yīng)。 主要有兩個(gè)缺點(diǎn)：
那么短輪詢適合哪些使用場景呢？ 按照我的理解，如果數(shù)據(jù)變化頻繁或者可以預(yù)計(jì)數(shù)據(jù)在短時(shí)間內(nèi)變化一次，可以使用短輪詢，比如：
用戶在 PC 上購買東西以激活網(wǎng)頁。 由于 PC 和 web 沒有連接，我們希望用戶盡快完成支付。 在這種情況下，短輪詢是一種可用的方法，開發(fā)簡單，服務(wù)端直接提供接口告訴客戶端訂單狀態(tài)。 客戶端只需要每5秒請(qǐng)求一次，得到結(jié)果就不需要再請(qǐng)求了。
使用短輪詢時(shí)，要注意請(qǐng)求數(shù)上限的控制。 例如服務(wù)器接收http數(shù)據(jù)，用戶請(qǐng)求100次后仍未檢測到付款，則可以彈出“付款完成后請(qǐng)到我的訂單頁面查看”的窗口，無需請(qǐng)求。
長輪詢
長輪詢是另一種實(shí)時(shí)獲取數(shù)據(jù)的方式。 看一下過程：
本質(zhì)沒變。 客戶端仍然在向服務(wù)器發(fā)送請(qǐng)求，而沒有收到它想要的數(shù)據(jù)。 不同的是，服務(wù)器不再直接響應(yīng)請(qǐng)求，而是暫停請(qǐng)求，自行調(diào)度。 判斷數(shù)據(jù)的變化，如果有變化，則立即返回給客戶端，如果沒有變化，則等待超時(shí)。
可以明顯看出，長輪詢的好處是客戶端請(qǐng)求少很多，避免了不必要的客戶端請(qǐng)求。 缺點(diǎn)是服務(wù)器會(huì)掛掉大量請(qǐng)求增加資源消耗，并且服務(wù)器對(duì)HTTP請(qǐng)求的并發(fā)數(shù)有限制。 的。
微信網(wǎng)頁版的登錄就是長輪詢的典型例子：
從圖中可以看出，客戶端不停地向服務(wù)器發(fā)送請(qǐng)求，但是服務(wù)器并沒有在第一時(shí)間給出響應(yīng)，所以客戶端等待超時(shí)繼續(xù)發(fā)送請(qǐng)求。
總的來說服務(wù)器接收http數(shù)據(jù)，我理解長輪詢一般用的比較多，而短輪詢對(duì)于簡單的編程更重要，適合小型應(yīng)用。 像微信網(wǎng)頁登錄，幾千個(gè)用戶同時(shí)登錄，一段時(shí)間后服務(wù)器收到幾千個(gè)請(qǐng)求處理。 堆積機(jī)器來分?jǐn)偯總€(gè)服務(wù)器上的處理請(qǐng)求數(shù)并不是解決問題的辦法。
上面介紹了兩種輪詢方式，但是兩者結(jié)合起來有明顯的缺點(diǎn)。 總結(jié)起來有以下幾點(diǎn)：
因此，我們能做的最好的事情就是：客戶端和服務(wù)器之間有一條路徑。 當(dāng)服務(wù)器上的數(shù)據(jù)發(fā)生變化時(shí)，服務(wù)器可以主動(dòng)推送給客戶端。 它是在HTML5之后誕生的協(xié)議來實(shí)現(xiàn)這一點(diǎn)。 雖然這是一個(gè)新的協(xié)議，但它也是基于 HTTP 協(xié)議的。
看一下原理，很簡單：
客戶端首先通過HTTP協(xié)議向服務(wù)端發(fā)送幾個(gè)特殊的header，告訴服務(wù)端我現(xiàn)在發(fā)起一個(gè)HTTP請(qǐng)求，但是我要升級(jí)到：
只要服務(wù)端支持該協(xié)議（Tomcat7和Jetty7之后支持），服務(wù)端在收到請(qǐng)求并建立連接成功后，會(huì)返回Sec--Accept和Sec--這兩個(gè)header給客戶端，Http Status為101 . 協(xié)議切換成功，這樣客戶端和服務(wù)端只要任何一方不斷開連接就可以基于這條路徑進(jìn)行通信。
再說說相對(duì)于上面提到的長短輪詢在帶寬資源上的節(jié)省。 有一個(gè)測試，假設(shè)HTTP Header是871字節(jié)。 由于數(shù)據(jù)傳輸是基于幀的，因此幀傳輸效率更高。 與長短輪詢相比，2個(gè)字節(jié)就可以代替871字節(jié)的Header。 測試結(jié)果是：
對(duì)于每秒相同數(shù)量的客戶端輪詢，當(dāng)頻率高達(dá)10W/s時(shí)，輪詢需要消耗665Mbps，而只有1.526Mbps，接近435倍。
它實(shí)現(xiàn)了real-time實(shí)時(shí)，節(jié)省了大量的帶寬資源，但是我理解它也有自己的問題，就是開發(fā)成本比較高。 這里的開發(fā)成本并不是指自己實(shí)現(xiàn)。 這可以直接使用 Netty 來完成——在 Java 語言層面，API 非常簡單，它提供了完整的實(shí)現(xiàn)，而真正的開發(fā)成本在于分布式環(huán)境中的數(shù)據(jù)同步問題。
比如有一個(gè)在線聊天系統(tǒng)，有10萬人同時(shí)在線。 這時(shí)，用戶發(fā)送一條1K的語音消息。 單機(jī)維持10W連接是可以的（這不是HTTP請(qǐng)求，所以不受連接池?cái)?shù)量的影響），問題出在帶寬上。 單機(jī)同時(shí)向10W用戶推送1K語音消息，至少需要10M帶寬。 這只是單純的把數(shù)據(jù)往外推，沒有考慮數(shù)據(jù)進(jìn)來的場景，實(shí)際操作過程需要更多的帶寬。 對(duì)于企業(yè)來說，這是一個(gè)很大的問題。 一個(gè)非常大的成本。
所以在連接數(shù)較多的場景下會(huì)使用集群（實(shí)際上即使連接數(shù)不多，也會(huì)為了高可用而使用集群）。 10W并發(fā)分布5臺(tái)機(jī)器，每臺(tái)機(jī)器平均有2W個(gè)連接。 考慮集群下會(huì)出現(xiàn)的問題：
Client 1將數(shù)據(jù)發(fā)送給Server 1，所有連接到Server 1的client都可以推送語音，但是問題是：
其他需要考慮的問題太多就不一一列舉了。 總而言之，在請(qǐng)求量大、并發(fā)高的場景下使用，代碼開發(fā)成本是非常高的。 但是由于它可以實(shí)現(xiàn)服務(wù)器到客戶端的實(shí)時(shí)數(shù)據(jù)推送，節(jié)省了大量的帶寬資源，所以IM、音視頻、彈幕等很多應(yīng)用都會(huì)用到它。
總結(jié)
以上就是本文的全部內(nèi)容。 希望本文的內(nèi)容對(duì)您的學(xué)習(xí)或工作有一定的參考學(xué)習(xí)價(jià)值。 有什么問題可以留言交流。 感謝您對(duì)場景 3 的支持。