服務器推送技術常用解決方案有哪些？服務器推送方式有哪些？

  服務器推送技術指的是在服務器端和客戶端建立鏈接，這樣客戶端就可以隨時接受服務器發送的信息了，比如可以使用服務器推送技術發送電子郵件都能夠，現在的服務器推送技術解決方案比較多，大家對服務器推送技術解決方案也有一個評價的標準，下面新網就給朋友們詳細的來介紹一下服務器推送技術常用解決方案有哪些以及服務器推送方式有哪些等問題。

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

  4.websocket : 全雙工的，長連接。

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

  在耗電量和耗流量上第一個是最耗電的，第二個次之，第三個是最優，但通過下面的設計方案，第二個方案和第三個在耗電量和耗流量上差別不大：主要理由是考慮到用戶在線的時長及socket也要維持一套心跳服務上來推論。

  服務器推送技術解決方案評價標準
  推送方案的公認評價采取4s標準：
  Safe (安全)
  推送方案應支持透傳及各種加密方案，保障信息傳遞安全。
  推送方案的ID系統應該獨立于已有的網站或服務的ID系統，這樣保障用戶在不同手機上登錄后的信息投遞準確性，避免因為取消綁定事件失敗因網絡傳輸而造成的信息誤投送。
  Stable（穩定）
  穩定包括兩個部分一個是服務器端的穩定性，一個是手機端的穩定性。
  服務端穩定性，因為使用長連接方案，對服務器的開銷和要求很大，推送方案對服務器開發要求很高，海量線程連接下的服務器穩定性是非常具有挑戰性的。一般的評判標準包括：
  - 同時在線時峰值 （一般按照百萬并發連接時服務器穩定性評測）；
  - 高并發時消息平均延遲時間（一般按照1分鐘處理1百萬條信息評測）；
  - 服務穩定性 （一般要求全年99.9%以上可用，有備份，有負載均衡等）；
  鑒于服務器穩定的開發難度很大，小團隊不建議自己開發，建議使用穩定的第三方推送方案等。
  Save（節?。?br />  省電應注意CPU休眠，一般用服務縮短待機時間百分比評判。
  省流量應注意協議的修改和冗余數據包的處理，一般用空載待機月流量評判。
  省成本應考慮單服務器承載同時連接數，可承載同時連接數越多成本越低，業內 頂尖水平為個推的單服務器50萬連接。
  Slim（體積?。?br />

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

  服務器推送技術常用解決方案有哪些？以上就給大家介紹了關于服務器推送技術解決方案的問題，當前比較常見的服務器推送技術常見解決方案有三種，對于這些解決方案，大家還需要知道評價的方法，比如是不是安全、穩定，是不是可以節省流程等，如果大家還有疑問，可以咨詢新網。