服务器推送技术常用的三个解决方案分别是什么

本篇文章为大家展示了服务器推送技术常用的三个解决方案分别是什么，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

创新互联建站服务紧随时代发展步伐，进行技术革新和技术进步，经过10多年的发展和积累，已经汇集了一批资深网站策划师、设计师、专业的网站实施团队以及高素质售后服务人员，并且完全形成了一套成熟的业务流程，能够完全依照客户要求对网站进行成都网站制作、网站建设、建设、维护、更新和改版，实现客户网站对外宣传展示的首要目的，并为客户企业品牌互联网化提供全面的解决方案。

现在的app大多都有IM服务，在选择上无外乎有两种选择：一是自建IM服务，二是用第三方的云服务。

暂不表第三方的云服务如何如何。
在自建IM服务上，每家公司的选择往往逃不出下面的三个方案：
一是普通的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也要维持一套心跳服务上来推论。
前提条件：服务器端先维护一自增的消息id服务，不管是点聊消息和群聊消息，自增id不要用同一套（主要是基于两者的消息量上来考虑），但所有用户的点聊都用同一套自增的针点聊的消息id服务，所有用户的群聊消息都用同一套自增的针群聊的消息id服务。这样每发送的每一条消息都有一个唯一的id。注意：点聊消息和群聊消息都只存储一条，哪怕一个群内有2000个群成员，在数据库中存储的也只有一条消息记录。
ASLINE的服务器提供全国最先进、快速网络设计及国际顶级设备 。
免备案、速度快，受到国内站长的欢迎。为各类用户提供优质服务器，五星级式售后
免费重装系统，重启，系统测试
app端直接请求icomet服务（注意：app不是直接请求php或java或nodejs或其它服务），每个app端用户分配一个专用的icomet通道接收消息和提供长连接服务，由icomet服务来负责维持与app端的长连接。然后用php或java或其它语言负责往发送消息，还是以我熟悉的php为例，当php端接收到发送消息请求时，在处理完相关业务逻辑后，往消息接收方的icomet通道中推送消息(包括消息唯一id和具体消息内容等)，这样如果app端用户在线的话，且还维持着icomet的长连接的话，就能立即接收到消息。app端接收到消息后处理完成后再发起下次长连接请求（注意：app端接收到消息后没有回调告诉服务器端已接收到，没有回调，没有回调！重要的事说三遍！）。
或许会有这样的需求：要支持查看历史消息的功能，即使是换终端设备了，也要能支持查看历史消息。此时该如何进一步优化？
很简单：由于消息id都是自增的，只需要另开一个http消息查询接口，按消息id的大小往前或往后查询即可
app端调用php写的接口实现发消息功能，php负责处理相关业务逻辑，并把消息写入MongoDB和rabbitmq队列中写，然后由java与app端做的一套socket服务消费rabbitmq队列，来实现通知app端再调用php的消息查询接口去拉取消息。
单台服务器不可避免的问题
首先，要明白单台服务器常见的问题，无非就是并发、大数据、单点
并发问题：一个时间点，同时有海量用户去对服务器进行访问
大数据：例如海量数据的存储和传输（性能方面的问题）
单点问题：例如只有一台服务器，如果服务器出现故障了后果不堪设想。
针对以上问题，出现了以下几种解决方式（后面我这个博客会持续更新，目前我就了解两种）：
集群架构思想：
可以处理并发问题和单点问题，集群的目标是多台服务器做相同的业务处理，可以缓解用户的并发问题（也叫作负载均衡），同时因为多台服务器做相同的操作，所以一台挂了并不影响另一台的操作，所以可以避免单点问题。（以前使用apache做分布式集群负载均衡的前端服务器，现在流行Ngix做分布式集群负载均衡的前端服务器）。举个例子，集群就像大家用的笔记本电脑和外接键盘的关系，笔记本的键盘坏了，可以用外接键盘，提供持续服务，或者笔记本键盘没坏，用外接键盘可以更好的保护笔记本

今天为上与app配合做接口的经验也有三年了，现在的app大多都有IM服务，在选择上无外乎有两种选择：一是自建IM服务，二是用第三方的云服务。

