一种消息推送方法、装置及消息服务系统
技术领域
本发明涉及消息服务技术领域,尤其涉及一种消息推送方法、装置及消息服务系统。
背景技术
在云平台及超融合技术中,通常基于分布式应用架构,而分布式应用架构通常采用消息服务系统。在消息服务系统中,消息系统中间件是消息服务系统的核心组件,其承担连接管理与消息管理的核心功能。基于WebSocket协议的消息推送机制,实现浏览器(或包含浏览器的客户端)与服务端进行全双工通信(Full-Duplex),以更好地节省服务端的资源和带宽并达到实时通讯的目的。为支持高并发的访问请求,通常需要部署数量更多的消息队列服务器,因此传统的云平台或者超融合设备中的消息服务系统存在功能耦合、部署成本过高及资源浪费的问题。
同时,在现有技术中由于服务端与客户端建立了基于WebSocket协议的全双工通信,必然会对服务端造成资源及性能上的损耗。此外,由于传统的消息系统中间件基于公网环境进行传输,传统的消息推送方式可能存在无法确保每个消息都能够成功地被推送到客户端或者会导致数据的落盘失败以及消息的重复消费等诸多缺陷。上述缺陷会直接导致各种在线应用、资金支付操作、邮件重复发送或者发送失败后无法被邮件发送者所感知等诸多问题。有鉴于此,有必要对现有技术中的消息推送方法及相关技术予以改进,以解决上述问题。
发明内容
本发明的目的在于揭示一种消息推送方法、装置及消息服务系统,用以解决现有技术中对消息推送过程中所存在的诸多缺陷,尤其是为了实现有效地控制对消息推送过程中实施监听操作,避免原本不需要重发推送的消息被重复推送以及客户端对消息的重复消费,提高消息推送的可靠性。
为实现上述一个发明目的,本发明提供了一种消息推送方法,包括:
监听自服务端发出的消息,使用预先加载过滤条件的第一缓存与第二缓存对所述消息分别执行过滤校验操作与可靠性检测,以对服务端发出的消息进行筛选,并将筛选出的消息推送至客户端。
所述服务端发出的消息响应于客户端发起的访问请求,监听自服务端发出的消息,使用预先加载过滤条件的第一缓存与第二缓存对所述消息分别执行过滤校验操作与可靠性检测,以对服务端发出的消息进行筛选,并将筛选出的消息推送至客户端,以响应所述访问请求。
作为本发明的进一步改进,所述服务端发出的消息为服务端主动发送,监听自服务端主动发出的消息,使用预先加载过滤条件的第一缓存与第二缓存对所述消息分别执行过滤校验操作与可靠性检测,以对服务端发出的消息进行筛选,并将筛选出的消息推送至客户端。
作为本发明的进一步改进,所述过滤条件在第一缓存与第二缓存接收到自服务端发出的消息之前,还包括:自存储装置中预先加载客户端和/或服务端预先注册并分别写入第一缓存与第二缓存的第一消息事件白名单与第二消息事件白名单。
作为本发明的进一步改进,所述过滤条件由第一消息事件白名单和/或第二消息事件白名单定义,所述第一缓存与第二缓存挂载至存储装置,并在执行消息推送之前预先自所述存储装置中调用预先注册的第一消息事件白名单与第二消息事件白名单。
作为本发明的进一步改进,所述第一消息事件白名单包含消息标识、消息名称、消息创建时间或者消息更新时间中的一种或者几种的任意组合,所述第二消息事件白名单包含在设定时间段内被允许推送的次数。
作为本发明的进一步改进,还包括:丢弃不符合第一消息事件白名单和/或第二消息事件白名单所对应的消息。
作为本发明的进一步改进,所述第二消息事件白名单包含在设定时间段内被允许推送的次数被设定为一次,并丢弃超过设定时间段的消息或者在设定时间段内被推送两次或者两次以上的消息。
作为本发明的进一步改进,所述服务端在响应客户端发起的访问请求后将响应访问请求所对应的消息发送至消息队列服务器中,并使用消息推送组件对发送至所述消息队服务器中的消息进行监听,并建立TCP连接。
作为本发明的进一步改进,所述监听自服务端发出的消息之前,在服务端与客户端之间建立WebSocket连接。
作为本发明的进一步改进,所述第一缓存与第二缓存被封装至消息推送组件中,并将至少一个消息推送组件被封装为微服务。
基于相同发明思想,本发明还揭示了一种消息推送装置,由至少一个消息推送组件组成,所述消息推送组件包括:用于监听自服务端发出的消息的监听组件,响应于客户端的WebSocket引擎,第一缓存及第二缓存;
所述第一缓存与第二缓存使用预先加载过滤条件,以对所述消息分别执行过滤校验操作与可靠性检测,对服务端发出的消息进行筛选,并通过所述WebSocket引擎将筛选出的消息推送至客户端。
作为本发明的进一步改进,所述消息推送装置被封装为微服务。
作为本发明的进一步改进,还包括:与第一缓存与第二缓存连接的存储装置;
所述过滤条件在第一缓存与第二缓存接收到自服务端发出的消息之前,自存储装置中预先加载客户端和/或服务端预先注册并分别写入第一缓存与第二缓存的第一消息事件白名单与第二消息事件白名单。
最后,本发明还揭示了一种消息服务系统,包括:
服务端,接收自服务端发出响应客户端发起的访问请求所对应的消息的消息队列服务器,如上述任一项发明创造所述的消息推送装置;以及客户端。
作为本发明的进一步改进,所述消息队列服务器采用分布式消息队列消费自服务端发出响应客户端发起的访问请求所对应的消息。
与现有技术相比,本发明的有益效果是:
首先,通过在第一缓存与第二缓存中预先加载过滤条件,以通过第一缓存与第二缓存对所述消息分别执行过滤校验操作与可靠性检测,能够有效地控制对基于WebSocket协议建立全双工通信时向客户端所推送消息时的可靠性与准确性,由于第二消息事件白名单包含在设定时间段内被允许推送的次数,使得向客户端推送的消息能够根据业务需要在设定时间范围内向客户端进行推送,有效地防止了消息被重复推送,并实现了对推送消息的鉴权处理;
其次,由于将第一缓存与第二缓存被封装至消息推送组件,并将消息推送装置被封装为微服务且采用分布式消息队列,能够实现高内聚低耦合的效果,并使得整个消息服务系统具有更好的扩展性。
附图说明
图1为本发明一种消息推送方法的整体流程图;
图2为本发明一种消息服务系统的拓扑图,其中,示出了消息服务系统所包含的消息推送装置在客户端与服务端之间建立基于WebSocket协议的全双工通信连接的实例图;
图3为本发明一种消息服务系统的拓扑图,其中,示出了消息服务系统所包含的消息推送装置在一种变形例中在客户端与服务端之间建立基于WebSocket协议的全双工通信连接的实例图;
图4为本发明一种消息推送装置的拓扑图。
具体实施方式
下面结合附图所示的各实施方式对本发明进行详细说明,但应当说明的是,这些实施方式并非对本发明的限制,本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代,均属于本发明的保护范围之内。
本申请所揭示的一种消息推送方法、消息推送装置及其消息服务系统,旨在对服务端10对向客户端40执行消息推送的实现过程予以改进。尤其是的,服务端10在本申请各个实施例中可被理解为运行计算机可执行程序的服务器、物理计算机、虚拟机、虚拟机集群、数据中心,云计算平台、超融合一体机,甚至还可为手持式移动设备(例如手机、可接入网络的可穿戴设备、平板电脑等)等。客户端40在本申请各个实施例中为向服务端10发起访问请求或者操作指令的一种终端设备或者电子设备,并在各个实施例中可被理解为手机、计算机、能够发送访问请求(例如用于网上订购商品的程序或者计算机应用)的移动设备、邮件系统、广播系统等。
尤其的,在本申请中,服务端10与客户端40是相对而言的,彼此之间的角色可根据计算机程序或者各种在线应用的特性进行对调。因此,在本申请中如果消息从一个主体推送至另一个主体时,第一个主体则为服务端,二个主体即为客户端40。以下通过若干实施例对具体实现过程予以阐述。
实施例一:
本实施例揭示了一种消息推送方法的第一种具体实施方式。
参图1所示,一种消息推送方法,包括以下步骤S1~步骤S3。
步骤S1、监听自服务端发出的消息。
步骤S2、使用预先加载过滤条件的第一缓存与第二缓存对所述消息分别执行过滤校验操作与可靠性检测。
步骤S3、对服务端发出的消息进行筛选,并将筛选出的消息推送至客户端。
结合图2与图4所示,在本实施例中,服务端10发出的消息响应于客户端发起的访问请求,监听自服务端10发出的消息,使用预先加载过滤条件的第一缓存32与第二缓存33对所述消息分别执行过滤校验操作与可靠性检测,以对服务端10发出的消息进行筛选,并将筛选出的消息推送至客户端40,以响应所述访问请求。被推送至客户端40的消息在客户端40的浏览器41中进行可视化展示。
过滤条件在第一缓存32与第二缓存33接收到自服务端10发出的消息之前,还包括:自存储装置50中预先加载客户端40和/或服务端10预先注册并分别写入第一缓存32与第二缓存33的第一消息事件白名单与第二消息事件白名单。在本实施例中,服务端10指定对客户端10发起的访问请求所对应的消息时,已经事先更具客户端40作为具体事务的请求方所发出的业务请求所包含的messageid、事件名称(event)及版本号(version)等标签确定待推送的消息所推送的对象,即某个具体的客户端40。至于服务端10是否具有推送消息的权限,则是由消息本身所携带的上述标签所决定的。因此,本实施例所揭示的消息推送方法无需确定待推送的消息所推送的具体对象。
过滤条件由第一消息事件白名单和/或第二消息事件白名单定义,并最优选为由第一消息事件白名单和第二消息事件白名单共同定义。同时,第一消息事件白名单和第二消息事件白名单可以在设定的时间范围内被统一配置于如图4所示出的消息推送装置60中。第一缓存32与第二缓存33挂载至存储装置50,并在执行消息推送之前预先自所述存储装置50中调用预先注册的第一消息事件白名单与第二消息事件白名单。由此可使得对第一消息事件白名单和第二消息事件白名单的定义及配置更为灵活,凡是不符合第一消息事件白名单与第二消息事件白名单的消息都会别认定为黑名单消息,从而拒绝对该落入黑名单的消息所执行的推送操作。第一消息事件白名单与第二消息事件白名单均以数据表结构的格式保存至第一缓存32与第二缓存33中,以满足用户在客户端40的浏览器中41中进行快速查询,并支持海量数据的高并发查询、检索与定位,同时也能满足用户对第一消息事件白名单和第二消息事件白名单中的一个或者几个键值(Key-Valve)的灵活修改。
具体的,在本实施例中,第一消息事件白名单包含消息标识、消息名称、消息创建时间或者消息更新时间中的一种或者几种的任意组合,所述第二消息事件白名单包含在设定时间段内被允许推送的次数。同时,本实施例所揭示的消息推送方法还包括:丢弃不符合第一消息事件白名单和/或第二消息事件白名单所对应的消息。
以下示出了部分实现上述过程并带批注的可执行代码。
在本实施例中,第一消息事件白名单用以对待推送消息进行鉴权,并可由图4所示出的消息推送组件30中的监听组件31予以监听,当待推送的消息不符合第一消息事件白名单所设定的内容时,拒绝对该待推送的消息推送至客户端40。同时,通过第二消息事件白名单对符合第一消息事件白名单的消息进行可靠性(Reliability)判断。至于可靠性的参数被设置为一次(Mosonce)还是多次(Lease once),则可根据待推送的消息及用户在客户端40所发起的访问请求的具体要求进行灵活设定。如果一条消息基于第一缓存32与第二缓存33执行鉴权处理及通过可靠性判断后,可直接通过图4中的WebSocket引擎34向客户端40进行反馈。
例如,在本实施例中,该第二消息事件白名单包含在设定时间段内被允许推送的次数被设定为一次,并丢弃超过设定时间段的消息或者在设定时间段内被推送两次或者两次以上的消息。服务端10在响应客户端40发起的访问请求后将响应访问请求所对应的消息发送至消息队列服务器20中,并使用消息推送装置60(其包含消息推送组件30a、消息推送组件30b)对发送至所述消息队服务器20中的消息进行监听,并建立TCP连接。当消息在设定时间段内推送至客户端40的次数超过第二消息事件白名单包含在设定时间段内被允许推送的次数时,则丢弃该消息。
Socket(套接字)是支持TCP/IP协议的网络通信基本操作单元,应用层通过传输层进行数据通信时,TCP会遇到多个同时为某些个应用程序提供并发服务的需求,多个TCP连接或者多个应用程序进程需要通过一个TCP协议端口传输数据。因此,为了区分不同的应用程序进程或者线程,操作系统(例如物理机的操作系统或者云平台管理系统的操作系统)需要为应用程序与TCP/IP协议提供套接字接口。通常的,建立Socket连接至少需要一对套接字,其中一个套接字运行于客户端(Client Socket),另一个套接字运行于服务端(SeverSocket)。套接字之间的连接过程包括(a)服务器监听;(b)客户端请求;(c)连接确认。只要确认连接成功,客户端与服务端即建立了连接,通常情况下,Socket连接就是TCP连接。
监听自服务端10发出的消息之前,在服务端10与客户端40之间建立WebSocket连接。通常的,在对某个自服务端10向客户端40执行消息推送前,需要建立客户端40与服务端10之间的建立基于WebSocket协议的全双工通信。由于使用消息推送装置60对发送至所述消息队服务器20中的消息进行监听并建立TCP连接,使得该消息推送方法具有高内聚低耦合的技术优势,并使得运行该消息推送方法的消息服务系统具有更好的扩展性,非常适合在消息推送具有极高要求的金融服务、线上购物等场景中。此类场景中虽然可通过增加后台服务器数量及性能的途径予以实现,但若采用本实施例所揭示的技术方案,能够使得在既有物理设备的前提下,则能够则支撑数量更多的客户端40的访问需求。
结合图3所示,在本实施例中,该第一缓存32与第二缓存33被封装至消息推送组件30中,并将至少一个消息推送组件30被封装为微服务。在图3中,消息推送组件30包含消息推送组件30a及消息推送组件30b或者数量更多的消息服务组件。每个消息服务组件均于后端的消息队列服务器20建立TCP连接并对由服务端10所推送的至消息队列服务器20中的待推送的消息进行监听。消息队列服务器20支持异步处理、流量削峰、日志处理及应用解耦,并可采用RabbitMQ实现。自服务端10发送至消息队列服务器20的消息发送至消息队列服务器20的RabbitMQ交换机,并将消息写入队列中。然后由消息推送组件30中的监听组件31对写入队列中的消息进行监听。
第二消息事件白名单本质上定义了消息在一定的时间内允许重复推送的次数,保存在第一缓存32的key-value格式为key:messageId-sessionId,value为该消息在定义的时间范围内推送的次数。messageId为消息体里的唯一标识,sessionId为客户端的一个会话key,value的上限为第一消息事件白名单里event对象里定义的Reliability属性,如果Reliability属性为MostOnce,则该消息在一定时间范围内最多只能推送一次,如果Reliability属性为LeastOnce,那么该消息在一定时间范围内可以允许多次推送。至于时间的长度可根据实际需要进行任意设定。
同时,在本实施例中,待推送消息可通过第一消息事件白名单中的消息标识(即messageId),位于前端的客户端40发起的访问请求的会话key(即sessionId),可通过在客户端40中查询messageId是否与sessionId匹配,以确定是否已经推送过该消息,如果已经推送过,则执行丢弃后续并与之前的sessionId相匹配的messageId所对应的待推送消息,以保证消息根据第二消息事件白名单进行可靠性检测,以对该待推送消息的一次或者在设定的时间中的多次推送,防止消息被任意地推送。
通过本实施例所揭示的消息推送方法,可在高并发的分布式消息推送场景中,有效地监听并控制消息的推送范围,能够对待推送的消息根据实际需要进行精确可控的推送操作,避免消息本被重复推送或者第二消息事件白名单可以在设定的时间范围内被允许推送的次数,并最终防止消息在客户端40被重复消费。
实施例二:
本实施例示出了一种消息推送方法的一种变形实施例。本实施例与实施例一所揭示的消息推送方法相比,其主要区别在于,所述服务端10发出的消息为服务端10主动发送,监听自服务端10主动发出的消息,使用预先加载过滤条件的第一缓存32与第二缓存33对所述消息分别执行过滤校验操作与可靠性检测,以对服务端10发出的消息进行筛选,并将筛选出的消息推送至客户端40。
参图2与图3所示,本实施例场景中所揭示的消息推送方法,可在服务端10包含的若干业务指令集,例如业务指令集101及业务指令集102等,服务端10自发地推送消息,可在服务端10对客户端40进行自动消息推送,例如客户端40所安装的某个软件(APP)执行版本升级或者插件安装时,由客户端10定期且主动地向客户端40推送含有安装程序或者系统升级程序的消息。于此场景中,使用本实施例所揭示的消息推送方法,能够防止服务端10频繁无序或重复地向客户端40推送“系统升级”的消息及升级数据包。避免用户在已经安装了升级数据包后,在客户端40的浏览器41或者其他形式的用户可视化界面(GUI)中重复的弹出提示用户升级系统或者软件的对话框,并间接地提高了用户体验。
本实施例与实施例一中具有相同部分的技术方案,请参实施例一所述,在此不再赘述。
实施例三:
结合图2至图4所示,基于实施例一和/或实施例二所揭示的一种消息推送方法所包含的技术方案,本实施例还揭示了一种消息推送装置60,由至少一个消息推送组件30组成,所述消息推送组件30包括:用于监听自服务端发出的消息的监听组件,响应于客户端40的WebSocket引擎34,第一缓存32及第二缓存33。
在软件架构层面而言,服务端10、消息队列服务器20及消息推送装置60(其包含消息推送组件30a、消息推送组件30b)均位于后端,客户端40位于前端。第一缓存32与第二缓存33使用预先加载过滤条件,以对所述消息分别执行过滤校验操作与可靠性检测,对服务端10发出的消息进行筛选,并通过所述WebSocket引擎34将筛选出的消息推送至客户端40。
在本实施例中,消息推送装置60被封装为微服务。该消息推送装置60包含两个或者两个上的消息推送组件,例如消息推送组件30a、消息推送组件30b等。同时,该消息推送装置还包括:与第一缓存32与第二缓存33连接的存储装置50。该存储装置50选自数据库(尤其优选为分布式时序数据库)、磁盘整理、分布式缓存或者分布式存储装置。该存储装置50可被服务端10和/或客户端40访问,并向存储装置50中预先配置过滤条件,并对过滤条件所包含的第一消息事件白名单与第二消息事件白名单予以独立配置。
过滤条件在第一缓存32与第二缓存33接收到自服务端10发出的消息之前,自存储装置50中预先加载客户端40和/或服务端10预先注册并分别写入第一缓存32与第二缓存33的第一消息事件白名单与第二消息事件白名单。
本实施例与实施例一和/或实施例二中相同部分的技术方案,请参上文所述,在此不再赘述。
实施例四:
结合图2至图4所示,基于上述任意一种实施例所揭示的技术方案,本实施例还揭示了一种消息服务系统,该消息服务系统包括:
服务端10,接收自服务端10发出响应客户端40发起的访问请求所对应的消息的消息队列服务器20,如实施例三所揭示一种的消息推送装置;以及客户端40。响应客户端40发起的访问请求所对应的消息即本实施例中需要被推送的消息。消息队列服务器20采用分布式消息队列消费自服务端10发出响应客户端40发起的访问请求所对应的消息。
客户端40向消息服务组件30(或者消息服务装置60)发送WebSocket请求,并由客户端40向消息服务组件30(或者消息服务装置60)建立与客户端40的WebSocket连接。
本实施例与实施例一至实施例三所揭示的消息推送方法或者消息推送装置中具有相同部分的技术方案,请参上文所述,在此不再赘述。
本发明实施例中所描述的各种说明性的逻辑块,或单元都可以通过通用处理器,数字信号处理器,专用集成电路(ASIC),现场可编程门阵列或其它可编程逻辑装置,离散门或晶体管逻辑,离散硬件部件,或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器,可选地,该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现,例如数字信号处理器和微处理器,多个微处理器,一个或多个微处理器联合一个数字信号处理器核,或任何其它类似的配置来实现。
上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明,它们并非用以限制本发明的保护范围,凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。
对于本领域技术人员而言,显然本发明不限于上述示范性实施例的细节,而且在不背离本发明的精神或基本特征的情况下,能够以其他的具体形式实现本发明。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本发明的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。
此外,应当理解,虽然本说明书按照实施方式加以描述,但并非每个实施方式仅包含一个独立的技术方案,说明书的这种叙述方式仅仅是为清楚起见,本领域技术人员应当将说明书作为一个整体,各实施例中的技术方案也可以经适当组合,形成本领域技术人员可以理解的其他实施方式。