服務(wù)器推送技術(shù)指的是在服務(wù)器端和客戶端建立鏈接，這樣客戶端就可以隨時(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ì)的來介紹一下服務(wù)器推送技術(shù)常用解決方案有哪些以及服務(wù)器推送方式有哪些等問題。

  服務(wù)器推送的四種方式，作為架構(gòu)師的你全了解嗎？
  常用的服務(wù)器推送方式，大致分為四種。
  1.短輪詢：在客戶端，定時(shí)的去請(qǐng)求服務(wù)器中，然后刷新信息到客戶端頁(yè)面。一般互聯(lián)網(wǎng)業(yè)界的標(biāo)準(zhǔn)是5秒。
  2.長(zhǎng)輪詢：客戶端向服務(wù)器發(fā)送Ajax請(qǐng)求，服務(wù)器接到請(qǐng)求后hold住連接，直到有新消息才返回響應(yīng)信息并關(guān)閉連接，客戶端處理完響應(yīng)信息后再向服務(wù)器發(fā)送新的請(qǐng)求。
  原理是servlet的異步請(qǐng)求長(zhǎng)連接。也就是說，異步請(qǐng)求中在原始的請(qǐng)求返回的時(shí)候并沒有關(guān)閉連接，關(guān)閉的只是處理請(qǐng)求的那個(gè)線程（一般是回收的線程池里了），只有在異步請(qǐng)求全部處理完之后才會(huì)關(guān)閉連接。
  具體實(shí)現(xiàn)技術(shù)spring提供 DeferredResult方式?？梢栽试S容器線程快速釋放以便可以接受更多的請(qǐng)求提升吞吐量，讓真正的業(yè)務(wù)邏輯在其他的工作線程中去完成。
  3.sse（ Server-sent Events ）是 WebSocket 的一種輕量代替方案，使用 HTTP 協(xié)議。SSE 是單向通道，只能服務(wù)器向客戶端發(fā)送消息，如果客戶端需要向服務(wù)器發(fā)送消息，則需要一個(gè)新的 HTTP 請(qǐng)求。

  4.websocket : 全雙工的，長(zhǎng)連接。

  服務(wù)器推送技術(shù)常用的三個(gè)解決方案
  一是普通的http解決方案：app端通用http服務(wù)定時(shí)拉取消息，比例每隔3秒，雖然你和我可能都很鄙視這個(gè)方案，但確實(shí)有公司在用。
  二是基于comet的解決方案(其實(shí)也是基于http）：app端通過comet服務(wù)拉取消息，即app端發(fā)起一次http請(qǐng)求，然后服務(wù)端檢查有無待接收的消息，如果有立即返回給app端，如果無，則把當(dāng)前http請(qǐng)示掛起多少多少秒，如30秒，在這30秒內(nèi)，如果他人給當(dāng)前的app用戶發(fā)送消息，服務(wù)端能在這30秒任意一點(diǎn)立即結(jié)束當(dāng)前掛起的http請(qǐng)求，并把消息一起返回給app端。此方案我熟悉的有icomet服務(wù)。
  三是socket解決方案：app端通過socket與服務(wù)端通信，目前比較常用的服務(wù)端socket解決方案有nodejs，swoole，workerman等等。一般游戲類app服務(wù)端和app端采用此方案的比較多。

  在耗電量和耗流量上第一個(gè)是最耗電的，第二個(gè)次之，第三個(gè)是最優(yōu)，但通過下面的設(shè)計(jì)方案，第二個(gè)方案和第三個(gè)在耗電量和耗流量上差別不大：主要理由是考慮到用戶在線的時(shí)長(zhǎng)及socket也要維持一套心跳服務(wù)上來推論。

  服務(wù)器推送技術(shù)解決方案評(píng)價(jià)標(biāo)準(zhǔn)
  推送方案的公認(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)，這樣保障用戶在不同手機(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ù)器的開銷和要求很大，推送方案對(duì)服務(wù)器開發(fā)要求很高，海量線程連接下的服務(wù)器穩(wěn)定性是非常具有挑戰(zhàn)性的。一般的評(píng)判標(biāo)準(zhǔn)包括：
  - 同時(shí)在線時(shí)峰值 （一般按照百萬并發(fā)連接時(shí)服務(wù)器穩(wěn)定性評(píng)測(cè)）；
  - 高并發(fā)時(shí)消息平均延遲時(shí)間（一般按照1分鐘處理1百萬條信息評(píng)測(cè)）；
  - 服務(wù)穩(wěn)定性 （一般要求全年99.9%以上可用，有備份，有負(fù)載均衡等）；
  鑒于服務(wù)器穩(wěn)定的開發(fā)難度很大，小團(tuán)隊(duì)不建議自己開發(fā)，建議使用穩(wěn)定的第三方推送方案等。
  Save（節(jié)?。?br />   省電應(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萬連接。
  Slim（體積?。?br />

  推送服務(wù)應(yīng)該體積盡量小，不影響主程序的大小和復(fù)雜度，一般以小于300K為宜。

  服務(wù)器推送技術(shù)常用解決方案有哪些？以上就給大家介紹了關(guān)于服務(wù)器推送技術(shù)解決方案的問題，當(dāng)前比較常見的服務(wù)器推送技術(shù)常見解決方案有三種，對(duì)于這些解決方案，大家還需要知道評(píng)價(jià)的方法，比如是不是安全、穩(wěn)定，是不是可以節(jié)省流程等，如果大家還有疑問，可以咨詢新網(wǎng)。