暂不表第三方的云服务如何如何。
在自建IM服务上，每家公司的选择往往逃不出下面的三个方案：
一是普通的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也要维持一套心跳服务上来推论。
前提条件：服务器端先维护一自增的消息id服务，不管是点聊消息和群聊消息，自增id不要用同一套（主要是基于两者的消息量上来考虑），但所有用户的点聊都用同一套自增的针点聊的消息id服务，所有用户的群聊消息都用同一套自增的针群聊的消息id服务。这样每发送的每一条消息都有一个唯一的id。注意：点聊消息和群聊消息都只存储一条，哪怕一个群内有2000个群成员，在数据库中存储的也只有一条消息记录。
ASLINE的服务器提供全国最先进、快速网络设计及国际顶级设备 。
免备案、速度快，受到国内站长的欢迎。为各类用户提供优质服务器，五星级式售后
免费重装系统，重启，系统测试
app端直接请求icomet服务（注意：app不是直接请求php或java或nodejs或其它服务），每个app端用户分配一个专用的icomet通道接收消息和提供长连接服务，由icomet服务来负责维持与app端的长连接。然后用php或java或其它语言负责往发送消息，还是以我熟悉的php为例，当php端接收到发送消息请求时，在处理完相关业务逻辑后，往消息接收方的icomet通道中推送消息(包括消息唯一id和具体消息内容等)，这样如果app端用户在线的话，且还维持着icomet的长连接的话，就能立即接收到消息。app端接收到消息后处理完成后再发起下次长连接请求（注意：app端接收到消息后没有回调告诉服务器端已接收到，没有回调，没有回调！重要的事说三遍！）。
或许会有这样的需求：要支持查看历史消息的功能，即使是换终端设备了，也要能支持查看历史消息。此时该如何进一步优化？
很简单：由于消息id都是自增的，只需要另开一个http消息查询接口，按消息id的大小往前或往后查询即可
app端调用php写的接口实现发消息功能，php负责处理相关业务逻辑，并把消息写入mongodb和rabbitmq队列中写，然后由java与app端做的一套socket服务消费rabbitmq队列，来实现通知app端再调用php的消息查询接口去拉取消息。
单台服务器不可避免的问题
首先，要明白单台服务器常见的问题，无非就是并发、大数据、单点
并发问题：一个时间点，同时有海量用户去对服务器进行访问
大数据：例如海量数据的存储和传输（性能方面的问题）
单点问题：例如只有一台服务器，如果服务器出现故障了后果不堪设想。
针对以上问题，出现了以下几种解决方式（后面我这个博客会持续更新，目前我就了解两种）：
集群架构思想：
可以处理并发问题和单点问题，集群的目标是多台服务器做相同的业务处理，可以缓解用户的并发问题（也叫作负载均衡），同时因为多台服务器做相同的操作，所以一台挂了并不影响另一台的操作，所以可以避免单点问题。（以前使用apache做分布式集群负载均衡的前端服务器，现在流行Ngix做分布式集群负载均衡的前端服务器）。举个例子，集群就像大家用的笔记本电脑和外接键盘的关系，笔记本的键盘坏了，可以用外接键盘，提供持续服务，或者笔记本键盘没坏，用外接键盘可以更好的保护笔记本键盘不会加速衰老
集群的种类：
高可用集群：主要是为了保障用户的应用程序持久、不简单提供服务
负载均衡集群：可以做到把一个高负荷的应用分散到多个节点共同完成，适合业务繁忙、大负荷访问的系统
科学计算集群（HPC集群）：提供单个计算机不能提供的强大计算能力，追求与综合性能
分布式架构思想：
和集群的实现不同，集群是多台服务器集中实现同一种业务，而分布式则是把多台服务器集中在一起，每台服务器实现不同的业务，做不同的事情，并且缺一不可，如果一台服务器挂了，就有可能影响整个服务器的功能的运行。
分布式集群综合架构思想：
就如上面所述，集群有集群的好处，分布式有分布式的好处，可否做到两个架构进行合并呢，当然可以。我们可以让分布式的每一个节点都进行集群，这种架构通常叫做分布式集群架构。

键盘不会加速衰老
集群的种类：
高可用集群：主要是为了保障用户的应用程序持久、不简单提供服务
负载均衡集群：可以做到把一个高负荷的应用分散到多个节点共同完成，适合业务繁忙、大负荷访问的系统
科学计算集群（HPC集群）：提供单个计算机不能提供的强大计算能力，追求与综合性能
分布式架构思想：
和集群的实现不同，集群是多台服务器集中实现同一种业务，而分布式则是把多台服务器集中在一起，每台服务器实现不同的业务，做不同的事情，并且缺一不可，如果一台服务器挂了，就有可能影响整个服务器的功能的运行。
分布式集群综合架构思想：
就如上面所述，集群有集群的好处，分布式有分布式的好处，可否做到两个架构进行合并呢，当然可以。我们可以让分布式的每一个节点都进行集群，这种架构通常叫做分布式集群架构。

上述内容就是服务器推送技术常用的三个解决方案分别是什么，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注创新互联行业资讯频道。