服務(wù)器推送技術(shù)常用解決方案有哪些?服務(wù)器推送方式有哪些?
服務(wù)器推送技術(shù)指的是在服務(wù)器端和客戶(hù)端建立鏈接,這樣客戶(hù)端就可以隨時(shí)接受服務(wù)器發(fā)送的信息了,比如可以使用服務(wù)器推送技術(shù)發(fā)送電子郵件都能夠,現(xiàn)在的服務(wù)器推送技術(shù)解決方案比較多,大家對(duì)服務(wù)器推送技術(shù)解決方案也有一個(gè)評(píng)價(jià)的標(biāo)準(zhǔn),下面新網(wǎng)就給朋友們?cè)敿?xì)的來(lái)介紹一下服務(wù)器推送技術(shù)常用解決方案有哪些以及服務(wù)器推送方式有哪些等問(wèn)題。
常用的服務(wù)器推送方式,大致分為四種。
1.短輪詢(xún):在客戶(hù)端,定時(shí)的去請(qǐng)求服務(wù)器中,然后刷新信息到客戶(hù)端頁(yè)面。一般互聯(lián)網(wǎng)業(yè)界的標(biāo)準(zhǔn)是5秒。
2.長(zhǎng)輪詢(xún):客戶(hù)端向服務(wù)器發(fā)送Ajax請(qǐng)求,服務(wù)器接到請(qǐng)求后hold住連接,直到有新消息才返回響應(yīng)信息并關(guān)閉連接,客戶(hù)端處理完響應(yīng)信息后再向服務(wù)器發(fā)送新的請(qǐng)求。
原理是servlet的異步請(qǐng)求長(zhǎng)連接。也就是說(shuō),異步請(qǐng)求中在原始的請(qǐng)求返回的時(shí)候并沒(méi)有關(guān)閉連接,關(guān)閉的只是處理請(qǐng)求的那個(gè)線(xiàn)程(一般是回收的線(xiàn)程池里了),只有在異步請(qǐng)求全部處理完之后才會(huì)關(guān)閉連接。
具體實(shí)現(xiàn)技術(shù)spring提供 DeferredResult方式??梢栽试S容器線(xiàn)程快速釋放以便可以接受更多的請(qǐng)求提升吞吐量,讓真正的業(yè)務(wù)邏輯在其他的工作線(xiàn)程中去完成。
3.sse( Server-sent Events )是 WebSocket 的一種輕量代替方案,使用 HTTP 協(xié)議。SSE 是單向通道,只能服務(wù)器向客戶(hù)端發(fā)送消息,如果客戶(hù)端需要向服務(wù)器發(fā)送消息,則需要一個(gè)新的 HTTP 請(qǐng)求。
4.websocket : 全雙工的,長(zhǎng)連接。
一是普通的http解決方案:app端通用http服務(wù)定時(shí)拉取消息,比例每隔3秒,雖然你和我可能都很鄙視這個(gè)方案,但確實(shí)有公司在用。
二是基于comet的解決方案(其實(shí)也是基于http):app端通過(guò)comet服務(wù)拉取消息,即app端發(fā)起一次http請(qǐng)求,然后服務(wù)端檢查有無(wú)待接收的消息,如果有立即返回給app端,如果無(wú),則把當(dāng)前http請(qǐng)示掛起多少多少秒,如30秒,在這30秒內(nèi),如果他人給當(dāng)前的app用戶(hù)發(fā)送消息,服務(wù)端能在這30秒任意一點(diǎn)立即結(jié)束當(dāng)前掛起的http請(qǐng)求,并把消息一起返回給app端。此方案我熟悉的有icomet服務(wù)。
三是socket解決方案:app端通過(guò)socket與服務(wù)端通信,目前比較常用的服務(wù)端socket解決方案有nodejs,swoole,workerman等等。一般游戲類(lèi)app服務(wù)端和app端采用此方案的比較多。
在耗電量和耗流量上第一個(gè)是最耗電的,第二個(gè)次之,第三個(gè)是最優(yōu),但通過(guò)下面的設(shè)計(jì)方案,第二個(gè)方案和第三個(gè)在耗電量和耗流量上差別不大:主要理由是考慮到用戶(hù)在線(xiàn)的時(shí)長(zhǎng)及socket也要維持一套心跳服務(wù)上來(lái)推論。
推送方案的公認(rèn)評(píng)價(jià)采取4s標(biāo)準(zhǔn):
Safe (安全)
推送方案應(yīng)支持透?jìng)骷案鞣N加密方案,保障信息傳遞安全。
推送方案的ID系統(tǒng)應(yīng)該獨(dú)立于已有的網(wǎng)站或服務(wù)的ID系統(tǒng),這樣保障用戶(hù)在不同手機(jī)上登錄后的信息投遞準(zhǔn)確性,避免因?yàn)槿∠壎ㄊ录∫蚓W(wǎng)絡(luò)傳輸而造成的信息誤投送。
Stable(穩(wěn)定)
穩(wěn)定包括兩個(gè)部分一個(gè)是服務(wù)器端的穩(wěn)定性,一個(gè)是手機(jī)端的穩(wěn)定性。
服務(wù)端穩(wěn)定性,因?yàn)槭褂瞄L(zhǎng)連接方案,對(duì)服務(wù)器的開(kāi)銷(xiāo)和要求很大,推送方案對(duì)服務(wù)器開(kāi)發(fā)要求很高,海量線(xiàn)程連接下的服務(wù)器穩(wěn)定性是非常具有挑戰(zhàn)性的。一般的評(píng)判標(biāo)準(zhǔn)包括:
- 同時(shí)在線(xiàn)時(shí)峰值 (一般按照百萬(wàn)并發(fā)連接時(shí)服務(wù)器穩(wěn)定性評(píng)測(cè));
- 高并發(fā)時(shí)消息平均延遲時(shí)間(一般按照1分鐘處理1百萬(wàn)條信息評(píng)測(cè));
- 服務(wù)穩(wěn)定性 (一般要求全年99.9%以上可用,有備份,有負(fù)載均衡等);
鑒于服務(wù)器穩(wěn)定的開(kāi)發(fā)難度很大,小團(tuán)隊(duì)不建議自己開(kāi)發(fā),建議使用穩(wěn)定的第三方推送方案等。
Save(節(jié)省)
省電應(yīng)注意CPU休眠,一般用服務(wù)縮短待機(jī)時(shí)間百分比評(píng)判。
省流量應(yīng)注意協(xié)議的修改和冗余數(shù)據(jù)包的處理,一般用空載待機(jī)月流量評(píng)判。
省成本應(yīng)考慮單服務(wù)器承載同時(shí)連接數(shù),可承載同時(shí)連接數(shù)越多成本越低,業(yè)內(nèi) 頂尖水平為個(gè)推的單服務(wù)器50萬(wàn)連接。
Slim(體積?。?br />
推送服務(wù)應(yīng)該體積盡量小,不影響主程序的大小和復(fù)雜度,一般以小于300K為宜。
聲明:免責(zé)聲明:本文內(nèi)容由互聯(lián)網(wǎng)用戶(hù)自發(fā)貢獻(xiàn)自行上傳,本網(wǎng)站不擁有所有權(quán),也不承認(rèn)相關(guān)法律責(zé)任。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容,請(qǐng)發(fā)
送郵件至:operations@xinnet.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),本站將立刻刪除涉嫌侵權(quán)內(nèi)容。本站原創(chuàng)內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)
需注明出處:新網(wǎng)idc知識(shí)百科