CN115348231B - 一种消息处理方法、装置、服务端及存储介质 - Google Patents

一种消息处理方法、装置、服务端及存储介质 Download PDF

Info

Publication number
CN115348231B
CN115348231B CN202210987809.2A CN202210987809A CN115348231B CN 115348231 B CN115348231 B CN 115348231B CN 202210987809 A CN202210987809 A CN 202210987809A CN 115348231 B CN115348231 B CN 115348231B
Authority
CN
China
Prior art keywords
message
preset
queue
priority level
processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202210987809.2A
Other languages
English (en)
Other versions
CN115348231A (zh
Inventor
马德磊
李瑞亮
贾宏伟
郭建君
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Weiling Times Technology Co Ltd
Original Assignee
Beijing Weiling Times Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Weiling Times Technology Co Ltd filed Critical Beijing Weiling Times Technology Co Ltd
Priority to CN202210987809.2A priority Critical patent/CN115348231B/zh
Publication of CN115348231A publication Critical patent/CN115348231A/zh
Application granted granted Critical
Publication of CN115348231B publication Critical patent/CN115348231B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS

Abstract

本申请涉及消息系统的领域,尤其是涉及一种消息处理方法、装置、服务端及存储介质。该方法包括:获取客户端发送的消息,并确定消息对应的消息类型;根据消息类型,确定消息对应的优先等级,优先等级与消息的实时性呈正比例关系;若优先等级高于预设优先等级,则对消息进行回调处理。本申请涉及一种消息处理方法、装置、服务端及存储介质,可以提高消息处理效率,进一步地可以提升用户使用体验的效果。

Description

一种消息处理方法、装置、服务端及存储介质
技术领域
本申请涉及消息系统的领域,尤其是涉及一种消息处理方法、装置、服务端及存储介质。
背景技术
消息是在两台计算机间传送的数据单位,例如文本字符等。消息生产者用于生产数据即生产消息,生产出来的消息被发送至消息处理者,消息处理者对消息进行处理,在消息生产者生产出消息后,直至被消息处理者处理后,才能进行下一个消息的处理,影响消息处理的效率。
消息队列是一个用于暂存消息生产者所生产出的消息,以供消息处理者回调消息进行处理的容器。消息队列的目的是提供路由并保证消息的传递,如果发送消息时接收者不可用,消息队列会保留消息,直至可以成功传递,消息队列为任何应用程序提供消息处理和消息队列功能。因此,为了提高消息的通信效率,在消息生产者每生产出一个消息后,就将消息存储至消息队列中,不需要等待消息处理者进行处理后再返回,而对于消息处理者,则可以通过访问消息队列,获取消息并对消息进行处理,消息生产者与消息处理者之间的工作为异步处理方式,不需要相互等待,进而提高了消息处理的效率。
消息队列作为一个先进先出的消息存储区域,消息会按照消息的接收顺序进行存储,先接收的消息先处理,在消息被处理后,该消息也将被删除。
但是,当消息被存储至一个消息队列中后,有的消息为急需消息,在处理急需消息之前,往往需要等待一段时长,在消息处理者将急需消息之前的消息处理后,才能对急需消息进行处理,急需消息难以及时被消息处理者进行处理,出现消息延迟的现象,降低用户体验。
发明内容
为了解决以上至少一项问题,本申请提供一种消息处理方法、装置、服务端及存储介质。
第一方面,本申请提供一种消息处理方法,采用如下的技术方案:
一种消息处理方法,包括:
获取客户端发送的消息,并确定所述消息对应的消息类型;
根据所述消息类型,确定所述消息对应的优先等级,所述优先等级与消息的实时性呈正比例关系;
若所述优先等级高于预设优先等级,则对所述消息进行回调处理。
通过采用上述技术方案,在获取到客户端发送的消息时,通过确定消息的消息类型,以确定出消息类型对应的优先等级,并在优先等级高于预设优先等级时,也即当接收到的消息实时性要求高时,将实时性要求高的消息进行回调处理,不将该消息存储至原有的消息队列中,以便对实时性要求高的消息能够及时进行处理,从而可以减小等待的时长以及提高对实时性要求高的消息的处理效率,进而可以提升用户体验。
在一种可能的实现方式中,所述对所述消息进行回调处理,包括以下任一项:
将所述消息存储至第一预设队列,并基于所述第一预设队列对所述消息进行回调处理,所述第一预设队列用于存储高于所述预设优先等级的消息;
将所述消息存储至第二预设队列,并基于所述第二预设队列对所述消息进行回调处理,所述第二预设队列仅用于存储所述消息;
直接对所述消息进行回调处理。
通过采用上述技术方案,在对优先等级高于预设优先等级的消息进行回调处理时,一方面可以将消息存储至用于存储所有优先等级高于预设优先等级的消息队列中,并基于该队列进行回调处理,也就是说,将实时性较高的消息与实时性较低的消息分开存储以进行回调,从而可以进一步地减小等待的时长以及提高对实时性要求高的消息的处理效率;第二方面还可以将优先等级较高的消息存储至专用于存储该消息的第二预设队列内,也就是说,一个队列中仅存储当前接收的实时性较高的消息,以基于该队列进行消息回调处理,从而可以进一步地减小等待的时长以及提高对实时性要求高的消息的处理效率;第三方面还可以直接将消息进行回调处理,等待时长更短,实时性要求高的消息的处理效果更高,进一步可以提升用户体验。
在另一种可能的实现方式中,所述对所述消息进行回调处理,之前还包括:
基于所述消息中携带的属性信息,确定所述消息对应的处理等级,所述属性信息包括:发送所述消息的客户端信息、所述消息的发送设备信息以及所述客户端对应的用户信息中的至少一项,所述处理等级与消息的实时性呈正比例关系;
若所述处理等级高于预设处理等级,则基于所述消息类型,确定第三预设队列,所述第三预设队列为所述消息类型所对应的队列,且用于存储所述消息类型中高于所述预设处理等级的消息;
将所述消息存储至所述第三预设队列中;
其中,所述对所述消息进行回调处理,包括:
基于所述第三预设队列对所述消息进行回调处理。
通过采用上述技术方案,在对优先等级高于预设优先等级的消息进行回调处理之前,基于接收到的消息所对应的客户端信息、设备信息以及用户信息中的至少一项可以确定出该消息对应的处理等级,能够在该消息的处理等级高于预设等级时,将该消息暂存至该消息类型对应的第三预设队列,以进行回调,也就是说,即使该消息类型为实时性要求高的类型,也可以进一步的从实时性要求高的消息中选择出处理等级更高的消息,以分开存储回调,从而可以进一步地提高消息的回调效率,进一步地可以提高实时性要求高且处理等级较高的消息的处理效率。
在一种可能的实现方式中,所述确定所述消息对应的消息类型,包括以下任一项:
根据所述消息中携带的Key,并基于Key与消息类型之间的对应关系,确定所述消息对应的消息类型;
基于所述消息确定所述消息对应的Key,并基于所述Key与消息类型之间的对应关系,确定所述消息对应的消息类型。
通过采用上述技术方案,在确定消息对应的消息类型进而确定消息对应的优先等级时,一方面可以根据消息中携带的Key,确定消息对应的消息类型,另一方面还可以在获取到消息时,根据消息确定消息对应的Key,之后再确定消息对应的消息类型,从而可以为确定消息类型提供了两种可能的实现方式。
在一种可能的实现方式中,基于所述Key与消息类型之间的对应关系,确定所述消息对应的消息类型,之前还包括:
建立所述Key与消息类型之间的对应关系。
通过采用上述技术方案,预先建立的Key与消息类型之间的对应关系,以使得后续在接收到消息所对应的Key后,可以利用预先创建的对应关系,更为快速和准确地确定消息对应的消息类型,进而可以提升用户体验。
在一种可能的实现方式中,所述方法还包括以下任一项:
若所述优先等级不高于预设优先等级,则将所述消息存储至第四预设队列,并基于所述第四预设队列对所述消息进行回调处理,所述第四预设队列用于存储不高于预设优先等级的消息;
若所述优先等级不高于预设优先等级,则将所述消息存储至第五预设队列,并基于所述第五预设队列对所述消息进行回调处理,所述第五预设队列为所述消息类型对应的队列。
通过采用上述技术方案,对于优先等级不高于预设优先等级的消息,也即对于实时性要求较低的消息,一方面可以将消息与其他不高于预设优先等级的消息共同存储在第四预设队列内,基于第四预设队列进行回调处理,在第四预设队列内仅存储有优先等级不高于预设优先等级的消息,相较于将所有消息均存储至某一队列而言,消息处理的效率更高;另一方面,还可以根据消息对应的消息类型,确定消息类型对应的第五预设队列,将消息存储在第五预设队列内,第五预设队列内存储有与该消息具有相同消息类型的其他消息,将所有消息进行分类存储,分开回调,进一步地可以提高消息处理的效率。
第二方面,本申请提供一种消息处理装置,采用如下的技术方案:
一种消息处理装置,包括:
消息获取模块,用于获取客户端发送的消息;
类型确定模块,用于确定所述消息对应的消息类型;
等级确定模块,用于根据所述消息类型,确定所述消息对应的优先等级,所述优先等级与消息的实时性呈正比例关系;
优先回调模块,用于当所述优先等级高于预设优先等级时,对所述消息进行回调处理。
通过采用上述技术方案,在消息获取模块获取到客户端发送的消息时,由类型确定模块确定出消息的消息类型,之后由等级确定模块确定出消息类型对应的优先等级,并在优先等级高于预设优先等级时,也即当接收到的消息实时性要求高时,将实时性要求高的消息通过优先回调模块进行回调处理,不将该消息存储至原有的消息队列中,以便对实时性要求高的消息能够及时进行处理,从而可以减小等待的时长以及提高对实时性要求高的消息的处理效率,进而可以提升用户体验。
在一种可能的实现方式中,所述优先回调模块在对所述消息进行回调处理时,具体用于:
将所述消息存储至第一预设队列,并基于所述第一预设队列对所述消息进行回调处理,所述第一预设队列用于存储高于所述预设优先等级的消息;或者,
将所述消息存储至第二预设队列,并基于所述第二预设队列对所述消息进行回调处理,所述第二预设队列仅用于存储所述消息;或者,
直接对所述消息进行回调处理。
在一种可能的实现方式中,所述装置还包括:
处理等级确定模块,用于基于所述消息中携带的属性信息,确定所述消息对应的处理等级,所述属性信息包括:发送所述消息的客户端信息、所述消息的发送设备信息以及所述客户端对应的用户信息中的至少一项,所述处理等级与消息的实时性呈正比例关系;
队列确定模块,用于当所述处理等级高于预设处理等级时,基于所述消息类型,确定第三预设队列,所述第三预设队列为所述消息类型所对应的队列,且用于存储所述消息类型中高于所述预设处理等级的消息;
存储模块,用于将所述消息存储至所述第三预设队列中;
其中,所述优先回调模块在对所述消息进行回调处理时,具体用于:
基于所述第三预设队列对所述消息进行回调处理。
在一种可能的实现方式中,所述类型确定模块在确定所述消息对应的消息类型时,具体用于:
根据所述消息中携带的Key,并基于Key与消息类型之间的对应关系,确定所述消息对应的消息类型;或者,
基于所述消息确定所述消息对应的Key,并基于所述Key与消息类型之间的对应关系,确定所述消息对应的消息类型。
在一种可能的实现方式中,所述装置还包括:
建立模块,用于建立所述Key与消息类型之间的对应关系。
在一种可能的实现方式中,所述装置还包括第一回调模块或第二回调模块,其中:
所述第一回调模块,用于当所述优先等级不高于预设优先等级时,将所述消息存储至第四预设队列,并基于所述第四预设队列对所述消息进行回调处理,所述第四预设队列用于存储不高于预设优先等级的消息;
所述第二回调模块,用于当所述优先等级不高于预设优先等级,将所述消息存储至第五预设队列,并基于所述第五预设队列对所述消息进行回调处理,所述第五预设队列为所述消息类型对应的队列。
第三方面,本申请提供一种服务端,采用如下的技术方案:
一种服务端,该服务端包括:
至少一个处理器;
存储器;
至少一个应用程序,其中至少一个应用程序被存储在存储器中并被配置为由至少一个处理器执行,所述至少一个应用程序配置用于:执行上述消息处理的方法。
第四方面,本申请提供一种计算机可读存储介质,采用如下的技术方案:
一种计算机可读存储介质,包括:存储有能够被处理器加载并执行上述消息处理方法的计算机程序。
综上所述,本申请包括以下有益技术效果:
1、在获取到客户端发送的消息时,通过确定消息的消息类型,以确定出消息类型对应的优先等级,并在优先等级属于高于预设优先等级时,也即当接收到的消息实时性要求高时,将实时性要求高的消息进行回调处理,不将该消息存储至原有的消息队列中,以便对实时性要求高的消息能够及时进行处理,从而可以减小了等待的时长,以及提高了对实时性要求高的消息的处理效率,进而可以提升用户体验。
2、在对优先等级高于预设优先等级的消息进行回调处理时,一方面可以将消息存储至用于存储所有优先等级高于预设优先等级的消息队列中,并基于该队列进行回调处理,也就是说,将实时性较高的消息与实时性较低的消息分开存储以进行回调,从而可以进一步地减小等待的时长以及提高对实时性要求高的消息的处理效率;第二方面还可以将优先等级较高的消息存储至专用于存储该消息的第二预设队列内,也就是说,一个队列中仅存储当前接收的实时性较高的消息,以基于该队列进行消息回调处理,从而可以进一步地减小等待的时长以及提高对实时性要求高的消息的处理效率;第三方面还可以直接将消息进行回调处理,等待时长更短,实时性要求高的消息的处理效果更高,进一步可以提升用户体验。
附图说明
图1是本申请实施例消息处理方法的流程示意图;
图2是本申请实施例消息队列建立流程的示意图;
图3是本申请实施例消息处理系统的系统示意图;
图4是本申请实施例消息处理装置的方框示意图;
图5是本申请实施例服务端的示意图。
具体实施方式
以下结合附图1-5对本申请作进一步详细说明。
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
云游戏是以云计算为基础的游戏方式,在云游戏的运行模式下,所有游戏的存储、计算和渲染都将在服务端中运行,服务端将渲染完毕后的游戏画面压缩后通过网络发送至客户端,即传送给用户,客户端将传送过来得到游戏画面进行解压,用户即可通过客户端显示的视频进行游戏。对于用户而言,用户的游戏设备不需要高端处理器和显卡,只需要基本的视频解压能力就可以实现较佳的游戏效果。
用户在客户端通过鼠标、键盘、游戏手柄等操作设备输入数据,客户端记录下用户输入的数据,并将这些数据发送至服务端,服务端将接收到数据存储至消息队列中,之后由消息处理者从消息队列中取出消息,并对消息进行处理,形成视频数据反馈至客户端中,客户端解压该视频数据,在用户的显示设备上将显示对应的游戏视频,实现对用户的操作的响应。其中,客户端可以是安装有云游戏的电脑、手机、以及其他电子设备。
但是,在将消息存储至消息队列后,对于一些实时性要求较高的数据将等待较长时间才会响应处理,在客户端表现为用户输入一个操作后,需要等待一段时间才会响应,造成一定的延迟,严重影响用户的游戏体验。
为此,本申请实施例提供了一种消息处理方法,由服务端执行,该服务端可以为服务器也可以为终端设备,其中,该服务器可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云计算服务的云服务器。终端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机等,但并不局限于此,该终端设备以及服务器可以通过有线或无线通信方式进行直接或间接地连接,本申请实施例在此不做限制。
进一步地,如图1所示,该方法可以包括:
步骤S101、获取客户端发送的消息,并确定消息对应的消息类型。
其中,消息类型表征消息的类别。
具体地,将客户端产生的所有消息进行分类后,将形成多种消息类型,一个消息类型可能对应一个消息,也可能包括多个消息。当获取到客户端发送的消息时,确定消息对应的消息类型。
例如,在一种格斗类型的游戏中,当用户正式进入游戏之前,首先需要登录,用户在登录界面输入的消息对应一种消息类型,比如在登录界面,用户通过键鼠等操作设备输入账号和密码,此时,用户在登录界面通过操作设备输入的所有消息,均属于登录消息类型;用户在进入游戏之前,需要挑选角色与场景,在角色与场景界面输入的消息对应为一种消息类型,比如在角色选择界面以及场景选择界面,用户通过操作设备输入的消息,均属于选择消息类型;当用户进入游戏之后,在游戏内将进行双方格斗PK等操作动作,用户在实时游戏界面通过操作设备输入的所有消息,均属于操作消息类型。
其中,客户端发送的消息,可能为用户通过操作设备输入指令数据后,由客户端对该指令数据进行转换后生成的消息,例如上述示例中的操作消息类型对应的消息,以及登录消息类型对应的消息;客户端发送的消息还可能为客户端产生的有关系统的消息,例如心跳包消息等,其中,客户端系统产生的消息对应的消息类型为系统消息类型。当客户端将消息发送至服务端后,服务端获取到消息,根据消息确定出消息对应的消息类型。
步骤S102、根据消息类型,确定消息对应的优先等级。
其中,优先等级与消息的实时性呈正比例关系;也即消息的实时性要求越高,对应的消息处理时的优先等级越高,表征消息处理的实时性要求越高。
具体地,不同类型的消息对应的处理实时性要求不同,每个消息类型对应一个优先等级,不同消息类型对应的优先等级可能相同,也可能不同。根据消息的消息类型,即可确定消息对应的优先等级。以步骤S101中的示例继续说明,对于属于操作消息类型的消息,在用户通过操作设备输入对应的操作消息后,往往需要服务端实时响应用户的操作,也即操作消息类型对应的消息实时性要求最高,其对应的处理的优先等级也就最高,消息处理的及时性要求也最高。再例如,用户在选择角色和场景时输入的消息,对应的消息类型为选择消息类型,选择消息类型的消息实时性要求相对操作消息类型而言较低,在用户选择场景后,可以等待一秒或短暂时间再响应,故而对于选择消息类型对应的优先等级较低,实时性要求较低;再比如用户在登录界面输入的消息,属于登录消息类型,登录消息类型对应的优先等级较低,登录消息类型对应的优先等级低于操作消息类型对应的优先等级,而相对于选择消息类型的优先等级而言,两者的优先等级可能相同,也可能不同。
基于消息的实时性要求的不同,将各个消息类型划分为两个或多个优先等级,其中,优先等级越高,消息实时性要求越高,例如:优先等级按照由低到高的顺序依次为第一优先等级、第二优先等级......第n优先等级,第一优先等级最低,第n优先等级最高。再例如操作消息类型对应的消息实时性要求高,可能对应第五优先等级,选择消息类型对应的消息实时性要求较低,可能对应为第二优先等级。
步骤S103、若优先等级高于预设优先等级,则对消息进行回调处理。
其中,预设优先等级为预先设定的等级,例如,预设优先等级设定为第三优先等级,也就是说,高于预设优先等级的消息表征实时性要求较高。
具体地,预设优先等级为人为设定的优先等级,也可以是用户输入的优先等级,还可以为服务端预先设定的。若消息对应的优先等级高于预设优先等级,则表征消息的实时性要求高,需要及时处理此类消息,以便提供给用户更好的游戏体验。例如步骤S102示例中,属于操作消息类型的消息,若该消息对应的优先等级为第五优先等级,预设优先等级为第三优先等级,则操作消息类型对应的优先等级高于预设优先等级,若不能及时处理此类消息,则将严重影响用户的游戏体验,当检测到接收到操作消息类型的消息时,对接收到的消息进行回调处理。
为此,当消息对应的优先等级高于预设优先等级时,将对消息进行回调处理,而不将消息存储至原有的所有消息对应的消息队列中,不必等待对存储在该消息之前的所有消息进行处理,对于实时性要求高的消息能够及时进行处理,提高了处理消息的效率,进而提高了用户的游戏体验。
本申请实施例提供了一种消息处理方法,在获取到客户端发送的消息时,通过确定消息的消息类型,以确定出消息类型对应的优先等级,并在优先等级高于预设优先等级时,也即当接收到的消息实时性要求高时,将实时性要求高的消息进行回调处理,不将该消息存储至原有的消息队列中,以便对实时性要求高的消息能够及时进行处理,从而可以减小等待的时长以及提高对实时性要求高的消息的处理效率,进而可以提升用户体验。
进一步地,在本申请实施例中,接收客户端发送的消息的方式可以详见上述实施例,在接收到客户端发送的消息之后,确定消息对应的消息类型的方式,具体可以包括:方式一或者方式二,其中,
方式一:根据消息中携带的Key,并基于Key与消息类型之间的对应关系,确定消息对应的消息类型。
其中,Key,又称键值,位于注册表结构链末端,包含当前应用程序执行时使用的实际配置信息和数据。每个消息对应有一个唯一确定的Key。Key可以是消息对应的消息名称,还可以是其他用户自定义的键值。
具体地,客户端在将消息发送到服务端之前,预先确定出消息对应的Key,例如,在用户通过操作设备输入操作消息类型对应的操作消息时,该消息对应的Key为HandleMsg。之后,客户端将消息发送至服务端,在发送时,该消息对应的Key也被携带在消息中,例如,在发送操作消息时,HandleMsg也连同操作消息被发送至服务端,服务端在接收到消息时,消息中既包括操作消息对应的内容,还包括HandleMsg。在客户端将消息发送至服务端,服务端即可直接从消息中获取到该消息对应的Key,从而可以根据该消息对应的Key,以及消息的Key与消息类型之间的对应关系,确定该消息所对应的消息类型。
其中,消息的Key与消息类型之间的对应关系为预先建立好的关系,每个Key对应一个消息类型。具体地,在基于Key与消息类型之间的对应关系,确定消息对应的消息类型之前还可以包括:建立Key与消息类型之间的对应关系。每个消息对应有一个Key,消息对应一个消息类型,即一个Key对应一个消息类型,值的说明的是,一个消息类型可能对应一个Key,也可能对应多个Key。
在确定消息对应的消息类型之前,预先建立Key与消息类型之间的对应关系,服务端即可直接根据消息中携带的Key确定消息的消息类型,进而确定消息的优先等级,判断消息的实时性要求高低,以确定该消息的处理方式。
方式二:基于消息确定消息对应的Key,并基于Key与消息类型之间的对应关系,确定消息对应的消息类型。
具体地,在消息由客户端发送至服务端后,服务端预先根据消息确定消息对应的Key,之后再根据Key与消息类型的对应关系确定消息的消息类型,即可确定消息对应的消息类型。
其中,确定消息对应的Key的方式可以是自定义的,也是全局唯一的例如将各个消息的ID作为消息的Key;还可以是利用键值编码的方式,将消息所包含的信息的字符串作为键值等方式;另外,确定出消息对应的key后,在一种可能的实现方式中,该消息对应的key将保持不变,即消息对应的key为全局唯一的。在确定消息对应的Key时,可以利用哈希注册的方式进行确定,其中,哈希(Hash)是一种将任意长度的输入通过散列算法变换成固定长度输出的函数,输出的值为散列值,实质上是将任意长度的消息压缩到某一固定长度的消息摘要的函数,即将消息进行压缩,压缩后得到固定长度的消息摘要,这个消息摘要即可作为对应的Key,Key与消息对应。在获取到消息时,对消息采取散列算法求值,得到具体的散列值,这个散列值即可作为Key。
如上述方式一所示,在确定消息对应的消息类型之前还可以包括:建立Key与消息类型之间的对应关系。具体建立的过程详见方式一所示的实施例,在此不再赘述。
进一步地,在根据消息的Key确定消息对应的消息类型之后,还需要根据消息类型与优先等级的对应关系,以进一步确定消息对应的优先等级。
进一步地,在确定出优先等级之后,对于优先等级高于预设优先等级的消息,即实时性要求高的消息,则单独进行回调处理,其中,对消息进行回调处理的方式,具体可以包括:步骤S1031a(图中未示出)、步骤S1031b(图中未示出)以及步骤S1031c(图中未示出)中的任一项,其中,
步骤S1031a、将消息存储至第一预设队列,并基于第一预设队列对消息进行回调处理。
其中,第一预设队列用于存储高于预设优先等级的消息。
具体地,第一预设队列内存储的消息为所有高于预设优先等级的消息,即所有的优先等级高于预设优先等级的消息均将被存储至第一预设队列。
例如,消息m1为优先等级高于预设优先等级的消息,将消息m1存储至第一预设队列内;消息n1为优先等级低于预设优先等级的消息,则不将消息n1存放至第一预设队列内;消息q1为优先等级高于预设优先等级的消息,则将消息q1存储至第一预设队列内,使得第一预设队列内仅存储高于预设优先等级的消息。
之后再基于第一预设队列进行消息的回调处理,第一预设队列对应有一个工作线程,通过第一预设队列对应的工作线程依次将第一预设队列内存储的消息进行回调处理,例如,第一预设队列内按照顺序依次存储有消息m1、消息q1、消息m2、消息m3,其中,该顺序为存储时间的先后顺序,消息m1较消息q1存储在前,服务端利用工作线程按照存储顺序依次从第一预设队列内进行消息回调处理,先回调消息m1,消息m1被处理后,消息m1将从第一预设队列内被删除,之后再回调消息m2,在回调消息m2时,若有消息q2被服务端接收,且消息q2的优先等级高于预设优先等级,则消息q2将被存储至消息m3之后,按照顺序依次等待工作线程的回调,在将消息m3回调之后,就对消息q2进行回调处理。
即,服务端在现有的消息队列的基础上,建立了一个专用的第一预设队列,第一预设队列仅用于回调实时性要求高的消息,即仅用于回调优先等级高于预设优先等级的消息。在本申请实施例中,通过直接基于第一预设队列,对第一预设队列内存储的消息进行回调处理,能够将实时性要求高的数据与实时性要求低的数据分开回调处理,从而可以提高消息处理的效率。
步骤S1031b、将消息存储至第二预设队列,并基于第二预设队列对消息进行回调处理。
其中,第二预设队列仅用于存储消息,该消息为优先等级高于预设优先等级的消息。
具体地,在消息的优先等级高于预设优先等级时,即该消息为实时性较高的消息,需要及时进行处理,此时将该消息单独存储至一个消息队列中,即单独存储至第二预设队列内,第二预设队列内将单独存储该消息,由于第二预设队列内仅存储有该消息,可以直接调用回调函数对该消息进行回调处理,相较于步骤S1031a的方式而言,处理消息的效率更高。
例如,消息类型m的优先等级高于预设优先等级,其中,消息m1、消息m2以及消息m3均属于消息类型m;消息m1将被存储于第二预设队列1中,消息m2将被存储于第二预设队列2中,消息m3存储于第二预设队列3中。也即每个消息对应一个队列,且每个队列内仅存储有一个消息。
进一步地,每个第二预设队列可以是服务端在获取到消息时实时建立的,在判断出消息对应的优先等级高于预设优先等级时,即创建一个第二预设队列,将消息存储至第二预设队列中,并基于第二预设队列进行回调处理;另一方面,确定消息对应的第二预设队列的方式还可以是,在服务端获取到消息并判断出消息属于实时性要求高的消息时,通过遍历服务端的各个消息队列,将服务端内部未存储有消息的其中一个消息队列作为该消息对应的第二预设队列,将消息存储在该第二预设队列中。另外,每个第二预设队列也可以是服务端预先创建好的,在获取到客户端发送的消息之前,预先建立预设个数的第二预设队列,例如,在服务端预先建立了5个第二预设队列,依次为第二预设队列1、第二预设队列2、第二预设队列3、第二预设队列4以及第二预设队列5。在接收到消息并判断出消息属于实时性要求高的消息时,基于预先建立的各个第二预设队列,分配消息对应的第二预设队列,将消息存储在对应的第二预设队列内。
具体地,分配消息对应的第二预设队列的方式可以是,按照各个第二预设队列的顺序,依次判断当前各个第二预设队列内是否存储有历史消息,若当前第二预设队列内存储有历史消息,则将下一个第二预设队列作为当前第二预设队列,继续执行判断当前第二预设队列内是否存储有历史消息的步骤,直至当前第二预设队列内未存储有历史消息,则将该当前第二预设队列作为当前获取到的消息对应的第二预设队列,将消息存储在该对应的第二预设队列内。例如:以服务端建立的5个第二预设队列为例继续说明,若当前获取到的消息为消息m9,且消息m9为优先等级高于预设优先等级的消息,按照第二预设队列的排列顺序,第二预设队列1为第一个第二预设队列,即为当前第二预设队列,首先判断第二预设队列1内是否存储有历史消息,若第二预设队列1内此时存储有消息m8,则将第二预设队列2作为当前第二预设队列,再判断第二预设队列2内是否存储有历史消息,若第二预设队列2内未存储任何消息,则第二预设队列2即为当前获取到的消息对应的第二预设队列,消息将被存储至第二预设队列2中。以使得将消息存储至第二预设队列中,且该第二预设队列内仅存储该消息。
步骤S1031c、直接对消息进行回调处理。
具体地,对于优先等级高于预设优先等级的消息,还可以不将消息存储于对应的预设队列内,而采用直接回调的方式,将消息进行回调处理,服务端在判断出消息的优先等级高于预设优先等级的消息时,将直接调用回调函数,就消息进行回调处理,减少了存储至对应的预设队列后,在预设队列内等待调取的时间,进一步提高了消息的处理效率,对于实时性要求高的消息,能够及时处理,减小延时停顿等情况的发生几率,进一步提高用户的使用体验。
进一步地,在对消息进行回调处理时,可以采用如步骤S1031a、步骤S1031b以及步骤S1031c三种实现方式中的任意一种,即,一方面可以采用上述步骤S1031a或步骤S1031b的方式将消息存储至对应的队列中,之后再回调处理;另一方面,还可以采用如步骤S1031c的方式,将消息直接进行回调。其次,还可以采用第四种实现方式中,即将同一种消息类型的消息放置在同一个预设队列内,对所有消息基于消息类型的不同,分开回调处理;另外,对于同一种消息类型的不同消息而言,不同消息可能对应有不同的实时性要求,即,不同消息也可能对应不同的处理等级,例如:对于操作消息类型的消息而言,不同云游戏的客户端产生不同的消息,流畅度要求更高的云游戏,其操作产生的消息的实时性要求更高,流畅度要求较低的云游戏,其操作产生的消息的实时性要求则较低,但所有操作消息类型对应的消息均为优先等级高于预设优先等级的消息。
为了对同一消息类型的不同消息,针对消息本身实时性要求的不同,在回调处理时能够分开回调处理,以对实时性要求更高的消息能够进一步提高处理效率,对消息进行回调处理,之前还可以包括:步骤Sa1(图中未示出)、步骤Sa2(图中未示出)以及步骤Sa3(图中未示出),其中,
步骤Sa1、基于消息中携带的属性信息,确定消息对应的处理等级。
其中,属性信息包括:发送消息的客户端信息、消息的发送设备信息以及客户端对应的用户信息中的至少一项,处理等级与消息的实时性呈正比例关系。
具体地,不同种类云游戏对应的发送消息的客户端不同,对应的同一种消息类型的消息的处理等级也不同;发送消息的客户端信息表征消息对应的云游戏的种类。例如,云游戏A为格斗类的云游戏,云游戏B为休闲类的云游戏,若在云游戏A对应的客户端中产生了操作消息类型的消息A,以及在云游戏B对应的客户端中产生了操作消息类型的消息B,消息A的实时性要求显著高于消息B对应的实时性要求,即消息A的处理等级将高于消息B的处理等级。
再有,对于用户而言,当使用高处理性能的设备进行游戏时,对游戏的响应速度的需求往往更高,即对于不同性能的消息的发送设备而言,其发出的消息的处理等级也存在不同,往往性能越高,处理等级越高。消息发送设备信息即为游戏设备的相关性能信息。
再有,客户端对应的用户信息包括用户的账号信息以及用户对云游戏的使用频次等信息,例如,当用户为VIP用户时,可以提供至用户更高的操作体验,当用户玩云游戏的频次较高时,表征用户为当前云游戏的忠实用户,也可以提供至用户更高的操作体验,为此,可以根据客户端对应的用户信息,确定客户端发送的消息的处理等级。
另外,在根据一项属性信息确定消息的处理等级时,其确定处理等级的标准单一,可能存在较大的偶然性,为了更加提高确定消息的处理等级的准确度,故而还可以由客户端信息、发送设备信息以及用户信息三项中的任意两项,以及三项,共同确定消息的处理等级,例如,以客户端信息和用户信息共同决定消息的处理等级。在采用多项属性信息确定处理等级时,可以根据各项属性信息对实时性的影响程度,进行比例划分,根据每项情况的分值,再乘以对应的比例,综合相加后得到相应的等级分值,等级分值越高处理等级越高,进而确定消息对应的处理等级。例如:采用客户端信息和用户信息共同决定消息的处理等级,各自对应的分值比例为70%以及30%,客户端信息为10分(满分为10分),用户信息为5分,则综合相加后为8.5分,根据综合后的分值,确定消息对应的处理等级。
处理等级为分级设置的等级,例如:处理等级按照由高到低的顺序依次为第一处理等级、第二处理等级......第n处理等级,其中第一处理等级最低,第n处理等级最高;上例所得到的8.5分对应的消息处理等级较高,对应为第五处理等级。
步骤Sa2、若处理等级高于预设处理等级,则基于消息类型,确定第三预设队列。
其中,第三预设队列为消息类型所对应的队列,且用于存储消息类型中高于预设处理等级的消息。
具体地,对于同一种消息类型的所有消息将被存储至同一个实时预设队列中,不同种类的消息类型将被存储至不同的实时预设队列中,例如:消息类型m、消息类型n以及消息类型q,消息类型m对应实时预设队列m,对应为消息类型m的所有消息将被存储至实时预设队列m中;消息类型q对应实时预设队列q,对应为消息类型q的所有消息将被存储至实时预设队列q中,消息类型n不属于优先等级高于实时预设优先等级的消息类型,无对应的实时预设队列。
进一步地,为了对同一消息类型中的处理等级高的消息进行分开回调,故而将实时预设队列拆分为第三预设队列和实时预设子队列,其中,对于一个消息类型对应的实时预设队列而言,第三预设队列专用于存储处理等级高于预设处理等级的消息;实时预设子队列用于存储处理等级不高于(即低于或等于)预设处理等级的消息。
其中,预设处理等级为预先设定的处理等级,例如:设定为如步骤Sa1示例中的第二处理等级。当消息的优先等级高于预设优先等级时,该消息已经被确定为实时性要求高的消息,此时,先根据消息类型,确定出消息对应的实时预设队列,之后再基于该消息,判断该消息的处理等级是否高于预设处理等级,当高于预设处理等级时,表征此时消息为实时性要求更高的消息,则该消息对应为实时预设队列中的第三预设队列。当不高于预设处理等级时,表征消息为实时性要求高,但是不需要再提高处理效率,此时该消息对应为实时预设子队列。例如:消息m1属于消息类型m,优先等级高于预设优先等级,对应的实时预设队列为实时预设队列m,实时预设队列m包括第三预设队列m以及实时预设子队列m,若消息m1的处理等级为第五处理等级,预设处理等级为第四处理等级,则消息m1的处理等级高于预设处理等级,该消息m1对应为第三预设队列m;若消息m1的处理等级为第四处理等级,不高于预设处理等级,则该消息m1对应为实时预设子队列m。
步骤Sa3、将消息存储至第三预设队列。
在上述实施例的基础上(也即在步骤Sa1、步骤Sa2以及步骤Sa3所对应的实现方式的基础上),对消息进行回调处理,具体可以包括:基于第三预设队列对消息进行回调处理。
若消息的处理等级高于预设处理等级,则在确定出消息对应的第三预设队列后,将消息存储至对应的第三预设队列,之后再基于第三预设队列对消息进行回调处理。
若消息的处理等级不高于预设处理等级,则在确定出消息对应的实时预设子队列后,将消息存储至对应的实时预设子队列,之后再基于实时预设子队列对消息进行回调处理。
对于同一消息类型的消息,根据处理等级的不同,对于处理等级高于预设处理等级的消息,表征其处理的实时性要求极高,因此将该消息另外存储至第三预设队列中,即再将实时性要求更高的消息独立出来进行回调处理,进一步提高了消息处理的效率。
进一步地,在本申请实施例中,对于优先等级高于预设优先等级的消息,将对消息进行回调处理,而对于优先等级不高于预设优先等级的消息而言,处理消息的方式,具体可以是方式一或者方式二,其中,
方式一:若优先等级不高于预设优先等级,则将消息存储至第四预设队列,并基于第四预设队列对消息进行回调处理。
其中,第四预设队列用于存储不高于预设优先等级的消息。
具体地,在服务端获取到消息时,根据消息的Key确定消息对应的消息类型,再根据消息类型确定消息对应的优先等级,当优先等级不高于预设优先等级时,即当优先等级低于或等于预设优先等级时,表征消息的实时性要求较低,对消息处理的效率要求相对较低,对用户游戏体验的影响也较低,因此对于此类消息可以继续将消息存储在预先建立好的消息队列内,即存储在第四预设队列中,所有优先等级不高于预设优先等级的消息将全部被放置在第四预设队列内,之后再从第四预设队列内进行消息回调处理。例如:消息a1对应的优先等级不高于预设优先等级,则将消息存储至第四预设队列内,之后,消息a2的优先等级也不高于预设优先等级,则将消息也存储至第四预设队列内,其中消息a1与消息a2可能属于同一消息类型,也可能不属于同一消息类型。
方式二:若优先等级不高于预设优先等级,则将消息存储至第五预设队列,并基于第五预设队列对消息进行回调处理。
其中,第五预设队列为消息类型对应的队列。
具体地,在消息的优先等级不高于预设优先等级时,即消息的处理实时性要求较低,此时,首先根据消息的消息类型,确定消息类型对应的消息队列,该消息类型对应的消息队列即为该消息将被存储的第五预设队列。
其中,对于优先等级不高于预设优先等级的消息类型,每种消息类型均对应有一个消息队列,每个消息队列均为预先建立好的队列,每个消息队列对应一种消息类型,还可以对应两种或三种等多种消息类型。优选的,消息队列与消息类型为一一对应关系,每一类消息对应一个消息队列。
例如,登录消息类型对应一个消息队列A1,选择消息类型对应一个消息队列A2,互动消息类型对应一个消息队列A3;或者登陆消息类型和选择消息类型共同对应一个消息队列B1,互动消息类型对应一个消息队列B2;其中,互动消息类型为在用户进行好友互动时输入的消息所属的类型。
在获取到优先等级不高于预设优先等级的消息时,将根据消息类型与消息队列的对应关系,确定出该消息对应的消息队列,将该消息对应的消息队列作为第五预设队列,并将消息存储至第五预设队列中。
例如:消息b1对应消息类型b,不高于预设优先等级,消息类型b对应的消息队列为第x预设队列,则将消息b1存储至第x预设队列内;消息c2对应的消息类型为消息类型c,消息类型c对应的消息对列为第y预设队列,消息c2对应的优先等级也不高于预设优先等级,则将消息c2存储至第y预设队列,其中,第x预设队列与第y预设队列不属于同一个消息队列;若接收到消息类型为消息类型b的消息b2,则消息b2将被存储至第x预设队列。
在进行消息回调处理时,每个消息队列对应一个work线程,通过work线程依次将对应的消息队列内存储的消息进行回调处理,对于优先等级不高于预设优先等级的消息,可以按照消息类型的不同进行分类存储,分类回调,相较于所有消息类型的消息均放置在一个消息队列中的方式而言,各自分开回调,进一步提高了消息处理的效率。
对于本申请实施例,参照图2,在进行消息获取之前,服务端首先利用消息系统注册模块,并通过所有消息各自对应的Key值,建立Key值与消息类型的对应关系,根据消息类型的不同注册不同的消息系统,其中,一个消息系统对应一个消息队列,消息队列为上述提到的第五预设队列,用于存储属于对应的消息类型的所有消息,且用于存储优先等级不高于预设优先等级的消息。
基于上述实施例,本申请实施例基于云游戏场景提供了一个示例,以说明消息处理的过程,参照图3,图3为消息处理系统的示意图,包括客户端、消息系统、消息队列系统、回调消息系统以及消息处理者,其中,消息处理者包括消息处理者1以及消息处理者2;用户在客户端进行游戏,并向消息系统发送消息,消息系统将高于预设优先等级的消息发送至回调消息系统,并通过回调消息系统进行回调,由消息处理者1进行处理;消息系统将不高于预设优先等级的消息发送至消息队列系统,将消息存储至对应的消息队列,再利用work线程将消息回调,由消息处理者2进行处理。
例如,当用户在客户端进行游戏时,首先登陆游戏,在游戏登陆界面通过键鼠设备输入账号和密码,客户端基于用户通过操作设备输入指令数据,并将指令数据转换为了相应的消息,将消息指令发送至服务端中,其中客户端在发送至服务端之前,预先基于消息确定出消息对应的Key,在将消息发送至服务端时,Key也被消息携带发送至服务端,服务端接收到消息后,也将一同获取到消息对应的Key,根据Key即确定出消息对应的消息类型,此时用户处于登录界面,服务端判断出该消息对应的消息类型为登录消息类型,预设优先等级为预先设定的第三优先等级,该消息对应的优先等级为第二优先等级,不高于预设优先等级,则先根据消息类型确定消息对应的第五预设队列,将该消息存储至该消息对应的第五预设队列中,该消息对应的第五预设队列仅用于存储属于登录消息类型的消息;之后再利用第五预设队列对应的work线程,依次从第五预设队列中回调消息,并将消息发送至消息处理者1,以令消息处理者1进行消息处理,对于实时性要求较低的消息能够分类进行存储,进一步提高消息处理的效率。
继续参照图3,当用户登录进游戏后,开始进行游戏,用户通过操作设备开始控制游戏中的角色移动或动作,此时,服务端接收到相应消息后,判断出消息属于操作消息类型,若该消息对应的优先等级为第五优先等级,则高于预设优先等级,将该消息直接发送至回调消息系统,直接将消息进行回调处理,以将消息发送至消息处理者2,令消息处理者2对实时性要求高的消息直接回调,进而减小了存储至消息队列的时间以及减少了等待的时间,提高了消息处理的效率。
值的说明的是,本申请实施例介绍的消息处理方法,不只适用于云游戏,还可以适用于网上商城等订单消息等业务场景中,在本申请中仅以云游戏作为示例进行说明,并不代表对本申请的应用场景进行限定。
上述实施例从方法流程的角度介绍一种消息处理的方法,下述实施例从虚拟模块或者虚拟单元的角度介绍了一种消息处理的装置,参照图4,具体详见下述实施例。
一种消息处理装置40,包括:
消息获取模块401,用于获取客户端发送的消息;
类型确定模块402,用于确定消息对应的消息类型;
等级确定模块403,用于根据消息类型,确定消息对应的优先等级,优先等级与消息的实时性呈正比例关系;
优先回调模块404,用于当优先等级高于预设优先等级时,对消息进行回调处理。
具体地,在消息获取模块401获取到客户端发送的消息时,由类型确定模块402确定出消息的消息类型,之后由等级确定模块403确定出消息类型对应的优先等级,并在优先等级高于预设优先等级时,也即当接收到的消息实时性要求高时,将实时性要求高的消息通过优先回调模块404进行回调处理,不将该消息存储至原有的消息队列中,以便对实时性要求高的消息能够及时进行处理,从而可以减小等待的时长以及提高对实时性要求高的消息的处理效率,进而可以提升用户体验。
本申请实施例的一种可能的实现方式,优先回调模块404在对消息进行回调处理时,具体用于:
将消息存储至第一预设队列,并基于第一预设队列对消息进行回调处理,第一预设队列用于存储高于预设优先等级的消息;或者,
将消息存储至第二预设队列,并基于第二预设队列对消息进行回调处理,第二预设队列仅用于存储消息;或者,
直接对消息进行回调处理。
本申请实施例的一种可能的实现方式,装置40还包括:
处理等级确定模块,用于基于消息中携带的属性信息,确定消息对应的处理等级,属性信息包括:发送消息的客户端信息、消息的发送设备信息以及客户端对应的用户信息中的至少一项,处理等级与消息的实时性呈正比例关系;
队列确定模块,用于当处理等级高于预设处理等级时,基于消息类型,确定第三预设队列,第三预设队列为消息类型所对应的队列,且用于存储消息类型中高于预设处理等级的消息;
存储模块,用于将消息存储至第三预设队列中;
其中,优先回调模块在对消息进行回调处理时,具体用于:
基于第三预设队列对消息进行回调处理。
本申请实施例的一种可能的实现方式,类型确定模块402在确定消息对应的消息类型时,具体用于:
根据消息中携带的Key,并基于Key与消息类型之间的对应关系,确定消息对应的消息类型;或,
基于消息确定消息对应的Key,并基于Key与消息类型之间的对应关系,确定消息对应的消息类型。
本申请实施例的一种可能的实现方式,装置40还包括:
建立模块,用于建立Key与消息类型之间的对应关系。
本申请实施例的一种可能的实现方式,装置40还包括第一回调模块或者第二回调模块,其中:
第一回调模块用于当优先等级不高于预设优先等级时,将消息存储至第四预设队列,并基于第四预设队列对消息进行回调处理,第四预设队列用于存储不高于预设优先等级的消息;
第二回调模块用于当优先等级不高于预设优先等级时,将消息存储至第五预设队列,并基于第五预设队列对消息进行回调处理,第五预设队列为消息类型对应的队列。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
本申请实施例还从实体装置的角度介绍了一种服务端,如图5所示,图5所示的服务端50包括:处理器501和存储器503。其中,处理器501和存储器503相连,如通过总线502相连。可选地,服务端50还可以包括收发器504。需要说明的是,实际应用中收发器504不限于一个,该服务端50的结构并不构成对本申请实施例的限定。
处理器501可以是CPU(Central Processing Unit,中央处理器),通用处理器,DSP(Digital Signal Processor,数据信号处理器),ASIC(Application SpecificIntegrated Circuit,专用集成电路),FPGA(Field Programmable Gate Array,现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框,模块和电路。处理器501也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,DSP和微处理器的组合等。
总线502可包括一通路,在上述组件之间传送信息。总线502可以是PCI(Peripheral Component Interconnect,外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture,扩展工业标准结构)总线等。总线502可以分为地址总线、数据总线、控制总线等。为便于表示,图5中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
存储器503可以是ROM(Read Only Memory,只读存储器)或可存储静态信息和指令的其他类型的静态存储设备,RAM(Random Access Memory,随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备,也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory,电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory,只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。
存储器503用于存储执行本申请方案的应用程序代码,并由处理器501来控制执行。处理器501用于执行存储器503中存储的应用程序代码,以实现前述方法实施例所示的内容。
其中,服务端包括但不限于:移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。还可以为服务器等,在本申请实施例中,该服务器可以为云端服务器。图5示出的服务端仅仅是一个示例,不应对本申请实施例的功能和使用范围带来任何限制。
本申请实施例提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,当其在计算机上运行时,使得计算机可以执行前述方法实施例中相应内容。在本申请实施例中,在获取到客户端发送的消息时,通过确定消息的消息类型,以确定出消息类型对应的优先等级,并在优先等级属于高于预设优先等级时,也即当接收到的消息实时性要求高时,将实时性要求高的消息进行回调处理,不将该消息存储至原有的消息队列中,以便对实时性要求高的消息能够及时进行处理,从而可以减小了等待的时长,以及提高了对实时性要求高的消息的处理效率,进而可以提升用户体验。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,以上实施例仅用以对本申请的技术方案进行了详细介绍,但以上实施例的说明只是用于帮助理解本申请的方法及其核心思想,不应理解为对本申请的限制。本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本申请的保护范围之内。

Claims (7)

1.一种消息处理方法,其特征在于,包括:
获取客户端发送的消息,并确定所述消息对应的消息类型;
根据所述消息类型,确定所述消息对应的优先等级,所述优先等级与消息的实时性呈正比例关系;
若所述优先等级高于预设优先等级,则对所述消息进行回调处理;
所述对所述消息进行回调处理,包括:将所述消息存储至第二预设队列,并基于所述第二预设队列对所述消息进行回调处理,所述第二预设队列仅用于存储所述消息;在消息的优先等级高于预设优先等级时,将该消息单独存储至第二预设队列内,第二预设队列内将单独存储该消息,其中,每个消息对应一个第二队列,且每个队列内仅存储有一个消息;
分配消息至对应的第二预设队列的方式包括,按照各个第二预设队列的顺序,依次判断当前各个第二预设队列内是否存储有历史消息,若当前第二预设队列内存储有历史消息,则将下一个第二预设队列作为当前第二预设队列,继续执行判断当前第二预设队列内是否存储有历史消息的步骤,直至当前第二预设队列内未存储有历史消息,则将该当前第二预设队列作为当前获取到的消息对应的第二预设队列,将消息存储在该对应的第二预设队列内。
2.根据权利要求1所述的方法,其特征在于,所述确定所述消息对应的消息类型,包括以下任一项:
根据所述消息中携带的Key,并基于Key与消息类型之间的对应关系,确定所述消息对应的消息类型;
基于所述消息确定所述消息对应的Key,并基于所述Key与消息类型之间的对应关系,确定所述消息对应的消息类型。
3.根据权利要求2所述的方法,其特征在于,基于所述Key与消息类型之间的对应关系,确定所述消息对应的消息类型,之前还包括:
建立所述Key与消息类型之间的对应关系。
4.根据权利要求1所述的方法,其特征在于,所述方法还包括以下任一项:
若所述优先等级不高于预设优先等级,则将所述消息存储至第四预设队列,并基于所述第四预设队列对所述消息进行回调处理,所述第四预设队列用于存储不高于预设优先等级的消息;
若所述优先等级不高于预设优先等级,则将所述消息存储至第五预设队列,并基于所述第五预设队列对所述消息进行回调处理,所述第五预设队列为所述消息类型对应的队列。
5.一种消息处理装置,其特征在于,包括:
消息获取模块,用于获取客户端发送的消息;
类型确定模块,用于确定所述消息对应的消息类型;
等级确定模块,用于根据所述消息类型,确定所述消息对应的优先等级,所述优先等级与消息的实时性呈正比例关系;
优先回调模块,用于当所述优先等级高于预设优先等级时,对所述消息进行回调处理;
所述优先回调模块在对所述消息进行回调处理时,具体用于:
将所述消息存储至第二预设队列,并基于所述第二预设队列对所述消息进行回调处理,所述第二预设队列仅用于存储所述消息;在消息的优先等级高于预设优先等级时,将该消息单独存储至第二预设队列内,第二预设队列内将单独存储该消息,其中,每个消息对应一个第二队列,且每个队列内仅存储有一个消息;
分配消息至对应的第二预设队列的方式包括,按照各个第二预设队列的顺序,依次判断当前各个第二预设队列内是否存储有历史消息,若当前第二预设队列内存储有历史消息,则将下一个第二预设队列作为当前第二预设队列,继续执行判断当前第二预设队列内是否存储有历史消息的步骤,直至当前第二预设队列内未存储有历史消息,则将该当前第二预设队列作为当前获取到的消息对应的第二预设队列,将消息存储在该对应的第二预设队列内。
6.一种服务端,其特征在于,该服务端包括:
至少一个处理器;
存储器;
至少一个应用程序,其中至少一个应用程序被存储在存储器中并被配置为由至少一个处理器执行,所述至少一个应用程序配置用于:执行权利要求1~4任一项所述的消息处理方法。
7.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,当所述计算机程序在计算机中执行时,令所述计算机执行权利要求1~4任一项所述的消息处理方法。
CN202210987809.2A 2022-08-17 2022-08-17 一种消息处理方法、装置、服务端及存储介质 Active CN115348231B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210987809.2A CN115348231B (zh) 2022-08-17 2022-08-17 一种消息处理方法、装置、服务端及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210987809.2A CN115348231B (zh) 2022-08-17 2022-08-17 一种消息处理方法、装置、服务端及存储介质

Publications (2)

Publication Number Publication Date
CN115348231A CN115348231A (zh) 2022-11-15
CN115348231B true CN115348231B (zh) 2023-12-12

Family

ID=83951325

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210987809.2A Active CN115348231B (zh) 2022-08-17 2022-08-17 一种消息处理方法、装置、服务端及存储介质

Country Status (1)

Country Link
CN (1) CN115348231B (zh)

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102685032A (zh) * 2012-05-31 2012-09-19 苏州阔地网络科技有限公司 一种网络会议的消息处理方法及系统
CN102685250A (zh) * 2012-05-31 2012-09-19 苏州阔地网络科技有限公司 一种消息调度处理方法及系统
CN106161192A (zh) * 2015-04-08 2016-11-23 阿里巴巴集团控股有限公司 一种消息处理的方法及设备
CN108156093A (zh) * 2018-01-25 2018-06-12 中科边缘智慧信息科技(苏州)有限公司 适于低带宽弱连接环境的多应用数据传输方法和系统
KR20190057818A (ko) * 2017-11-20 2019-05-29 광운대학교 산학협력단 차등적인 IoT 서비스를 제공하는 우선순위 기반의 MQTT 시스템 및 방법
CN110198351A (zh) * 2019-05-29 2019-09-03 深圳前海微众银行股份有限公司 离线消息的存储方法、装置、服务端及可读存储介质
CN111404838A (zh) * 2020-03-17 2020-07-10 上海云励科技有限公司 消息处理方法、装置及设备
CN114265753A (zh) * 2021-12-27 2022-04-01 中国农业银行股份有限公司 消息队列的管理方法、管理系统和电子设备
CN114327948A (zh) * 2021-12-28 2022-04-12 北京京东拓先科技有限公司 消息处理方法、装置、设备及存储介质
CN114428693A (zh) * 2022-03-31 2022-05-03 季华实验室 一种调节消息优先级的方法、装置、电子设备及存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10148738B2 (en) * 2014-11-12 2018-12-04 Zuora, Inc. System and method for equitable processing of asynchronous messages in a multi-tenant platform

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102685032A (zh) * 2012-05-31 2012-09-19 苏州阔地网络科技有限公司 一种网络会议的消息处理方法及系统
CN102685250A (zh) * 2012-05-31 2012-09-19 苏州阔地网络科技有限公司 一种消息调度处理方法及系统
CN106161192A (zh) * 2015-04-08 2016-11-23 阿里巴巴集团控股有限公司 一种消息处理的方法及设备
KR20190057818A (ko) * 2017-11-20 2019-05-29 광운대학교 산학협력단 차등적인 IoT 서비스를 제공하는 우선순위 기반의 MQTT 시스템 및 방법
CN108156093A (zh) * 2018-01-25 2018-06-12 中科边缘智慧信息科技(苏州)有限公司 适于低带宽弱连接环境的多应用数据传输方法和系统
CN110198351A (zh) * 2019-05-29 2019-09-03 深圳前海微众银行股份有限公司 离线消息的存储方法、装置、服务端及可读存储介质
CN111404838A (zh) * 2020-03-17 2020-07-10 上海云励科技有限公司 消息处理方法、装置及设备
CN114265753A (zh) * 2021-12-27 2022-04-01 中国农业银行股份有限公司 消息队列的管理方法、管理系统和电子设备
CN114327948A (zh) * 2021-12-28 2022-04-12 北京京东拓先科技有限公司 消息处理方法、装置、设备及存储介质
CN114428693A (zh) * 2022-03-31 2022-05-03 季华实验室 一种调节消息优先级的方法、装置、电子设备及存储介质

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
Message Queue Telemetry Transport Broker with Prioriy Support for Emergency Events in Internet of Things;Yong-Seong Kim et al.;Sersors and Materials;全文 *
郝永康.面向弱连接窄带宽环境的IP业务传输适配方法设计与实现.《中国优秀硕士学位论文全文数据库》.2022,全文. *
面向 LEO/GEO 卫星网络的多路径多业务路由策略;王娟等;《南京邮电大学学报》;正文第1-2章 *

Also Published As

Publication number Publication date
CN115348231A (zh) 2022-11-15

Similar Documents

Publication Publication Date Title
CN109395372B (zh) 实现游戏手柄远程操控电脑游戏的方法、系统与电子设备
US20190065135A1 (en) Dynamic Server-Side Image Sizing For Fidelity Improvements
US11940903B2 (en) Testing systems and methods
CN111586164B (zh) 远程云桌面的分享、接替、信息处理方法及电子设备
US20060277319A1 (en) Optimizing message transmission and delivery in a publisher-subscriber model
US8595303B2 (en) Thread data aggregation
CN115348222B (zh) 一种消息分发方法、装置、服务端及存储介质
CN113489805B (zh) 一种云桌面系统的对接方法、装置、设备及存储介质
CN109766315B (zh) 文件展示方法及终端、计算机存储介质、计算机设备
CN109636460B (zh) 一种业务处理方法、装置、设备及存储介质
CN116431282A (zh) 一种云虚拟主机服务器管理方法、装置、设备及存储介质
WO2022095741A1 (zh) 获取游戏道具的方法和装置
CN115348231B (zh) 一种消息处理方法、装置、服务端及存储介质
CN106487653B (zh) 一种消息处理方法及服务器
CN109710502A (zh) 日志传输方法、装置及存储介质
CN112291325A (zh) 一种消息的处理方法、装置及计算机系统
CN112468874A (zh) 一种视频播放方法、终端设备及系统
CN111800491A (zh) 一种数据传输方法、系统、计算设备及存储介质
WO2023098012A1 (zh) 弹幕显示方法及装置
CN113824689B (zh) 边缘计算网络、数据传输方法、装置、设备和存储介质
CA2833346C (en) Reducing latency for served applications by anticipatory preprocessing
KR20200108348A (ko) 데이터 전송
WO2017088382A1 (zh) 数据处理的方法和装置
CN111130983B (zh) 信息发送、生成结果信息的方法和设备
CN111163217A (zh) 一种手机游戏用户匹配方法、装置和服务器

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant