掌桥专利:专业的专利平台
掌桥专利
首页

一种消息推送管理方法及系统

文献发布时间:2023-06-19 19:27:02


一种消息推送管理方法及系统

技术领域

本申请涉及大数据技术领域,具体涉及一种消息推送管理方法及系统。

背景技术

随着互联网通信的发展,通信设备逐渐变得多元化。早期主要以PC端为主的网络通信方式,如今移动通信设备的通信方式变为主流,人与人之间信息交流也不仅限于电话和短信,基于互联网方式的如邮箱,移动APP,即时聊天软件等变得更加普遍。

在现有的计算机系统中,即时消息推送主要推送特定用户客户端,如PC客户端可以及时收到系统发送的通知消息,并且通知方式也比较单一,仅是简单的文字描述。用户没办法控制是否接受指定业务特征的通知消息。在现有的计算机系统中,由于缺乏对消息推送制定合理的推送策略,用户会存在消息频繁接收某些特定的业务消息,相反的情况,用户消息丢失,存在消息漏发和补发问题,缺少一个合理对消息异常的处理机制。

发明内容

鉴于上述问题,本申请提供了一种消息推送管理方法,用于解决上述存在消息频繁接收或漏发的技术问题。

为实现上述目的,发明人提供了一种消息推送管理方法,包括以下步骤:

配置交换机和多个消息队列,所述消息队列与所述交换机绑定,所述消息具有业务特征和业务权限标识,每种业务特征的消息对应一种所述消息队列;

转发服务器接收所述消息,识别所述消息的业务特征,并将所述消息根据业务特征压入对应的所述消息队列中进行推送;

推送服务器接收由所述消息队列所推送的消息,并根据消息发送策略选择消息渠道推送所述消息,所述消息渠道包括微信服务号、APP移动端、PC客户端、邮箱中的任意一种或多种,所述消息发送策略根据所述业务特征分别为不同的所述消息渠道设置推送权限,所述消息渠道仅推送符合其推送权限内的消息以控制消息的数据流量和数据流向;

客户端通过消息接收策略对消息进行鉴别,并接收鉴别通过的消息,所述消息接收策略包括查询所述消息渠道的权限与所述消息的业务特征是否相符。

在一些技术方案中,所述消息推送管理方法还包括步骤:

所述客户端发送长连接请求,网关服务器对所述长连接请求进行鉴权;所述鉴权通过后所述客户端与所述推送服务器长连接。

在一些技术方案中,所述消息推送管理方法还包括步骤:

所述推送服务器收集所述客户端对通过不同所述消息渠道所接收到的不同业务特征的消息的操作,所述操作包括阅读、收藏、删除、屏蔽中任意一种或多种;

根据所述操作分析该客户端对不同消息渠道以及不同业务特征的消息的接受程度,以及根据所述接受程度主动调整不同所述消息渠道对不同业务特征的推送权限。

在一些技术方案中,所述消息推送管理方法还包括步骤:

设置错误消息队列用于接收所述消息渠道推送失败的所述消息;

以及发送提示信息至后台管理员及时处理。

在一些技术方案中,所述消息推送管理方法还包括步骤:

创建缓冲区;

将所述转发服务器推送出的所述消息暂存于所述缓冲区内;

按时间周期自动建表,以及批量的从所述缓冲区内读取消息分表存储于数据库中。

在一些技术方案中,所述转发服务器设置有线程池,所述线程池采用多线程复用的方式接收每一条所述消息,并为所述消息分配唯一标识和时间戳,以及将所述消息纳入计数器进行流量统计。

在一些技术方案中,所述推送服务器采用多实例部署运行,且由所述网关服务器的路由配置负载均衡策略。

在一些技术方案中,所述业务权限标识的映射关系存储于缓存中,所述推送服务器根据所述业务权限标识的映射关系,并采用异步方式将消息采用推送渠道推送指定用户客户端。

