一种基于单台服务器的消息推送方法及其装置与流程

文档序号:17627373发布日期:2019-05-10 23:48阅读:230来源:国知局
一种基于单台服务器的消息推送方法及其装置与流程

本申请涉及计算机领域,尤其涉及一种基于单台服务器的消息推送方法及其装置。



背景技术:

目前,单台服务器推送消息的推送量在百万级。为了突破这个极限,大多是采用部署集群的方式,极大的增加了预算和成本。

举例来说,若服务器需要给终端甲和终端乙,主动推送消息,100万终端在线维护在集合中,在推送消息时即需要遍历整个集合,从100万终端中查询到终端甲和终端乙的信息,并顺序发送消息,耗时极长;且消息推送期间,集合中维护的客户端仍旧正常的上下线,集合面临不停的修改,有修改需要重新遍历,所以集合需要上锁,上锁也会增加消息推送的耗时;此外,服务器与终端之间通过json格式通信,而json编码非常消耗cpu资源,若服务器给100万终端推送一次消息则需要100万次json编码,进一步消耗了cpu资源,增加了推送时间。

因此,如何使得单台服务器的消息推送,减少cpu资源的消耗,减少消息的推送时间,显得尤为重要。



技术实现要素:

为了解决上述问题,本申请提出一种基于单台服务器的消息推送方法,该方法能够减少cpu资源的消耗,减少消息的推送时间。

本申请第一方面提供一种基于单台服务器的消息推送方法,所述方法包括:服务器接收第一终端发送的多条消息,其中,所述多条消息为所述服务器从接收消息的时刻开始到预定时间之内接收到的所有消息;

将所述多条消息合并成第一消息,所述第一消息包括目标终端信息;

遍历第一集合,得到所述第一消息对应的路径配置信息;其中,所述第一集合包括所有与服务器相连接的终端的路径配置信息以及相应目标终端信息,所述路径配置信息用于指示相应消息的传输路径;

所述服务器通过所述第一集合与至少一个目标终端建立连接。

在一种可能的实施方式中,所述方法还包括:所述服务器将所述第一集合分为多个第二集合,其中,所述第一集合存储的目标终端信息量和其对应消息的路径配置信息量,大于所述第二集合存储的目标终端信息量和其对应消息的路径配置信息量。

在一种可能的实施方式中,遍历第一集合,得到所述第一消息对应的路径配置信息,具体为:所述服务器同时遍历所述多个第二集合,得到所述第一消息对应的路径配置信息。

在一种可能的实施方式中,所述服务器将第一集合分为多个第二集合,具体为:根据在线目标终端的数量,将所述第一集合划分为多个第二集合。

在一种可能的实施方式中,所述第二集合存储的目标终端信息的数量小于或等于五万条。

在一种可能的实施方式中,所述服务器将所述至少一条消息合并成第一消息,之后,所述方法还包括:所述服务器将所述第一消息进行json格式的编码。

在一种可能的实施方式中,所述预定时间为一秒。

本申请第二方面提供一种基于单台服务器的消息推送装置,所述装置包括接收单元、合并单元、遍历单元以及处理单元;其中,

所述接收单元,用于接收第一终端发送的多条消息,其中,所述多条消息为所述服务器从接收消息的时刻开始到预定时间之内接收到的所有消息;

所述合并单元,用于将所述多条消息合并成第一消息,所述第一消息包括目标终端信息;

所述遍历单元,用于遍历第一集合,得到所述第一消息对应的路径配置信息;其中,所述第一集合包括所有与服务器相连接的终端的路径配置信息以及相应目标终端信息,所述路径配置信息用于指示相应消息的传输路径;

所述处理单元,用于通过所述第一集合与至少一个目标终端建立连接。

在一种可能的实施方式中,所述处理单元,还用于根据在线目标终端的数量,将所述第一集合划分为多个第二集合;其中,所述第一集合存储的目标终端信息量和其对应消息的路径配置信息量,大于所述第二集合存储的目标终端信息量和其对应消息的路径配置信息量。

在一种可能的实施方式中,所述遍历单元遍历第一集合,得到所述第一消息对应的路径配置信息,具体为:所述遍历单元同时遍历所述多个第二集合,得到所述第一消息对应的路径配置信息。

本申请中的服务器通过将一秒内的多条消息合并成一条消息,合并后每秒推送数等于在线连接数;同时将大集合划分为多个小集合,每个集合都有自己的锁,多线程并发遍历,小集合之间避免了锁竞争;读写锁取代互斥锁,多个推送任务可以并发遍历相同集合;且减少重复计算,n条消息合并成一条消息,只需要编码一次;从而避免大量的系统计算,以减少系统运算开销,减少消息的推送时间。

附图说明

此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。

图1为本申请实施例提供的一种基于单台服务器的消息推送方法流程示意图;

图2为本申请实施例提供的一种基于单台服务器的消息推送装置结构示意图。

具体实施方式

