服务器推送技术常用解决方案有哪些？服务器推送方式有哪些？

  服务器推送技术指的是在服务器端和客户端建立链接，这样客户端就可以随时接受服务器发送的信息了，比如可以使用服务器推送技术发送电子邮件都能够，现在的服务器推送技术解决方案比较多，大家对服务器推送技术解决方案也有一个评价的标准，下面就给朋友们详细的来介绍一下服务器推送技术常用解决方案有哪些以及服务器推送方式有哪些等问题。

  服务器推送的四种方式，作为架构师的你全了解吗？
  常用的服务器推送方式，大致分为四种。
  1.短轮询：在客户端，定时的去请求服务器中，然后刷新信息到客户端页面。一般互联网业界的标准是5秒。
  2.长轮询：客户端向服务器发送Ajax请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的请求。
  原理是servlet的异步请求长连接。也就是说，异步请求中在原始的请求返回的时候并没有关闭连接，关闭的只是处理请求的那个线程（一般是回收的线程池里了），只有在异步请求全部处理完之后才会关闭连接。
  具体实现技术spring提供 DeferredResult方式。可以允许容器线程快速释放以便可以接受更多的请求提升吞吐量，让真正的业务逻辑在其他的工作线程中去完成。
  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（节省）
  省电应注意CPU休眠，一般用服务缩短待机时间百分比评判。
  省流量应注意协议的修改和冗余数据包的处理，一般用空载待机月流量评判。
  省成本应考虑单服务器承载同时连接数，可承载同时连接数越多成本越低，业内 顶尖水平为个推的单服务器50万连接。
  Slim（体积小）

  推送服务应该体积尽量小，不影响主程序的大小和复杂度，一般以小于300K为宜。

  服务器推送技术常用解决方案有哪些？以上就给大家介绍了关于服务器推送技术解决方案的问题，当前比较常见的服务器推送技术常见解决方案有三种，对于这些解决方案，大家还需要知道评价的方法，比如是不是安全、稳定，是不是可以节省流程等，如果大家还有疑问，可以咨询。