在一些技术方案中,所述消息推送管理方法还包括步骤:

根据不同业务特征动态配置不同的消息模板,所述消息模板包括动态参数,所述动态参数将会在推送过程中转化为字段的具体值内容;

制作所述消息模板与所述业务特征以及所述消息渠道的映射关系,所述映射关系同步于所述客户端缓存;

当客户端接收到所述消息时,客户端根据所述映射关系选择对应的消息模板展示所述消息的内容;

所述消息模板利用函数配置正则表达式:拓扑节点:{topoName},时间:{createTime},节点信息:{extInfo:source};其中,

为了解决上述技术问题,本发明还提供了另一技术方案:

一种消息推送管理系统,包括:交换机、转发服务器、推送服务器和客户端;

所述交换机绑定有多个消息队列,所述消息具有业务特征和业务权限标识,每种业务特征的消息对应一种所述消息队列;

所述转发服务器用于接收所述消息,识别所述消息的业务特征,并将所述消息根据业务特征压入对应的所述消息队列中进行推送;

所述推送服务器用于接收由所述消息队列所推送的消息,并根据消息发送策略选择消息渠道推送所述消息,所述消息渠道包括微信服务号、APP移动端、PC客户端、邮箱中的任意一种或多种,所述消息发送策略根据所述业务特征分别为不同的所述消息渠道设置推送权限,所述消息渠道仅推送符合其推送权限内的消息以控制消息的数据流量和数据流向;

所述客户端用于通过消息接收策略对消息进行鉴别,并接收鉴别通过的消息,所述消息接收策略包括查询所述消息渠道的权限与所述消息的业务特征是否相符。

区别于现有技术,上述技术方案根据消息的型业务特征分别设置了多个对应的消息队列,转发服务器通过消息队列向推送服务器推送消息,从而确保消息分类有序的转发至推送服务器,并且在推送服务器中根据消息发送策略选择消息渠道推送所述消息,其中所述消息渠道仅推送符合其推送权限内的消息以控制消息的数据流量和数据流向;并且客户端通过消息接收策略对消息进行鉴别,查询所述消息渠道的权限与所述消息的业务特征是否相符,仅接收权限与特征相符的消息。从而通过消息接收策略与消息发送策略结合,有效避免频繁接收无效消息,以及避免客户端消息漏接。

在一些实施例中,所述推送服务器收集所述客户端对通过不同所述消息渠道所接收到的不同业务特征的消息的操作,根据所述操作分析该客户端对不同消息渠道以及不同业务特征的消息的接受程度,以及根据所述接受程度主动调整不同所述消息渠道对不同业务特征的推送权限。在这些实施例中通过这样的设计,可以实时关注客户端的变化,并主动及时的调整消息渠道对不同业务特征的推送权限,从而可在第一时间根据客户端的变化过滤掉无效消息。

上述发明内容相关记载仅是本申请技术方案的概述,为了让本领域普通技术人员能够更清楚地了解本申请的技术方案,进而可以依据说明书的文字及附图记载的内容予以实施,并且为了让本申请的上述目的及其它目的、特征和优点能够更易于理解,以下结合本申请的具体实施方式及附图进行说明。

附图说明

附图仅用于示出本发明具体实施方式以及其他相关内容的原理、实现方式、应用、特点以及效果等,并不能认为是对本申请的限制。

在说明书附图中:

图1为具体实施方式所述消息推送管理方法的流程图;

图2为具体实施方式所述调整推送权限的流程图;

图3为具体实施方式所述转发服务器转发消息的流程图;

图4为具体实施方式所述消息推送管理系统的示意图;

图5为具体实施方式各队列的示意图;

上述各附图中涉及的附图标记说明如下:

100、注册中心服务器;

200、转发服务器;

300、推送服务器;

400、存储数据库;

500、网关服务器;

10、消息队列;

20、持久化队列;

30、错误消息队列;

具体实施方式