为了更清楚的阐释本申请的整体构思,下面结合说明书附图以示例的方式进行详细说明。

下文为了描述方便,“第一”“第二”仅仅是对名词进行区分,不应理解为对专业词的限定作用。

本申请实施例中,终端是指能够用浏览器上网,和/或能够按照客户端软件的设备,包括手机、平板电脑等。

如图1所示,一种基于单台服务器的消息推送方法,该方法包括步骤s101-s104。

s101,服务器接收第一终端发送的多条消息,其中,所述多条消息为所述服务器从接收消息的时刻开始到预定时间之内接收到的所有消息。

该步骤中,第一终端为权限高的终端,例如公司管理人员可以通过该第一终端发送通知消息,或者设备的升级指令。

此外,第一终端的数量,这里并不做限制,可以为一个或多个终端;即一位或多位用户可以通过一个或多个第一终端发送消息给服务器。

s102,将所述多条消息合并成第一消息,所述第一消息包括目标终端信息。

第一消息包括目标终端信息,即消息的发送对象。

s103,遍历第一集合,得到所述第一消息对应的路径配置信息;其中,所述第一集合包括所有与服务器相连接的终端的路径配置信息以及相应目标终端信息,所述路径配置信息用于指示相应消息的传输路径。

在一个示例中,所述方法还包括:所述服务器将所述第一集合分为多个第二集合,其中,所述第一集合存储的目标终端信息量和其对应消息的路径配置信息量,大于所述第二集合存储的目标终端信息量和其对应消息的路径配置信息量。

在一个示例中,遍历第一集合,得到所述第一消息对应的路径配置信息,具体为:所述服务器同时遍历所述多个第二集合,得到所述第一消息对应的路径配置信息。

在一个示例中,所述服务器将第一集合分为多个第二集合,具体为:根据在线目标终端的数量,将所述第一集合划分为多个第二集合。

在一个示例中,所述第二集合存储的目标终端信息的数量小于或等于五万条。

s104,所述服务器通过所述第一集合与至少一个目标终端建立连接。

在一个示例中,所述服务器将所述至少一条消息合并成第一消息,之后,所述方法还包括:所述服务器将所述第一消息进行json格式的编码。

此时,n条消息合并成一条消息,大大减少了json编码的次数,降低了cpu的运算开销。

在一个示例中,所述预定时间为一秒。

如图2所示,一种基于单台服务器的消息推送装置,该装置包括接收单元、合并单元、遍历单元以及处理单元。

接收单元,用于接收第一终端发送的多条消息,其中,所述多条消息为所述服务器从接收消息的时刻开始到预定时间之内接收到的所有消息。

合并单元,用于将所述多条消息合并成第一消息,所述第一消息包括目标终端信息。

遍历单元,用于遍历第一集合,得到所述第一消息对应的路径配置信息;其中,所述第一集合包括所有与服务器相连接的终端的路径配置信息以及相应目标终端信息,所述路径配置信息用于指示相应消息的传输路径。

处理单元,用于通过所述第一集合与至少一个目标终端建立连接。

在一个示例中,所述处理单元,还用于根据在线目标终端的数量,将所述第一集合划分为多个第二集合;其中,所述第一集合存储的目标终端信息量和其对应消息的路径配置信息量,大于所述第二集合存储的目标终端信息量和其对应消息的路径配置信息量。

在一个示例中,所述遍历单元遍历第一集合,得到所述第一消息对应的路径配置信息,具体为:所述遍历单元同时遍历所述多个第二集合,得到所述第一消息对应的路径配置信息。同时遍历多个集合,能减少消息的推送时间。

本申请中的服务器通过将一秒内的多条消息合并成一条消息,合并后每秒推送数等于在线连接数;同时将大集合划分为多个小集合,每个集合都有自己的锁,多线程并发遍历,小集合之间避免了锁竞争;读写锁取代互斥锁,多个推送任务可以并发遍历相同集合;且减少重复计算,n条消息合并成一条消息,只需要编码一次;从而避免大量的系统计算,以减少系统运算开销,减少消息的推送时间。

本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。

下面对本申请方案的效果进行说明。

通过一台服务器进行测试服务器配置,cpu核数4,内存16g、文件描述符大小1048576,ip数量1,系统版本centoslinuxrelease7.4.1708(core)。

假如有100万用户在线,通过传统方法进行推送测试。推送10条消息,推送完成时间在500s,下发消息时cpu消耗在80%-100%左右,消息的到达率在98%以上,消耗占用计算机cpu开销太大,影响计算机的稳定运行。

使用相同配置的单台服务器,使用上述实施例中的方法进行测试。100万用户在线进行推送测试,推送10条消息,推送完成时间在200s,下发消息时cpu消耗在60%-80%左右,消息的到达率在98%以上。

对比可知,传统的推送方法消耗cpu巨大,而且随着消息和在线用户的增多,cpu开销也随之加大。

通过本申请实施例中的方案,能够减小cpu消耗同时也减小了推送时间。

专业人员应该还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。

以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1