丨輪詢與長(zhǎng)連接如何解決消息的實(shí)時(shí)到達(dá)問題

當(dāng)然這一方面得益于快速發(fā)展的移動(dòng)網(wǎng)絡(luò)，讓網(wǎng)絡(luò)延遲越來越低、網(wǎng)絡(luò)帶寬越來越高；另一個(gè)重要原因是：社交網(wǎng)絡(luò)Ap在實(shí)時(shí)性提升方面的技術(shù)，也在不斷升級(jí)迭代。實(shí)時(shí)性主要解決的問題是：當(dāng)一條消息發(fā)出后，我們的系統(tǒng)如何確保這條消息最快被接收人感知并獲取到，并且盡量讓耗費(fèi)的資源較少。這里關(guān)鍵的幾個(gè)點(diǎn)是：最快觸達(dá)，且耗費(fèi)資源少。想好了嗎？下面我們來看一看，IM在追求“消息實(shí)時(shí)性”的架構(gòu)上，所經(jīng)歷過的幾在PCWeb的早期時(shí)代，對(duì)于數(shù)據(jù)的獲取，大部分應(yīng)用采用一問一答的“請(qǐng)求響應(yīng)”式模式，實(shí)際上，像現(xiàn)在我們?yōu)g覽大部分門戶的，以及刷其實(shí)都是采用的“請(qǐng)求響IMQPS（每秒查正是由于“短輪詢”存在著高頻無用功的問題，為了避免這個(gè)問題，IM長(zhǎng)輪詢和短輪詢相比，一個(gè)最大的改進(jìn)之處在于：短輪詢模式下，服務(wù)端不管本輪有沒有新消息產(chǎn)生，都會(huì)馬上響應(yīng)并返回。而長(zhǎng)輪詢模式當(dāng)本次請(qǐng)求沒有獲取到新消息時(shí)，并不會(huì)馬上結(jié)束返回，而是會(huì)在服務(wù)端“懸掛（hang）”，等待一段時(shí)間；如果在等待的這段時(shí)間內(nèi)有新消息產(chǎn)生，就能馬上響應(yīng)返回。開銷和功耗開銷，也降低了服務(wù)端處理請(qǐng)求的QPS，相比短輪詢模式而言，顯得更加先服務(wù)端懸掛（hang）住請(qǐng)求，只是降低了請(qǐng)求的QPS，并沒有減少對(duì)后端資源輪詢的壓力。假1000個(gè)請(qǐng)求在等待消息，可能意味著有1000個(gè)線程在不斷輪詢消這里的根本原因在于短輪詢和長(zhǎng)輪詢是基于HTTP協(xié)議實(shí)現(xiàn)的，由于HTTP是一個(gè)無狀態(tài)隨著HTML5WebSocket這就像之前信件處理的邏輯，等待收信的用戶不需要每天都跑到郵局去詢問，而只要在郵局登記好自己家里的地址。等真正有信件時(shí)，郵局會(huì)派專門的郵遞員按照登記的地址來把信送過去。WebSocket隨著HTML5的出現(xiàn)，基于單個(gè)TCP連接的全雙工通信的協(xié)議WebSocket在2011年成為RFC標(biāo)準(zhǔn)協(xié)議，逐漸代替了短輪詢和長(zhǎng)輪詢的方式，而且由于WebSocket協(xié)議獲得了WebIMWebIM和短輪詢、長(zhǎng)輪詢相比，基于WebSocet實(shí)現(xiàn)的IM服務(wù)，客戶端和服務(wù)端只需要完成一次握手，就可以創(chuàng)建持久的長(zhǎng)連接，并進(jìn)行隨時(shí)的雙向數(shù)據(jù)傳輸。當(dāng)服務(wù)端接收到新消息時(shí)，可以通過建立的WebSocet連接，直接進(jìn)行推送，真正做到“邊緣觸發(fā)”，也保證了消息到達(dá)的實(shí)時(shí)性。WebSocketWebTCP長(zhǎng)連接衍生的IMWebSocketIMTCP議，如XMPP協(xié)議、MQTT協(xié)議以及各種私有協(xié)議。這些基于TCP長(zhǎng)連接的通信協(xié)議，在用戶上線連接時(shí)，在服務(wù)端好連接到服務(wù)器的用戶設(shè)備和具體TCP連接的映射關(guān)系，通過這種方式客戶端能夠隨時(shí)找到服務(wù)端，服務(wù)端也個(gè)用戶時(shí)，就能簡(jiǎn)單地通過這個(gè)長(zhǎng)連接實(shí)現(xiàn)“服務(wù)端實(shí)時(shí)推送”了。但是上面提到的這些私有協(xié)議都各有優(yōu)缺點(diǎn)，如：XMPP協(xié)議雖然比較成熟、擴(kuò)展性也不錯(cuò)，但基于XML格式的協(xié)議傳輸上冗余比較多，在流量方面不太友好，而且整體實(shí)現(xiàn)上比而輕量級(jí)的MQTT基于的“發(fā)布/訂閱”模式，在省流量和擴(kuò)展性方面都比較突出，在很多消息推送場(chǎng)景下被廣泛使用，但這個(gè)協(xié)議并不是IM領(lǐng)域的專有協(xié)議，因此對(duì)于很多IM下的個(gè)性化業(yè)務(wù)場(chǎng)景仍然需要大量復(fù)雜的擴(kuò)展和開發(fā)，比如不支持群組功能、不支持離因此，對(duì)于開發(fā)人力相對(duì)充足的大廠，目前很多是基于TCP（或者UDP）來實(shí)現(xiàn)自己的私有協(xié)議，一方面私有協(xié)議能夠貼合業(yè)務(wù)需要，做到真正的高效和省流；另一方面私有協(xié)議相對(duì)安全性更高一些，被的可能性小。目前主流的大廠很多都是采用私有協(xié)議為主的方式來實(shí)現(xiàn)。隨著HTML5WebSocketTCP最后給你留一個(gè)思考題，TCP 售賣。頁面已增加防盜追蹤 上一 02|消息收發(fā)架構(gòu)：為你的App，加上實(shí)時(shí)通信功TCP答：首先用戶有一個(gè)登陸的過程：(1)tcp客戶端與服務(wù)端通過三次握手建立tcp連接；(2)當(dāng)前用戶的uid和標(biāo)識(shí)當(dāng)前tcp連接的socket描述符(也就是fd)建立映射關(guān)系；(4)這個(gè)映…3服務(wù)器一個(gè)hashmapkey是userid，value是socketinstance，這樣用戶A發(fā)給用戶B的信息里邊含有用戶B的id，用usedBid到hashmap里邊查到用戶B的socket就可果需要多臺(tái)機(jī)器，如果用戶A的socker和用戶B的socket不在一臺(tái)機(jī)器上，這樣怎么解決作者回復(fù):一種法是用上線時(shí)一個(gè)局的i網(wǎng)關(guān)機(jī)映，發(fā)的候能到確定位；另式：下發(fā)把所有息下發(fā)所機(jī)器，每機(jī)器如發(fā)現(xiàn)當(dāng)用戶連在本7 3作者回復(fù):可以無狀態(tài)，一種法是用上線一個(gè)局的i網(wǎng)機(jī)映，發(fā)的時(shí)候就能到精確位；另式：下發(fā)把有消息下給所有器，每機(jī)器如發(fā)現(xiàn)1和4 12 1作者回復(fù):防止客戶端的連接是比較的哈，比如你的app源代碼了，稍微改一改就能1 作者回復(fù):基于1 4 請(qǐng)問，XMPP是基于XML格式的協(xié)議，那像 最近用aa做了一個(gè)與物聯(lián)網(wǎng)設(shè)備的連接應(yīng)用，是將連接到map中，然后通過設(shè)備的唯一標(biāo)識(shí)為y從中取出連接。將每一個(gè)指令狀態(tài)存到了db中。但這就會(huì)有種情況發(fā)生，當(dāng)連接數(shù)量過大時(shí)，的服務(wù)器端u決？2 HTTP22￣???請(qǐng)問本課寫的demo是基于mqtt用戶使用客戶端與服務(wù)器建立連接時(shí)攜帶了userid與i