为详细说明本申请可能的应用场景,技术原理,可实施的具体方案,能实现目的与效果等,以下结合所列举的具体实施例并配合附图详予说明。本文所记载的实施例仅用于更加清楚地说明本申请的技术方案,因此只作为示例,而不能以此来限制本申请的保护范围。

在本文中提及“实施例”意味着,结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中各个位置出现的“实施例”一词并不一定指代相同的实施例,亦不特别限定其与其它实施例之间的独立性或关联性。原则上,在本申请中,只要不存在技术矛盾或冲突,各实施例中所提到的各项技术特征均可以以任意方式进行组合,以形成相应的可实施的技术方案。

除非另有定义,本文所使用的技术术语的含义与本申请所属技术领域的技术人员通常理解的含义相同;本文中对相关术语的使用只是为了描述具体的实施例,而不是旨在限制本申请。

在本申请的描述中,用语“和/或”是一种用于描述对象之间逻辑关系的表述,表示可以存在三种关系,例如A和/或B,表示:存在A,存在B,以及同时存在A和B这三种情况。另外,本文中字符“/”一般表示前后关联对象是一种“或”的逻辑关系。

在本申请中,诸如“第一”和“第二”之类的用语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何实际的数量、主次或顺序等关系。

在没有更多限制的情况下,在本申请中,语句中所使用的“包括”、“包含”、“具有”或者其他类似的开放式表述,意在涵盖非排他性的包含,这些表述并不排除在包括所述要素的过程、方法或者产品中还可以存在另外的要素,从而使得包括一系列要素的过程、方法或者产品中不仅可以包括那些限定的要素,而且还可以包括没有明确列出的其他要素,或者还包括为这种过程、方法或者产品所固有的要素。

与《审查指南》中的理解相同,在本申请中,“大于”、“小于”、“超过”等表述理解为不包括本数;“以上”、“以下”、“以内”等表述理解为包括本数。此外,在本申请实施例的描述中“多个”的含义是两个以上(包括两个),与之类似的与“多”相关的表述亦做此类理解,例如“多组”、“多次”等,除非另有明确具体的限定。

在本申请实施例的描述中,所使用的与空间相关的表述,诸如“中心”“纵向”“横向”“长度”“宽度”“厚度”“上”“下”“前”“后”“左”“右”“竖直”“水平”“垂直”“顶”“底”“内”“外”“顺时针”“逆时针”“轴向”“径向”“周向”等,所指示的方位或位置关系是基于具体实施例或附图所示的方位或位置关系,仅是为了便于描述本申请的具体实施例或便于读者理解,而不是指示或暗示所指的装置或部件必须具有特定的位置、特定的方位、或以特定的方位构造或操作,因此不能理解为对本申请实施例的限制。

除非另有明确的规定或限定,在本申请实施例的描述中,所使用的“安装”“相连”“连接”“固定”“设置”等用语应做广义理解。例如,所述“连接”可以是固定连接,也可以是可拆卸连接,或成一体设置;其可以是机械连接,也可以是电连接,也可以是通信连接;其可以是直接相连,也可以通过中间媒介间接相连;其可以是两个元件内部的连通或两个元件的相互作用关系。对于本申请所属技术领域的技术人员而言,可以根据具体情况理解上述用语在本申请实施例中的具体含义。

请参阅图1至图5,本实施例提供了一种消息推送管理方法,用于解决上述存在消息频繁接收或漏发的技术问题。

如图1所示,所述消息推送管理方法包括以下步骤:

S101、配置交换机和多个消息队列,所述消息队列与所述交换机绑定,所述消息具有业务特征和业务权限标识,每种业务特征的消息对应一种所述消息队列;

S102、转发服务器接收所述消息,识别所述消息的业务特征,并将所述消息根据业务特征压入对应的所述消息队列中进行推送;

S103、推送服务器接收由所述消息队列所推送的消息,并根据消息发送策略选择消息渠道推送所述消息,所述消息渠道包括微信服务号、APP移动端、PC客户端、邮箱中的任意一种或多种,所述消息发送策略根据所述业务特征分别为不同的所述消息渠道设置推送权限,所述消息渠道仅推送符合其推送权限内的消息以控制消息的数据流量和数据流向;

S104、客户端通过消息接收策略对消息进行鉴别,并接收鉴别通过的消息,所述消息接收策略包括查询所述消息渠道的权限与所述消息的业务特征是否相符。

转发服务器200配置具有基础功能的所述交换机,并完成消息通道测试,为消息创建唯一标识和时间戳,以及消息流量统计。在步骤S101中每一条消息具有相应的业务特征(其中业务特征包括:),如图5所示,并按业务特征进入指定的业务特征的消息队列10进行推送。

所述的推送服务器300为下游服务器,推送服务器300用于监听消息队列,该消息队列为转发服务器200所创建的交换机所绑定的队列。推送服务器300作为推送服务端,将承担高额的客户端长连接负载量,所述的推送服务器300支持多实例部署运行,由网关服务模块的路由配置负载均衡策略。

推送服务器300用于接收由转发服务器200消息队列所转发的消息,并实现包括微信服务号、APP移动端、PC客户端和邮箱等多种消息渠道的消息推送功能。推送服务器300包含括了消息推送的渠道开关,每个消息渠道都设置有对应的渠道开关,通过渠道开关可以开启或关闭该消息渠道。推送服务器300在进行消息推送时,根据业务特征配置微信服务号、移动APP、PC客户端和邮箱等消息渠道的推送权限,从而有效控制消息的数据流量和数据流向。

其中,如图4所示,预先建立注册中心服务器100,注册中心服务器100用于管理转发服务器200,存储数据库400、推送服务器300和网关服务器500的运行状态。消息推送管理系统可以为分布式系统,所述注册中心服务器100也是分布式系统的基础服务模块。

在一些实施方式中,所述转发服务器200设置有线程池,所述线程池采用多线程复用的方式接收每一条所述消息,并为所述消息分配唯一标识和时间戳,以及将所述消息纳入计数器进行流量统计。所述线程池采用多线异步推送方法,系统初始化一个固定大小线程池单例,线程池快速处理消息业务逻辑,并异步推送消息队列,从而降低消息推送的延时。

所述推送服务器300采用多实例部署运行,且由所述网关服务器500的路由配置负载均衡策略。

客户端设置有消息接收策略,消息接收策略中查询所接收到的消息对应的消息渠道是否具有向该客户端推送消息的权限,并仅接收有权限的消息渠道所推送的消息,拒收无权限的消息渠道所推送的消息。并且消息接收策略可以通过开关方式,配置自己的关注消息的业务特征。

上述实施方式中,根据消息的型业务特征分别设置了多个对应的消息队列,转发服务器200通过消息队列向推送服务器300推送消息,从而确保消息分类有序的转发至推送服务器300,并且在推送服务器300中根据消息发送策略选择消息渠道推送所述消息,其中所述消息渠道仅推送符合其推送权限内的消息以控制消息的数据流量和数据流向;并且客户端通过消息接收策略对消息进行鉴别,查询所述消息渠道的权限与所述消息的业务特征是否相符,仅接收权限与特征相符的消息。从而通过消息接收策略与消息发送策略结合,有效避免频繁接收无效消息,以及避免客户端消息漏接。

如图2所示,在一些实施方式中,所述消息推送管理方法还包括步骤:

S201、所述推送服务器300收集所述客户端对通过不同所述消息渠道所接收到的不同业务特征的消息的操作,所述操作包括阅读、收藏、删除、屏蔽中任意一种或多种;

S202、根据所述操作分析该客户端对不同消息渠道以及不同业务特征的消息的接受程度,以及根据所述接受程度主动调整不同所述消息渠道对不同业务特征的推送权限。

在本实施方式中,业务特征的消息的接受程度,以及根据所述接受程度主动调整不同所述消息渠道对不同业务特征的推送权限。在这些实施例中通过这样的设计,可以实时关注客户端的变化,并主动及时的调整消息渠道对不同业务特征的推送权限,从而可在第一时间根据客户端的变化过滤掉无效消息。

如图3所示,在一些实施方式中,所述消息推送管理方法还包括步骤:

S301、创建缓冲区;

S302、将所述转发服务器推送出的所述消息暂存于所述缓冲区内;

S303、按时间周期自动建表,以及批量的从所述缓冲区内读取消息分表存储于数据库中。

在上述实施方式中,还设置有存储数据库400(即持久化服务模块),用于存储转发服务器200中所述消息队列所推送出的消息。存储数据库400接收由转发服务器200的队列消息所推送出的消息,并且存储数据库400创建缓冲区,按时间周期自动建表,批量将消息数据持久化于数据库中,并分表存储。如图5所示,设置有持久化队列20,转发服务器200的队列消息所推送出的消息进入持久化队列20,然后通过持久化队列20读出交存储于存储数据库400中。

所述存储数据库400监听指定的所述消息队列,并异步批量存储消息队列转发的所述消息。并且所述存储数据库400开放查询接口,提供用户查询入口。

所述消息推送管理方法还包括步骤:所述客户端发送长连接请求,网关服务器500对所述长连接请求进行鉴权;所述鉴权通过后所述客户端与所述推送服务器300长连接。网关服务器500对客户端的长连接请求进行鉴权,以及处理跨域请求。有效的消息将会推送给相应的用户客户端,并且网关服务器500还用于在查询存储数据库400中的消息时,鉴权请求的有效性。

在一些实施方式中,所述消息推送管理方法还包括步骤:

设置错误消息队列用于接收所述消息渠道推送失败的所述消息;

以及发送提示信息至后台管理员及时处理。

如图5所示,在上述实施方式中,设置有错误消息队列30,所有的消息的推送过程将记录在日志中。日志中包括推送成功后的结果以及推送出现的异常的堆栈信息,同时将推送异常的信息进入错误消息队列,等待处理。

所述用户系统为并行系统,在业务逻辑上相对解耦,当用户系统的用户权限关系发生变动,需要及时通知消息推送系统,及时更新缓存的权限映射关系。

在一些实施方式中,所述业务权限标识的映射关系存储于缓存中,所述推送服务器300根据所述业务权限标识的映射关系,并采用异步方式将消息采用推送渠道推送指定用户客户端。

在一些实施方式中,所述消息推送管理方法还包括步骤:

根据不同业务特征动态配置不同的消息模板,所述消息模板包括动态参数,所述动态参数将会在推送过程中转化为字段的具体值内容;

制作所述消息模板与所述业务特征以及所述消息渠道的映射关系,所述映射关系同步于所述客户端缓存;

当客户端接收到所述消息时,客户端根据所述映射关系选择对应的消息模板展示所述消息的内容。

当所述消息模板的信息修改时,则将修改后的消息模板同步更新至客户端的缓存。

所述消息模板利用函数配置正则表达式:拓扑节点:{topoName},时间:{createTime},节点信息:{extInfo:source};其中,

为了解决上述技术问题,本发明还提供了另一技术方案:

如图4所示,一种消息推送管理系统,包括:交换机、转发服务器200、推送服务器和客户端;

所述交换机绑定有多个消息队列,所述消息具有业务特征和业务权限标识,每种业务特征的消息对应一种所述消息队列;

所述转发服务器200用于接收所述消息,识别所述消息的业务特征,并将所述消息根据业务特征压入对应的所述消息队列中进行推送;

所述推送服务器用于接收由所述消息队列所推送的消息,并根据消息发送策略选择消息渠道推送所述消息,所述消息渠道包括微信服务号、APP移动端、PC客户端、邮箱中的任意一种或多种,所述消息发送策略根据所述业务特征分别为不同的所述消息渠道设置推送权限,所述消息渠道仅推送符合其推送权限内的消息以控制消息的数据流量和数据流向;

所述客户端用于通过消息接收策略对消息进行鉴别,并接收鉴别通过的消息,所述消息接收策略包括查询所述消息渠道的权限与所述消息的业务特征是否相符。

转发服务器200配置具有基础功能的所述交换机,并完成消息通道测试,为消息创建唯一标识和时间戳,以及消息流量统计。在步骤S101中每一条消息具有相应的业务特征,如图5所示,并按业务特征进入指定的业务特征的消息队列10进行推送。

所述的推送服务器为下游服务器,推送服务器用于监听消息队列,该消息队列为转发服务器200所创建的交换机所绑定的队列。推送服务器作为推送服务端,将承担高额的客户端长连接负载量,所述的推送服务器支持多实例部署运行,由网关服务模块的路由配置负载均衡策略。

所述消息推送管理系统还包括注册中心服务器100,注册中心服务器100用于管理转发服务器200,存储数据库400、推送服务器和网关服务器500的运行状态。消息推送管理系统可以为分布式系统,所述注册中心服务器100也是分布式系统的基础服务模块。

所述转发服务器200设置有线程池,所述线程池采用多线程复用的方式接收每一条所述消息,并为所述消息分配唯一标识和时间戳,以及将所述消息纳入计数器进行流量统计。所述线程池采用多线异步推送方法,系统初始化一个固定大小线程池单例,线程池快速处理消息业务逻辑,并异步推送消息队列,从而降低消息推送的延时。所述推送服务器采用多实例部署运行,且由所述网关服务器500的路由配置负载均衡策略。

存储数据库400(即持久化服务模块),用于存储转发服务器200中所述消息队列所推送出的消息。存储数据库400接收由转发服务器200的队列消息所推送出的消息,并且存储数据库400创建缓冲区,按时间周期自动建表,批量将消息数据持久化于数据库中,并分表存储。如图5所示,设置有持久化队列20,转发服务器200的队列消息所推送出的消息进入持久化队列20,然后通过持久化队列20读出交存储于存储数据库400中。

网关服务器500对客户端的长连接请求进行鉴权,以及处理跨域请求。有效的消息将会推送给相应的用户客户端,并且网关服务器500还用于在查询存储数据库400中的消息时,鉴权请求的有效性。

上述实施方式中,根据消息的型业务特征分别设置了多个对应的消息队列,转发服务器200通过消息队列向推送服务器推送消息,从而确保消息分类有序的转发至推送服务器,并且在推送服务器中根据消息发送策略选择消息渠道推送所述消息,其中所述消息渠道仅推送符合其推送权限内的消息以控制消息的数据流量和数据流向;并且客户端通过消息接收策略对消息进行鉴别,查询所述消息渠道的权限与所述消息的业务特征是否相符,仅接收权限与特征相符的消息。从而通过消息接收策略与消息发送策略结合,有效避免频繁接收无效消息,以及避免客户端消息漏接。

最后需要说明的是,尽管在本申请的说明书文字及附图中已经对上述各实施例进行了描述,但并不能因此限制本申请的专利保护范围。凡是基于本申请的实质理念,利用本申请说明书文字及附图记载的内容所作的等效结构或等效流程替换或修改产生的技术方案,以及直接或间接地将以上实施例的技术方案实施于其他相关的技术领域等,均包括在本申请的专利保护范围之内。

相关技术
  • 一种基于消息推送驱动工作流的方法及系统
  • 一种基于GIS系统的校园消息推送优化方法
  • 一种证券客服咨询的智能消息推送方法、系统及装置
  • 一种实时消息推送方法及系统
  • 一种基于消息推送的wifi安全管理系统及管理方法
  • 一种用于系统消息推送的企业管理方法
技术分类

06120115916991