CN115878304A - 消息发送方法、接收方法、装置、设备及存储介质 - Google Patents
消息发送方法、接收方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN115878304A CN115878304A CN202111142612.0A CN202111142612A CN115878304A CN 115878304 A CN115878304 A CN 115878304A CN 202111142612 A CN202111142612 A CN 202111142612A CN 115878304 A CN115878304 A CN 115878304A
- Authority
- CN
- China
- Prior art keywords
- message
- clients
- virtual room
- client
- condition
- 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.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
本申请实施例公开了一种消息发送方法、接收方法、装置、设备及存储介质,属于通信技术领域。所述方法包括:获取虚拟房间对应的待下发的消息;在虚拟房间中的客户端数量满足第一条件的情况下,服务器主动将消息推送至虚拟房间中的客户端;在虚拟房间中的客户端数量满足第二条件的情况下,服务器在接收到来自客户端的消息拉取请求后,将消息发送给客户端。本申请实施例提供的技术方案,通过根据虚拟房间中的客户端数量,自动切换消息的发送方式,在客户端数量少的情况下,切换为推送方式,以进行消息发送,在客户端数量多的情况下,切换为拉取方式,以进行消息发送,在保证消息发送的实时性的同时,降低了消息发送过程中所需占用的机器资源。
Description
技术领域
本申请实施例涉及通讯技术领域,特别涉及一种消息发送方法、接收方法、装置、设备及存储介质。
背景技术
随着通信技术的发展,人们可以进行在线互动,诸如在线会议、教育、直播、聊天等。其中,消息的发送对在线互动有着重要的影响。
在相关技术中,采用推送方式进行消息的发送。例如,在服务器与客户端之间建立一条WebSocket(一种基于TCP(Transmission Control Protocol,传输控制协议)的全双工通信协议)通道,服务器在获取消息后,通过WebSocket通道将消息主动推送至客户端。
然而,在服务器需要推送至的客户端数量较多(如百万级)的情况下,相关技术会存在消息发送的延时较高的问题,从而导致消息的发送不够实时。
发明内容
本申请实施例提供了一种消息发送方法、接收方法、装置、设备及存储介质,能够在保证消息发送的实时性的同时,降低消息发送过程中所需占用的机器资源。技术方案如下:
根据本申请实施例的一个方面,提供了一种消息发送方法,所述方法包括:
获取虚拟房间对应的待下发的消息;
将所述消息存储至分布式缓存中;
在所述虚拟房间中的客户端数量满足第一条件的情况下,采用第一下发方式发送所述消息;其中,所述第一下发方式是指服务器主动向所述虚拟房间中的客户端推送所述消息的下发方式;
在所述虚拟房间中的客户端数量满足第二条件的情况下,采用第二下发方式发送所述消息;其中,所述第二下发方式是指所述服务器在接收到来自所述客户端的消息拉取请求后,将所述消息发送给所述客户端的下发方式。
根据本申请实施例的一个方面,提供了一种消息接收方法,所述方法包括:
显示虚拟房间的用户界面;
接收所述虚拟房间对应的消息;其中,在所述虚拟房间中的客户端数量满足第一条件的情况下,所述消息是服务器主动向所述虚拟房间中的客户端推送的,在所述虚拟房间中的客户端数量满足第二条件的情况下,所述消息是所述服务器在接收到来自所述客户端的消息拉取请求后,发送给所述客户端的;
基于所述消息,更新显示所述用户界面。
根据本申请实施例的一个方面,提供了一种消息发送装置,所述装置包括:
消息获取模块,用于获取虚拟房间对应的待下发的消息;
消息存储模块,用于将所述消息存储至分布式缓存中;
消息发送模块,用于在所述虚拟房间中的客户端数量满足第一条件的情况下,采用第一下发方式发送所述消息;其中,所述第一下发方式是指服务器主动向所述虚拟房间中的客户端推送所述消息的下发方式;
所述消息发送模块,还用于在所述虚拟房间中的客户端数量满足第二条件的情况下,采用第二下发方式发送所述消息;其中,所述第二下发方式是指所述服务器在接收到来自所述客户端的消息拉取请求后,将所述消息发送给所述客户端的下发方式。
根据本申请实施例的一个方面,提供了一种消息接收装置,所述装置包括:
界面显示模块,用于显示虚拟房间的用户界面;
消息接收模块,用于接收所述虚拟房间对应的消息;其中,在所述虚拟房间中的客户端数量满足第一条件的情况下,所述消息是服务器主动向所述虚拟房间中的客户端推送的,在所述虚拟房间中的客户端数量满足第二条件的情况下,所述消息是所述服务器在接收到来自所述客户端的消息拉取请求后,发送给所述客户端的;
界面更新模块,用于基于所述消息,更新显示所述用户界面。
根据本申请实施例的一个方面,提供了一种计算机设备,所述计算机设备包括处理器和存储器,所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现上述消息发送方法,或实现上述消息接收方法。
可选地,所述计算机设备为终端或服务器。
根据本申请实施例的一个方面,提供了一种计算机可读存储介质,所述可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以上述消息发送方法,或实现上述消息接收方法。
根据本申请实施例的一个方面,提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述消息发送方法,或执行上述消息接收方法。
本申请实施例提供的技术方案可以带来如下有益效果:
通过设置在虚拟房间中的客户端数量满足第一条件的情况下,服务器主动向客户端推送消息,在虚拟房间中的客户端数量满足第二条件的情况下,服务器在接收到来自客户端的消息拉取请求后,向客户端发送消息,实现了消息的发送方式的自动切换。在客户端数量少的情况下,切换为推送方式,以解决在客户端数量少的情况下,拉取方式下的消息的发送时延较高的问题,在客户端数量多(如百万级)的情况下,切换为拉取方式,以解决在客户端数量多的情况下,推送方式下的消息的发送时延较高和机器资源占用较多的问题,从而实现了在保证消息发送的实时性的同时,降低了消息发送过程中所需占用的机器资源。
另外,由于本申请实现了推送方式和拉取方式的自动切换,而不用受限于单一的消息发送方式只适用于特定场景下的消息推送,从而扩展了消息发送的适用场景,进而提高了消息发送的适用性。
另外,通过将消息存储至分布式缓存中,可实现消息发送过程中,丢失消息的拉取补偿,从而提高了消息发送的可靠性。此外,由于可从分布式缓存中快速获取消息,从而提高了消息的获取效率,进一步提高了消息发送的实时性。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请一个实施例提供的方案实施环境的示意图;
图2是本申请一个实施例提供的消息发送方法的流程图;
图3是本申请另一个实施例提供的第一下发方式的示意图;
图4是本申请一个实施例提供的参与客户端分组下的第一下发方式的示意图;
图5是本申请一个实施例提供的二级协程池下的第一下发方式的示意图;
图6是本申请一个实施例提供的双集群部署下的第一下发方式的示意图;
图7是本申请一个实施例提供的第二下发方式的示意图;
图8是本申请一个实施例提供的无状态消息拉取服务下的第二下发方式的示意图;
图9是本申请一个实施例提供的最新消息和丢失消息的获取方法的示意图;
图10是本申请一个实施例提供的消息接收方法的流程图;
图11是本申请一个实施例提供的用户界面的示意图;
图12是本申请一个实施例提供的教师客户端发起点名指令的示意图;
图13是本申请一个实施例提供的点名提示窗口的示意图;
图14是本申请一个实施例提供的教师客户端发起问答指令的示意图;
图15是本申请一个实施例提供的学生客户端侧的临时答题卡的示意图;
图16是本申请一个实施例提供的教师客户端侧的临时答题卡的示意图;
图17是本申请一个实施例提供的消息发送装置的框图;
图18是本申请一个实施例提供的消息接收装置的框图;
图19是本申请一个实施例提供的终端的结构框图;
图20是本申请一个实施例提供的服务器的结构框图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
请参考图1,其示出了本申请一个实施例提供的方案实施环境的示意图。该方案实施环境可以实现成为一个消息传输系统,该方案实施环境可以包括:终端11和服务器12。
终端11可以是诸如手机、平板电脑、多媒体播放设备、PC(Personal Computer,个人计算机)、可穿戴设备、智能电视、车载终端等电子设备。终端11中可以安装运行目标应用程序的客户端,该目标应用程序可以是任意一个具有消息传输需求的应用程序。例如,该目标应用程序可以是在线会议类应用程序、在线教育类应用程序、娱乐直播类应用程序、会话聊天类应用程序等,本申请实施例对此不作限定。
服务器12可以用于为终端11中的目标应用程序(如在线教育类应用程序)的客户端提供后台服务。例如,服务器12可以是上述目标应用程序(如在线教育类应用程序)的后台服务器,其可以为上述目标应用程序提供消息管理、消息存储、消息收发等服务。服务器12可以是一台服务器,也可以是由多台服务器组成的服务器集群,或者是一个云计算服务中心。
终端11和服务器12之间可以通过网络13进行互相通信。该网络13可以是有线网络,也可以是无线网络。
本申请实施例提供的技术方案可应用于云会议、云教育、云社交等场景中。
示例性地,以云会议为例。用户通过目标应用程序(如在线会议类应用程序)的客户端创建会议室(即虚拟房间),其它用户通过对应的客户端加入该会议室,会议室中的客户端将消息发送至目标应用程序对应的服务器,该服务器将消息发送至会议室中的各个客户端,以及将消息存储至分布式缓存中。会议室中的客户端基于消息,更显显示对应的用户界面。可选地,在会议室中的客户端数量较少的情况下,服务器主动向客户端推送消息,在会议室中的客户端数量较多的情况下,服务器在接收到来自客户端的消息拉取请求后,向客户端发送消息。
请参考图2,其示出了本申请一个实施例提供的消息发送方法的流程图。该方法各步骤的执行主体可以是图1所示方案实施环境中的服务器12。该方法可以包括如下几个步骤(201~204):
步骤201,获取虚拟房间对应的待下发的消息。
虚拟房间是指一种可以提供在线实时交流的虚拟网络空间,用户可以通过该虚拟房间进行在线实时交流。可选地,在不同的应用场景中,该虚拟网络空间可以有不同的名称,如会议室、频道、语音房、直播间、聊天室等。本申请实施例对虚拟房间中的客户端数量不做限定。示例性地,以在线教育场景为例,该虚拟房间可以以班级、年级等为单位,还可以不设置客户端数量的上限(例如公开讲座等场景)。例如,对于一个真实的班级,建立一个对应的虚拟房间,该虚拟房间中包括该班级对应的学生、教师、助理等对应的客户端。可选地,还可以在该虚拟房间中建立多个小虚拟房间,每个小虚拟房间中可以包括指定的学生。其中,学生对应的客户端可称为学生客户端,教师对应的客户端可称为教师客户端,教师客户端在该虚拟房间中为主导客户端,其可以发起答题、点名、语音交流、视频交流等交互。
虚拟房间对应的待下发的消息是指需要发送至虚拟房间中的一个客户端或多个客户端的消息。该消息可以是由虚拟房间中的各个客户端生成的消息(诸如聊天消息、礼物消息、会议消息等),也可以是由服务器生成的消息(诸如通知消息、系统消息、推送消息等)。示例性地,在在线会议场景中,该虚拟房间可以被称为会议室(如语音会议室、视频会议室等),会议室对应的待下发的消息可以包括客户端生成聊天消息、语音消息、视频消息等,会议室对应的待下发的消息还可以包括服务器生成的引导指示、推送消息等。可选地,本申请实施例对消息的形式不做限定,其可以为信息、指令、请求、反馈、通知等形式。
步骤202,将消息存储至分布式缓存中。
分布式缓存是指运用在分布式环境中的缓存,其可用于解决数据库服务器和Web服务器之间的瓶颈。分布式缓存由一个服务端实现管理和控制,由多个客户端节点存储数据。可选地,本申请可以采用诸如Redis(Remote Dictionary Server,远程字典服务)、MenCache(高性能缓存)、SSDB(一种非关系型数据库)等分布式缓存系统来实现消息的存储。
可选地,可以键值对的形式对消息进行存储,在一个示例中,消息的存储过程可以如下:以目标存储形式将消息存储至分布式缓存中;其中,目标存储形式包括以下至少之一:房间维度缓存和个人维度缓存,房间维度缓存中,虚拟房间的标识形成的键值和虚拟房间对应的待下发的消息对应存储,个人维度缓存中,用户的标识和虚拟房间的标识形成的键值,与用户对应的待下发的消息对应存储。
示例性地,以在线会议场景为例。对于目标会议室,分别采用会议室维度缓存(即房间维度缓存)和个人维度缓存对消息进行存储。在采用会议室维度缓存的形式下,将目标会议室的标识(如会议室号)和目标会议室对应的待下发的消息对应存储,在采用个人维度缓存的形式下,将由目标用户的标识(如用户帐号)和目标会议室的标识(如会议室号)形成的键值和目标用户对应的待下发的消息对应存储。例如,在需要获取目标会议室对应的消息时,只需根据目标会议室的标识即可获取目标会议室对应的待下发的消息,而无需逐个获取目标会议室中的各个用户对应的待下发的消息,提高了消息的获取效率。在需要获取目标用户对应的待下发的消息时,只需根据目标会议室的标识和目标用户的标识即可获取目标用户对应的待下发的消息,从而实现了消息的精准获取。
本申请实施例通过将消息存储至分布式缓存中,在消息发送过程中,出现消息丢失的情况下,可以通过拉取方式从分布式缓存中拉取到丢失消息。此外,在采用拉取方式拉取消息的情况下,可以直接从分布式缓存中获取消息(如在有相同消息获取的需求下),而无需通过查询数据库来获取消息,从而减少了消息的查取耗时,进而提高了消息的获取效率。
步骤203,在虚拟房间中的客户端数量满足第一条件的情况下,采用第一下发方式发送消息;其中,第一下发方式是指服务器主动向虚拟房间中的客户端推送消息的下发方式。
可选地,上述第一条件可以是指虚拟房间中的客户端数量小于阈值,例如,该阈值可以为一万,其可以根据实际使用需求进行适应性设定与调整。上述第一条件还可以是指虚拟房间中的在线客户端数量小于阈值,本申请实施例对此不做限定。例如,在虚拟房间中的在线客户端数量小于一万的情况下,采用第一下发方式发送消息。在一个可行的示例中,在虚拟房间对应的流量小于设定阈值的情况下,也可以采用第一下发方式发送消息。
其中,在采用第一下发方式(即推送方式)发送消息的情况下,服务器在获取到虚拟房间对应的待下发的消息之后,实时地主动地对消息进行推送,从而提高了消息的发送实时性。
可选地,在服务器确定出消息的下发方式之后,可以将消息的下发方式通知到客户端,以使得客户端采取对应的接收方式。例如,在采用第一下发方式的情况下,客户端只需接收来自服务器的消息,在采用第二下发方式的情况下,客户端需要主动向服务器发送消息拉取请求,以获取消息。
在一个示例中,推送方式下的消息发送过程可以如下:通过消息推送服务将消息添加至消息队列中;通过消息派遣服务从消息队列中获取消息,以及将消息推送给虚拟房间中的参与客户端,该参与客户端是指虚拟房间中处于在线状态的客户端。
可选地,消息推送服务是一种用于实现消息推送功能的应用程序。该消息推送服务可用于获取虚拟房间对应的待下发的消息,又可用于将消息存储至分布式缓存,还可用于将消息添加至消息队列中。其中,消息队列是指一种用于存放消息的数据结构,消息可以从消息队列的队尾入队,从消息队列的队头出队。
示例性地,参考图3,服务器(如图3中的业务服务器301)获取虚拟房间对应的实时消息(如聊天消息、礼物消息、答题消息等),业务服务器301调用消息推送服务302,以通过消息推送服务302从上述实时消息中筛选出待下发的消息,以及查询出待下发的消息所需要推送至的参与客户端的地址信息(如参与客户端的标识)。消息推送服务302可将待下发的消息添加至消息队列304中,以及将待下发的消息存储至分布式缓存303中。
例如,在在线教育场景中,业务服务器301获取教师客户端生成的答题指令,该答题指令需要推送至虚拟房间中的所有参与客户端,则消息推送服务302需要先确定出所有参与客户端(即所有在线客户端),以及查询出所有参与客户端的标识,以使得消息派遣服务305可将该答题指令准确推送至所有参与客户端(如图3中终端306对应的参与客户端)。对于虚拟房间中的离线客户端,在离线客户端重新上线的情况下,可以直接从分布式缓存303中获取待下发的消息。
可选地,消息派遣服务是一种用于实现消息派遣功能的应用程序。示例性地,参考图3,消息派遣服务305从消息队列304中获取消息(即待下发的消息),以及获取消息对应的参与客户端的标识,根据参与客户端的标识将该消息推送至参与客户端(如图3中终端306中的参与客户端)。
在一个示例中,在消息派遣服务进行消息推送过程中,还可以对消息对应的参与客户端进行分组,得到多个参与客户端分组;通过多个消息派遣服务分别对多个参与客户端分组进行消息的推送。
示例性地,参考图4,假设某一消息需要被推送至1000个参与客户端,每100个参与客户端组成一个参与客户端分组,则可以获取10个参与客户端分组。业务服务器401调用10个消息派遣服务(即图4中的n为10),通过该10个消息派遣服务分别同时对10个参与客户端分组进行消息的推送。例如,在消息派遣服务1将消息推送至10个参与客户分组中的第1个参与客户分组中的100个参与客户端的同时,消息派遣服务2也对第2个参与客户分组中的100个参与客户端进行消息推送。本申请实施例通过对参与客户端进行分组,实现了消息发送的横向扩展,从而提高了消息的发送效率,进而提高了消息发送的实时性。
可选地,消息派遣服务(如上述10个消息派遣服务、下文中的第一消息派遣服务、第二消息派遣服务等)还可以包括第一协程池和第二协程池,第一协程池中包括用于对消息进行组包的协程,第二协程池中包括用于获取参与客户端的地址信息的协程。在将消息推送给虚拟房间中的参与客户端之前,还可以包括如下内容:从第一协程池中调用第一协程,以通过第一协程对消息进行组包;从第二协程池中调用第二协程,以通过第二协程获取消息对应的参与客户端,以及参与客户端的地址信息。
其中,第一协程池中可以包括多个第一协程,第一协程可用于对消息进行组包。例如,第一协程按照传输协议将消息组包成特定格式的数据(如字符串数据、XML(ExtensibleMarkup Language,可扩展标记语言)格式数据等)。第二协程池中可以包括多个第二协程,第二协程用于获取消息对应的参与客户端和参与客户端的地址信息(如参与客户端的标识)。
例如,参考图5,消息派遣服务501包括第一协程池和第二协程池,在消息派遣服务501从消息队列中获取消息之后,第一协程池中的第一协程对消息进行组包,第二协程池中的第二协程获取消息对应的参与客户端和参与客户端对应的地址信息,最后消息派遣服务501根据参与客户端的地址信息将消息推送至对应的参与客户端。
本申请实施例通过将消息派遣服务设置为二级协程池的模式,确保了消息的精准发送。同时,有效减少了IO(Input Output,输入输出流)的等待时长,从而提高了消息的发送效率,进一步提高了消息发送的实时性。
在一个示例中,还可以基于双集群部署的技术将消息划分成核心消息和非核心消息,以减少非核心消息的发送对核心消息的发送造成影响,保证核心消息发送的稳定性,其具体包括如下内容:通过消息推送服务基于核心消息配置和非核心消息配置,对消息进行划分,得到核心消息和非核心消息;其中,核心消息配置和非核心消息配置是消息推送服务从分布式配置中心中获取的;通过消息推送服务将核心消息添加至核心消息队列中,以及将非核心消息添加至非核心消息队列中。
其中,核心消息配置用于指导消息推送服务辨识出核心消息,非核心消息配置用于指导消息推送服务辨识出非核心消息,核心消息配置和非核心消息配置存储在分布式配置中心。对于不同的场景,核心消息和非核心消息的定义不同。示例性地,以在线教育场景为例。若教师客户端发起举手指令,则与该举手指令相关的消息(如举手指令、学生客户端针对举手指令的反馈消息)为核心消息,其它的消息(如聊天消息、礼物消息等)为非核心消息。
核心消息队列用于存储核心消息,非核心消息队列用于存储非核心消息,如此,在非核心消息的发送出现故障(如堵塞)的情况下,也不会影响到核心消息的发送。
可选地,消息派遣服务还可以包括第一消息派遣服务集群和第二消息派遣服务集群;其中,第一消息派遣服务集群中包括多个第一消息派遣服务,第二消息派遣服务集群中包括多个第二消息派遣服务。可选地,第一消息派遣服务用于对核心消息队列中的核心消息进行推送,第二消息派遣服务用于对非核心消息队列中的非核心消息进行推送。则可以从第一消息派遣服务集群中调用第一消息派遣服务,以通过第一消息派遣服务将核心队列中的核心消息推送给参与客户端,从第二消息派遣服务集群中调用第二消息派遣服务,以通过第二消息派遣服务将非核心队列中的非核心消息推送给参与客户端。
示例性地,参考图6,消息推送服务601从分布式配置中心602中获取核心消息配置和非核心消息配置,并根据核心消息配置和非核心消息配置对消息进行划分,确定消息是核心消息还是非核心消息,若消息为核心消息,则将该消息添加至核心消息队列603中,若消息为非核心消息,则将该消息添加至非核心消息队列604中。通过第一消息派遣服务605将核心队列603中的消息推送给参与客户端,通过第二消息派遣服务606将非核心队列604中的消息推送给参与客户端。
如此,在某个第一消息派遣服务出现故障的情况下,可以使用其它的第一消息派遣服务接替该第一消息派遣服务继续运行,从而保证核心消息的稳定发送。在某个第二消息派遣服务出现故障的情况下,可以使用其它的第二消息派遣服务接替该第二消息派遣服务继续运行,从而保证非核心消息的稳定发送。同时,由于消息派遣服务分为第一消息派遣集群和第二消息派遣集群,在第二消息派遣集群出现故障的情况下,也不会影响到核心消息的发送,从而进一步保证了核心消息的发送稳定性和实时性。
步骤204,在虚拟房间中的客户端数量满足第二条件的情况下,采用第二下发方式发送消息;其中,第二下发方式是指服务器在接收到来自客户端的消息拉取请求后,将消息发送给客户端的下发方式。
可选地,上述第二条件可以是指虚拟房间中的客户端数量大于阈值,例如,该阈值可以为一万,其可以根据实际适用需求进行适应性设定与调整。上述第二条件还可以是指虚拟房间中的在线客户端数量大于阈值,本申请实施例对此不做限定。例如,在虚拟房间中的在线客户端数量大于一万的情况下,采用第二下发方式发送消息。可选地,可以将虚拟房间中的客户端数量等于阈值的情况划分到第一条件,也可以将虚拟房间中的客户端数量等于阈值的情况划分到第二条件,本申请实施例对此不做限定。在一个可行的示例中,在虚拟房间对应的流量大于或等于设定阈值的情况下,也可以采用第二下发方式发送消息。
其中,在虚拟房间中的客户端数量满足第二条件的情况下,如果采用第一下方方式发送消息,消息队列中的消息将会存在较高的推送时延,在这种情况下,相对于继续采用第一下发方式,通过切换为采用第二下发方式(即拉取方式),可以降低消息的推送时延,从而保证消息的发送实时性。在一个示例中,通过实现推送方式和拉取方式的自动切换,可保证消息在2秒内被发送至参与客户端。此外,在虚拟房间中的客户端数量满足第二条件的情况下,通过切换为采用第二下发方式,能够有效减少消息派遣服务运行过程中的毛刺(也即推送任务突增导致的毛刺),从而避免了机器资源的占用率的增加。在一个示例中,相关技术中的最大扩散量为2.5亿/分钟,采用本申请实施例提供的技术方案之后,最大扩散量为1400万/分钟,扩散量毛刺减少10倍,节省机器资源50%以上。
在一个示例中,第二下发方式下的消息发送过程可以如下:响应于接收到来自虚拟房间中的参与客户端的消息拉取请求,通过消息拉取服务从分布式缓存中获取消息;其中,消息拉取请求是虚拟房间中的参与客户端按照设定时间间隔发送的,参与客户端是指虚拟房间中处于在线状态的客户端;将消息发送给参与客户端。
其中,消息拉取请求用于请求获取消息(即待下发的消息)。消息拉取请求中可以包括参与客户端的标识(如用户的标识)和虚拟房间的标识,以使得服务器可以精准地从可分布式缓存中获取消息,以及精准地将消息发动给参与客户端。上述设定时间间隔可以根据实际使用需求进行适应性地设置和调整。
消息拉取服务是一种用于实现消息拉取功能的应用程序,其可以用于根据参与客户端的标识和/或虚拟房间的标识从可分布式缓存中获取消息。
示例性地,参考图7,业务服务器701从分布式配置中心702中获取阈值配置,并根据阈值配置确定阈值,在检测到虚拟房间中的参与客户端数量大于阈值的情况下,采用第二下方方式发送消息。也即消息推送服务703直接将消息存储至分布式缓存704中,而不再将消息添加至消息队列中。业务服务器701在接收到来自参与客户端(如图7中的终端707对应的参与客户端)的消息拉取请求(如HTTPS(Hyper Text Transfer Protocol overSecureSocket Layer,SecureSocket层上的超文本传输协议)形式的请求)之后,通过负载均衡器706对消息拉取请求进行分摊,然后调用消息拉取服务705针对消息拉取请求,从分布式缓存704中拉取消息,最后业务服务器701将消息发送至参与客户端。
可选地,还可以采用多级缓存技术对消息进行存储,以降低分布式缓系统的压力,同时可支持高频的消息拉取请求。示例性地,在消息拉取服务获取消息之后(如将消息发送给参与客户端之后,或将消息发送给参与客户端之前),还可以将消息存储至消息拉取服务对应的本地缓存中;响应于针对目标消息的消息拉取请求,在本地缓存中存储有目标消息的情况下,从本地缓存中获取目标消息;将目标消息发送给参与客户端。
其中,该目标消息可以是最新消息(如虚拟房间中的多个参与客户端所需的虚拟房间对应的同一最新消息)、下文的丢失消息、历史消息等。消息拉取服务对应的本地缓存是指消息拉取服务对应的进程内缓存(也即托管堆缓存)。
示例性地,参考图7,若在消息拉取服务705对应的本地缓存中有所需的消息(如上述目标消息),则无需再从分布式缓存704中拉取消息,可以直接将所需的消息发送至参与客户端,从而提高了消息的获取效率,进而提高了消息的发送实时性。可选地,在上述实施例中,还可以进行负载均衡器级的缓存、HTTPS级的缓存等,本申请实施例对此不做限定。
在一个示例中,还可以将消息拉取服务设置为无状态,以使得消息拉取服务可横向扩展,从而实现支持海量参与客户端的接入。示例性地,将多个消息拉取服务被设置为无状态,以使得多个消息拉取服务中的任一消息拉取服务,可以对多个消息拉取请求中的任一消息拉取请求,进行消息的获取。例如,在接收到多个消息拉取请求的情况下,可以通过多个消息拉取服务分别针对多个消息拉取请求,进行消息的获取。
其中,无状态服务是指没有特殊状态的服务,各个请求对于服务器来说可以统一无差别处理,也即可以调用任一服务对请求进行处理。在本申请实施例中,无状态消息拉取服务与消息拉取请求解耦合,也即无状态消息拉取服务可以对任一消息拉取请求进行处理。
例如,参考图8,服务器在接收到来自m个参与客户端的消息拉取请求之后,通过负载均衡器801对m个消息拉取请求进行分摊,调用n个消息拉取服务(n等于m)分别对m个消息拉取请求进行处理。例如,假设消息拉取服务1对消息拉取请求1(请求获取目标消息)进行处理,若检测到本地缓存中没有目标消息,则从分布式缓存802中获取目标消息,然后将目标消息发送至消息拉取请求1对应的参与客户端1。若检测到本地缓存中有目标消息,则直接将目标消息发送至参与客户端1。在消息拉取服务1对消息拉取请求1进行处理的过程中,剩余n-1个消息拉取服务也分别对m-1个消息拉取请求进行处理。
在一个示例中,可以采用如下方法进行丢失消息的拉取补偿:接收来自参与客户端的丢失消息拉取请求;其中,丢失消息拉取请求是参与客户端在检测到消息的版本号不连续的情况下生成的,该丢失消息拉取请求中包括丢失的版本号,版本号是服务器采用自增的方式生成的;基于丢失的版本号,从本地缓存或分布式缓存中获取丢失的版本号对应的丢失消息;将丢失消息发送给参与客户端。其中,丢失消息拉取请求用于请求拉取丢失消息。
示例性地,参考图9,假设服务器902已经进行了版本号10之前的消息(包括版本号为10的消息,以下简称消息10)的发送,虚拟房间中的最新消息为消息11和消息12,在虚拟房间中的参与客户端901再次向服务器902发送消息拉取请求的情况下,可以获取消息11和消息12。可选地,在参与客户端901检测到消息的版本号不连续的情况下,可将丢失的版本号对应的消息确定为丢失消息,并生成包括丢失的版本号的丢失消息拉取请求。参与客户端901将该丢失消息拉取请求发送至服务器902,服务器902通过消息拉取服务根据丢失的版本号(如图9中的版本号3、5、和7)获取丢失消息(如图9中的消息3、消息5和消息7),并将丢失消息发送至参与客户端901。
通过采用本申请实施例提供的丢失消息的拉取补偿方法,可以使得消息的到达率满足99.99%,从而保证消息发送的稳定性和到达率。
在一个示例中,在消息对应于客户端的情况下,基于客户端的地址信息,将消息发送给客户端。该客户端可以是指虚拟房间中的任一客户端,如此,在需要的情况下,可以将消息发送至指定客户端。
在消息对应于虚拟房间的情况下,基于虚拟房间的地址信息,将消息发送给虚拟房间中的各个客户端。该虚拟房间可以是指任一虚拟房间,也可以是指某一虚拟房间(如大班)中的小虚拟房间(如小班),如此,在需要的情况下,可以以虚拟房间为单位进行消息的发送。
在消息对应于平台的情况下,基于平台的标识信息,将消息发送给使用平台的客户端。本申请实施例对目标平台不做限定,诸如安卓系统、IOS系统等。如此,在需要的情况下,可以将消息发送至使用指定平台的客户端。
综上所述,本申请实施例提供的技术方案,通过设置在虚拟房间中的客户端数量满足第一条件的情况下,服务器主动向客户端推送消息,在虚拟房间中的客户端数量满足第二条件的情况下,服务器在接收到来自客户端的消息拉取请求后,向客户端发送消息,实现了消息的发送方式的自动切换。在客户端数量少的情况下,切换为推送方式,以解决在客户端数量少的情况下,拉取方式下的消息的发送时延较高的问题,在客户端数量多(如百万级)的情况下,切换为拉取方式,以解决在客户端数量多的情况下,推送方式下的消息的发送时延较高和机器资源占用较多的问题,从而实现了在保证消息发送的实时性的同时,降低了消息发送过程中所需占用的机器资源。
另外,由于本申请实现了推送方式和拉取方式的自动切换,而不用受限于单一的消息发送方式只适用于特定场景下的消息推送,从而扩展了消息发送的适用场景,进而提高了消息发送的适用性。
另外,通过将消息存储至分布式缓存中,可实现消息发送过程中,丢失消息的拉取补偿,从而提高了消息发送的可靠性。此外,由于可从分布式缓存中快速获取消息,从而提高了消息的获取效率,进一步提高了消息发送的实时性。
另外,在采用第一下发方式发送消息的过程中,通过对参与客户端分组、采用二级协程池对消息派遣服务进行设置、将消息划分为核心消息和非核心消息、以及采用双集群部署技术对消息队列、消息推送服务进行部署等一系列方法,进一步提高了消息发送的实时性。
另外,在采用第二下发方式发送消息的过程中,通过采用多级缓存技术对消息进行存储、以及将消息拉取服务设置为无状态等一系列方法,进一步提高了消息发送的实时性。
请参考图10,其示出了本申请一个实施例提供的消息接收方法的流程图。该方法各步骤的执行主体可以是图1所示方案实施环境中的终端11(如目标应用程序的客户端)。该方法可以包括如下几个步骤(1001~1003):
步骤1001,显示虚拟房间的用户界面。
虚拟房间是指一种可以提供在线实时交流的虚拟网络空间,本申请实施例中的虚拟房间与上述实施例介绍相同,这里不再赘述。
在本申请实施例中,用户界面是指上述目标应用程序的客户端对应的用户界面,该用户界面可以是诸如虚拟房间、会议室、直播间、语音房等形式的界面。该用户界面中可以显示有在线实时交流过程中的消息(如文字、语音、视频等)、虚拟房间中的客户端列表、消息列表、控件等内容,本申请实施例对用户界面的显示形式不做限定。示例性地,以在线教育场景为例,参考图11,在教师客户端对应的虚拟房间的用户界面1101中,显示有在线问答对应的统计结果1102、消息列表1104、控件1103(可用于开启在线视频交流)、控件1105(可用于切换至参与客户端列表)等。
步骤1002,接收虚拟房间对应的消息;其中,在虚拟房间中的客户端数量满足第一条件的情况下,该消息是服务器主动向虚拟房间中的客户端推送的,在虚拟房间中的客户端数量满足第二条件的情况下,该消息是服务器在接收到来自客户端的消息拉取请求后,发送给客户端的。
虚拟房间对应的消息可以是由虚拟房间中的各个客户端生成的消息,也可以是由服务器生成的消息。本申请实施例对消息的形式不做限定,其可以为信息、指令、请求、反馈、通知等形式。
示例性地,以在线教育场景为例。教师客户端可以在虚拟房间中发起交互。例如,参考图12,响应于教师针对用户界面1201中的目标学生的点名操作(例如,针对控件1202的触发操作,进行语音点名),教师客户端生成点名指令,并将该点名指令发送至虚拟房间对应的服务器,服务器将该点名指令发送至目标学生对应的客户端,目标学生对应的客户端在接收到该点名指令之后,根据该点名指令,执行对应的业务逻辑,显示点提示窗口。例如,参考图13,点名提示窗口1301中显示有提示信息“老师邀请你上台,需要开启麦克风功能,55s内不操作默认放弃上台”、用于拒绝上台的控件1302和用于接收点名并开启麦克风功能的控件1303。其中,点名指令和来自目标学生对应的客户端的反馈信息都为虚拟房间对应的消息。
参考图11,教师和学生可以在虚拟房间中进行聊天,聊天消息在消息列表1104中更新显示。采用本申请实施例提供的技术方案,即使在百万人同时在线的情况下,教师和学生也可以在虚拟房间中正常稳定地聊天。其中,聊天消息都为虚拟房间对应的消息。
参考图14,教师还可以在虚拟房间中发起答题交互,响应于教师设置完临时答题卡1401的情况下,生成答题指令,并将该答题指令发送至虚拟房间对应的服务器,服务器将该答题指令发送至学生客户端,学生客户端在接收到该点答题指令之后,根据该答题指令,执行对应的业务逻辑,显示临时答题卡。例如,参考图15,临时答题卡1501中显示有4个答案选项、答题倒计时和提交控件。其中,答题指令和来自学生客户端的答案选项都为虚拟房间对应的消息。采用本申请实施例提供的技术方案,即使在百万人同时在线的情况下,教师和学生也可以在虚拟房间中正常稳定地进行答题交互。
可选地,上述第一条件可以是指虚拟房间中的客户端数量小于阈值,上述第一条件还可以是指虚拟房间中的在线客户端数量小于阈值。上述第二条件可以是指虚拟房间中的客户端数量大于阈值,上述第二条件还可以是指虚拟房间中的在线客户端数量大于阈值。可选地,可以将虚拟房间中的客户端数量等于阈值的情况划分到第一条件,也可以将虚拟房间中的客户端数量等于阈值的情况划分到第二条件,本申请实施例对此不做限定。
可选地,在虚拟房间中的客户端数量满足第二条件的情况下,虚拟房间中的客户端(如参与客户端)可以按照设定时间间隔向服务器发送消息拉取请求。其中,消息拉取请求用于请求获取消息,该消息拉取请求中可以包括参与客户端的标识(如用户的标识)和虚拟房间的标识,以使得服务器可以精准地从可分布式缓存中获取消息,以及精准地将消息发动给参与客户端。上述设定时间间隔可以根据实际使用需求进行适应性地设置和调整。
可选地,在接收虚拟房间对应的消息之后,还可以响应于消息的版本号不连续,向服务器发送丢失消息拉取请求;其中,丢失消息拉取请求中包括丢失的版本号,版本号是服务器采用自增的方式生成的;获取来自服务器的丢失消息,该丢失消息是指丢失的版本号对应的消息。如此可以实现丢失消息的补偿拉取,从而提高了消息接收的获取率。
消息的具体发送过程,与上述实施例介绍相同,这里不再赘述。
步骤1003,基于消息,更新显示用户界面。
可选地,在消息为聊天消息的情况下,在用户界面中更新显示聊天消息。在消息为指令的情况下,执行该指令对应的业务逻辑,更新显示用户界面。在消息为通知的情况下,在用户界面中更新显示通知消息,本申请实施例对用户界面的更新显示方式不做限定。
示例性地,参考图16,在教师客户端发起答题交互的场景下,教师客户端在接收到来自学生客户端的答案选项之后,对答案选项进行统计,并在临时答题卡1601中显示答题交互结果。
综上所述,本申请实施例提供的技术方案,通过设置在虚拟房间中的客户端数量满足第一条件的情况下,服务器主动向客户端推送消息,在虚拟房间中的客户端数量满足第二条件的情况下,服务器在接收到来自客户端的消息拉取请求后,向客户端发送消息,实现了消息的发送方式的自动切换。在客户端数量少的情况下,切换为推送方式,以解决在客户端数量少的情况下,拉取方式下的消息的发送时延较高的问题,在客户端数量多(如百万级)的情况下,切换为拉取方式,以解决在客户端数量多的情况下,推送方式下的消息的发送时延较高和机器资源占用较多的问题,从而实现了在保证消息发送的实时性的同时,降低了消息发送过程中所需占用的机器资源。
另外,由于本申请实现了推送方式和拉取方式的自动切换,而不用受限于单一的消息发送方式只适用于特定场景下的消息推送,从而扩展了消息发送的适用场景,进而提高了消息发送的适用性。
另外,通过将消息存储至分布式缓存中,可实现消息发送过程中,丢失消息的拉取补偿,从而提高了消息发送的可靠性。此外,由于可从分布式缓存中快速获取消息,从而提高了消息的获取效率,进一步提高了消息发送的实时性。
下述为本申请装置实施例,可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节,请参照本申请方法实施例。
请参考图17,其示出了本申请一个实施例提供的弹幕显示装置的框图。该装置具有实现上述方法示例的功能,所述功能可以由硬件实现,也可以由硬件执行相应的软件实现。该装置可以是服务器,也可以设置在服务器中。该装置1700可以包括:消息获取模块1701、消息存储模块1702和消息发送模块1703。
消息获取模块1701,用于获取虚拟房间对应的待下发的消息。
消息存储模块1702,用于将所述消息存储至分布式缓存中。
消息发送模块1703,用于在所述虚拟房间中的客户端数量满足第一条件的情况下,采用第一下发方式发送所述消息;其中,所述第一下发方式是指服务器主动向所述虚拟房间中的客户端推送所述消息的下发方式。
所述消息发送模块1703,还用于在所述虚拟房间中的客户端数量满足第二条件的情况下,采用第二下发方式发送所述消息;其中,所述第二下发方式是指所述服务器在接收到来自所述客户端的消息拉取请求后,将所述消息发送给所述客户端的下发方式。
在一个示例性实施例中,所述消息发送模块1703,用于:
通过消息推送服务将所述消息添加至消息队列中;
通过消息派遣服务从所述消息队列中获取所述消息,以及将所述消息推送给所述虚拟房间中的参与客户端,所述参与客户端是指所述虚拟房间中处于在线状态的客户端。
在一个示例性实施例中,所述消息发送模块1703,还用于:
对所述消息对应的参与客户端进行分组,得到多个参与客户端分组;
通过多个所述消息派遣服务分别对所述多个参与客户端分组进行所述消息的推送。
在一个示例性实施例中,所述消息派遣服务包括第一协程池和第二协程池,所述第一协程池中包括用于对所述消息进行组包的协程,所述第二协程池中包括用于获取所述参与客户端的地址信息的协程;所述消息发送模块1703,还用于:
从所述第一协程池中调用第一协程,以通过所述第一协程对所述消息进行组包;
从所述第二协程池中调用第二协程,以通过所述第二协程获取所述消息对应的所述参与客户端,以及所述参与客户端的地址信息。
在一个示例性实施例中,所述消息发送模块1703,还用于:
通过所述消息推送服务基于核心消息配置和非核心消息配置,对所述消息进行划分,得到核心消息和非核心消息;其中,所述核心消息配置和非核心消息配置是所述消息推送服务从分布式配置中心中获取的;
通过所述消息推送服务将所述核心消息添加至核心消息队列中,以及将所述非核心消息添加至非核心消息队列中。
在一个示例性实施例中,所述消息派遣服务包括第一消息派遣服务集群和第二消息派遣服务集群;其中,所述第一消息派遣服务集群中包括多个第一消息派遣服务,所述第二消息派遣服务集群中包括多个第二消息派遣服务;所述消息发送模块1703,还用于:
从所述第一消息派遣服务集群中调用所述第一消息派遣服务,以通过所述第一消息派遣服务将所述核心队列中的所述核心消息推送给所述参与客户端;
从所述第二消息派遣服务集群中调用所述第二消息派遣服务,以通过所述第二消息派遣服务将所述非核心队列中的所述非核心消息推送给所述参与客户端。
在一个示例性实施例中,所述消息发送模块1703,还用于:
响应于接收到来自所述虚拟房间中的参与客户端的消息拉取请求,通过消息拉取服务从所述分布式缓存中获取所述消息;其中,所述消息拉取请求是所述虚拟房间中的参与客户端按照设定时间间隔发送的,所述参与客户端是指所述虚拟房间中处于在线状态的客户端;
将所述消息发送给所述参与客户端。
在一个示例性实施例中,所述消息发送模块1703,还用于:
将所述消息存储至所述消息拉取服务对应的本地缓存中;
响应于针对目标消息的消息拉取请求,在所述本地缓存中存储有所述目标消息的情况下,从所述本地缓存中获取所述目标消息;
将所述目标消息发送给所述参与客户端。
在一个示例性实施例中,所述消息发送模块1703,还用于:
在接收到多个所述消息拉取请求的情况下,通过多个所述消息拉取服务分别针对多个所述消息拉取请求,进行所述消息的获取;
其中,多个所述消息拉取服务被设置为无状态,以使得多个所述消息拉取服务中的任一所述消息拉取服务,对多个所述消息拉取请求中的任一所述消息拉取请求,进行所述消息的获取。
在一个示例性实施例中,所述消息存储模块1702,用于以目标存储形式将所述消息存储至所述分布式缓存中;其中,所述目标存储形式包括以下至少之一:房间维度缓存和个人维度缓存,所述房间维度缓存中,所述虚拟房间的标识形成的键值和所述虚拟房间对应的待下发的消息对应存储,所述个人维度缓存中,用户的标识和所述虚拟房间的标识形成的键值,与所述用户对应的待下发的消息对应存储。
在一个示例性实施例中,所述消息发送模块1703,还用于:
接收来自所述参与客户端的丢失消息拉取请求;其中,所述丢失消息拉取请求是所述参与客户端在检测到所述消息的版本号不连续的情况下生成的,所述丢失消息拉取请求中包括丢失的版本号,所述版本号是所述服务器采用自增的方式生成的;
基于所述丢失的版本号,从所述本地缓存或所述分布式缓存中获取所述丢失的版本号对应的丢失消息;
将所述丢失消息发送给所述参与客户端。
在一个示例性实施例中,所述消息发送模块1703,还用于:
在所述消息对应于所述客户端的情况下,基于所述客户端的地址信息,将所述消息发送给所述客户端;
或者,在所述消息对应于所述虚拟房间的情况下,基于所述虚拟房间的地址信息,将所述消息发送给所述虚拟房间中的各个所述客户端;
或者,在所述消息对应于平台的情况下,基于所述平台的标识信息,将所述消息发送给使用所述平台的客户端。
综上所述,本申请实施例提供的技术方案,通过设置在虚拟房间中的客户端数量满足第一条件的情况下,服务器主动向客户端推送消息,在虚拟房间中的客户端数量满足第二条件的情况下,服务器在接收到来自客户端的消息拉取请求后,向客户端发送消息,实现了消息的发送方式的自动切换。在客户端数量少的情况下,切换为推送方式,以解决在客户端数量少的情况下,拉取方式下的消息的发送时延较高的问题,在客户端数量多(如百万级)的情况下,切换为拉取方式,以解决在客户端数量多的情况下,推送方式下的消息的发送时延较高和机器资源占用较多的问题,从而实现了在保证消息发送的实时性的同时,降低了消息发送过程中所需占用的机器资源。
另外,由于本申请实现了推送方式和拉取方式的自动切换,而不用受限于单一的消息发送方式只适用于特定场景下的消息推送,从而扩展了消息发送的适用场景,进而提高了消息发送的适用性。
另外,通过将消息存储至分布式缓存中,可实现消息发送过程中,丢失消息的拉取补偿,从而提高了消息发送的可靠性。此外,由于可从分布式缓存中快速获取消息,从而提高了消息的获取效率,进一步提高了消息发送的实时性。
请参考图18,其示出了本申请一个实施例提供的消息接收装置的框图。该装置具有实现上述方法示例的功能,所述功能可以由硬件实现,也可以由硬件执行相应的软件实现。该装置可以是终端,也可以设置在终端中。该装置1800可以包括:界面显示模块1801、消息接收模块1802和界面更新模块1803。
界面显示模块1801,用于显示虚拟房间的用户界面。
消息接收模块1802,用于接收所述虚拟房间对应的消息;其中,在所述虚拟房间中的客户端数量满足第一条件的情况下,所述消息是服务器主动向所述虚拟房间中的客户端推送的,在所述虚拟房间中的客户端数量满足第二条件的情况下,所述消息是所述服务器在接收到来自所述客户端的消息拉取请求后,发送给所述客户端的。
界面更新模块1803,用于基于所述消息,更新显示所述用户界面。
在一个示例性实施例中,所述装置1800还包括请求发送模块(图18中未示出)。
请求发送模块,用于在所述虚拟房间中的客户端数量满足所述第二条件的情况下,按照设定时间间隔向所述服务器发送所述消息拉取请求。
在一个示例性实施例中,所述请求发送模块,还用于响应于所述消息的版本号不连续,向所述服务器发送丢失消息拉取请求;其中,所述丢失消息拉取请求中包括丢失的版本号,所述版本号是所述服务器采用自增的方式生成的。
所述消息接收模块1802,还用于获取来自所述服务器的丢失消息,所述丢失消息是指所述丢失的版本号对应的消息。
综上所述,本申请实施例提供的技术方案,通过设置在虚拟房间中的客户端数量满足第一条件的情况下,服务器主动向客户端推送消息,在虚拟房间中的客户端数量满足第二条件的情况下,服务器在接收到来自客户端的消息拉取请求后,向客户端发送消息,实现了消息的发送方式的自动切换。在客户端数量少的情况下,切换为推送方式,以解决在客户端数量少的情况下,拉取方式下的消息的发送时延较高的问题,在客户端数量多(如百万级)的情况下,切换为拉取方式,以解决在客户端数量多的情况下,推送方式下的消息的发送时延较高和机器资源占用较多的问题,从而实现了在保证消息发送的实时性的同时,降低了消息发送过程中所需占用的机器资源。
另外,由于本申请实现了推送方式和拉取方式的自动切换,而不用受限于单一的消息发送方式只适用于特定场景下的消息推送,从而扩展了消息发送的适用场景,进而提高了消息发送的适用性。
另外,通过将消息存储至分布式缓存中,可实现消息发送过程中,丢失消息的拉取补偿,从而提高了消息发送的可靠性。此外,由于可从分布式缓存中快速获取消息,从而提高了消息的获取效率,进一步提高了消息发送的实时性。
需要说明的是,上述实施例提供的装置,在实现其功能时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内容结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的装置与方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
请参考图19,其示出了本申请一个实施例提供的终端1900的结构框图。该终端1900可以是图1所示方案实施环境中的终端11。该终端1900可用于实施上述消息接收方法。具体来讲:
通常,终端1900包括有:处理器1901和存储器1902。
处理器1901可以包括一个或多个处理核心,比如4核心处理器、8核心处理器等。处理器1901可以采用DSP(Digital Signal Processing,数字信号处理)、FPGA(FieldProgrammable Gate Array,现场可编程门阵列)、PLA(Programmable Logic Array,可编程逻辑阵列)中的至少一种硬件形式来实现。处理器1901也可以包括主处理器和协处理器,主处理器是用于对在唤醒状态下的数据进行处理的处理器,也称CPU(Central ProcessingUnit,中央处理器);协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中,处理器1901可以在集成有GPU(Graphics Processing Unit,图像处理器),GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中,处理器1901还可以包括AI(Artificial Intelligence,人工智能)处理器,该AI处理器用于处理有关机器学习的计算操作。
存储器1902可以包括一个或多个计算机可读存储介质,该计算机可读存储介质可以是非暂态的。存储器1902还可包括高速随机存取存储器,以及非易失性存储器,比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中,存储器1902中的非暂态的计算机可读存储介质用于存储至少一条指令、至少一段程序、代码集或指令集,至少一条指令、至少一段程序、代码集或指令集经配置以由一个或者一个以上处理器执行,以实现上述消息接收方法。
在一些实施例中,终端1900还可选包括有:外围设备接口1903和至少一个外围设备。处理器1901、存储器1902和外围设备接口1903之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口1903相连。具体地,外围设备包括:射频电路1904、显示屏1905、摄像头组件1906、音频电路1907、定位组件1908和电源1909中的至少一种。
本领域技术人员可以理解,图19中示出的结构并不构成对终端1900的限定,可以包括比图示更多或更少的组件,或者组合某些组件,或者采用不同的组件布置。
请参考图20,其示出了本申请一个实施例提供的服务器的结构框图。该服务器2000可以是图1所示方案实施环境中的服务器12。该服务器可以用于实施上述实施例中提供的消息发送方法。具体来讲:
该服务器2000包括中央处理单元(如CPU(Central Processing Unit,中央处理器)、GPU(Graphics Processing Unit,图形处理器)和FPGA(Field Programmable GateArray,现场可编程逻辑门阵列)等)2001、包括RAM(Random-Access Memory,随机存取存储器)2002和ROM(Read-Only Memory,只读存储器)2003的系统存储器2004,以及连接系统存储器2004和中央处理单元2001的系统总线2005。该服务器2000还包括帮助服务器内的各个器件之间传输信息的基本输入/输出系统(Input Output System,I/O系统)2006,和用于存储操作系统2013、应用程序2014和其他程序模块2015的大容量存储设备2007。
在一些可选实施例中,该基本输入/输出系统2006包括有用于显示信息的显示器2008和用于用户输入信息的诸如鼠标、键盘之类的输入设备2009。其中,该显示器2008和输入设备2009都通过连接到系统总线2005的输入输出控制器2010连接到中央处理单元2001。该基本输入/输出系统2006还可以包括输入输出控制器2010以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地,输入输出控制器2010还提供输出到显示屏、打印机或其他类型的输出设备。
该大容量存储设备2007通过连接到系统总线2005的大容量存储控制器(未示出)连接到中央处理单元2001。该大容量存储设备2007及其相关联的计算机可读介质为服务器2000提供非易失性存储。也就是说,该大容量存储设备2007可以包括诸如硬盘或者CD-ROM(Compact Disc Read-Only Memory,只读光盘)驱动器之类的计算机可读介质(未示出)。
不失一般性,该计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、EPROM(Erasable Programmable Read-Only Memory,可擦写可编程只读存储器)、EEPROM(Electrically Erasable Programmable Read-Only Memory,电可擦写可编程只读存储器)、闪存或其他固态存储技术,CD-ROM、DVD(Digital Video Disc,高密度数字视频光盘)或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然,本领域技术人员可知该计算机存储介质不局限于上述几种。上述的系统存储器2004和大容量存储设备2007可以统称为存储器。
根据本申请实施例,该服务器2000还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器2000可以通过连接在该系统总线2005上的网络接口单元2011连接到网络2012,或者说,也可以使用网络接口单元2011来连接到其他类型的网络或远程计算机系统(未示出)。
该存储器还包括至少一条指令、至少一段程序、代码集或指令集,至少一条指令、至少一段程序、代码集或指令集存储于存储器中,且经配置以由一个或者一个以上处理器执行,以实现上述消息发送方法。
在一个示例性实施例中,还提供了一种计算机可读存储介质,所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集在被终端的处理器执行时以实现上述消息接收方法。
在一个示例性实施例中,还提供了一种计算机可读存储介质,所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集在被服务器的处理器执行时以实现上述消息发送方法。
可选地,该计算机可读存储介质可以包括:ROM(Read-Only Memory,只读存储器)、RAM(Random-Access Memory,随机存储器)、SSD(Solid State Drives,固态硬盘)或光盘等。其中,随机存取记忆体可以包括ReRAM(Resistance Random Access Memory,电阻式随机存取记忆体)和DRAM(Dynamic Random Access Memory,动态随机存取存储器)。
在一个示例性实施例中,还提供了一种计算机程序产品或计算机程序,所述计算机程序产品或计算机程序包括计算机指令,所述计算机指令存储在计算机可读存储介质中。终端的处理器从所述计算机可读存储介质中读取所述计算机指令,所述终端的处理器执行所述计算机指令,使得所述终端执行上述消息接收方法。
在一个示例性实施例中,还提供了一种计算机程序产品或计算机程序,所述计算机程序产品或计算机程序包括计算机指令,所述计算机指令存储在计算机可读存储介质中。服务器的处理器从所述计算机可读存储介质中读取所述计算机指令,所述服务器的处理器执行所述计算机指令,使得所述服务器执行上述消息发送方法。
应当理解的是,在本文中提及的“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。另外,本文中描述的步骤编号,仅示例性示出了步骤间的一种可能的执行先后顺序,在一些其它实施例中,上述步骤也可以不按照编号顺序来执行,如两个不同编号的步骤同时执行,或者两个不同编号的步骤按照与图示相反的顺序执行,本申请实施例对此不作限定。
以上所述仅为本申请的示例性实施例,并不用以限制本申请,凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
Claims (20)
1.一种消息发送方法,其特征在于,所述方法包括:
获取虚拟房间对应的待下发的消息;
将所述消息存储至分布式缓存中;
在所述虚拟房间中的客户端数量满足第一条件的情况下,采用第一下发方式发送所述消息;其中,所述第一下发方式是指服务器主动向所述虚拟房间中的客户端推送所述消息的下发方式;
在所述虚拟房间中的客户端数量满足第二条件的情况下,采用第二下发方式发送所述消息;其中,所述第二下发方式是指所述服务器在接收到来自所述客户端的消息拉取请求后,将所述消息发送给所述客户端的下发方式。
2.根据权利要求1所述的方法,其特征在于,所述采用第一下发方式发送所述消息,包括:
通过消息推送服务将所述消息添加至消息队列中;
通过消息派遣服务从所述消息队列中获取所述消息,以及将所述消息推送给所述虚拟房间中的参与客户端,所述参与客户端是指所述虚拟房间中处于在线状态的客户端。
3.根据权利要求2所述的方法,其特征在于,所述将所述消息推送给所述虚拟房间中的参与客户端,包括;
对所述消息对应的参与客户端进行分组,得到多个参与客户端分组;
通过多个所述消息派遣服务分别对所述多个参与客户端分组进行所述消息的推送。
4.根据权利要求2所述的方法,其特征在于,所述消息派遣服务包括第一协程池和第二协程池,所述第一协程池中包括用于对所述消息进行组包的协程,所述第二协程池中包括用于获取所述参与客户端的地址信息的协程;
所述将所述消息推送给所述虚拟房间中的参与客户端之前,还包括:
从所述第一协程池中调用第一协程,以通过所述第一协程对所述消息进行组包;
从所述第二协程池中调用第二协程,以通过所述第二协程获取所述消息对应的所述参与客户端,以及所述参与客户端的地址信息。
5.根据权利要求2所述的方法,其特征在于,所述通过消息推送服务将所述消息添加至消息队列中,包括:
通过所述消息推送服务基于核心消息配置和非核心消息配置,对所述消息进行划分,得到核心消息和非核心消息;其中,所述核心消息配置和非核心消息配置是所述消息推送服务从分布式配置中心中获取的;
通过所述消息推送服务将所述核心消息添加至核心消息队列中,以及将所述非核心消息添加至非核心消息队列中。
6.根据权利要求5所述的方法,其特征在于,所述消息派遣服务包括第一消息派遣服务集群和第二消息派遣服务集群;其中,所述第一消息派遣服务集群中包括多个第一消息派遣服务,所述第二消息派遣服务集群中包括多个第二消息派遣服务;
所述将所述消息推送给所述虚拟房间中的参与客户端,包括:
从所述第一消息派遣服务集群中调用所述第一消息派遣服务,以通过所述第一消息派遣服务将所述核心队列中的所述核心消息推送给所述参与客户端;
从所述第二消息派遣服务集群中调用所述第二消息派遣服务,以通过所述第二消息派遣服务将所述非核心队列中的所述非核心消息推送给所述参与客户端。
7.根据权利要求1所述的方法,其特征在于,所述采用第二下发方式发送所述消息,包括:
响应于接收到来自所述虚拟房间中的参与客户端的消息拉取请求,通过消息拉取服务从所述分布式缓存中获取所述消息;其中,所述消息拉取请求是所述虚拟房间中的参与客户端按照设定时间间隔发送的,所述参与客户端是指所述虚拟房间中处于在线状态的客户端;
将所述消息发送给所述参与客户端。
8.根据权利要求7所述的方法,其特征在于,所述将所述消息发送给所述参与客户端之后,还包括:
将所述消息存储至所述消息拉取服务对应的本地缓存中;
响应于针对目标消息的消息拉取请求,在所述本地缓存中存储有所述目标消息的情况下,从所述本地缓存中获取所述目标消息;
将所述目标消息发送给所述参与客户端。
9.根据权利要求7所述的方法,其特征在于,所述方法还包括:
在接收到多个所述消息拉取请求的情况下,通过多个所述消息拉取服务分别针对多个所述消息拉取请求,进行所述消息的获取;
其中,多个所述消息拉取服务被设置为无状态,以使得多个所述消息拉取服务中的任一所述消息拉取服务,对多个所述消息拉取请求中的任一所述消息拉取请求,进行所述消息的获取。
10.根据权利要求1所述的方法,其特征在于,所述将所述消息存储至分布式缓存中,包括:
以目标存储形式将所述消息存储至所述分布式缓存中;
其中,所述目标存储形式包括以下至少之一:房间维度缓存和个人维度缓存,所述房间维度缓存中,所述虚拟房间的标识形成的键值和所述虚拟房间对应的待下发的消息对应存储,所述个人维度缓存中,用户的标识和所述虚拟房间的标识形成的键值,与所述用户对应的待下发的消息对应存储。
11.根据权利要求1至10任一项所述的方法,其特征在于,所述方法还包括:
接收来自所述参与客户端的丢失消息拉取请求;其中,所述丢失消息拉取请求是所述参与客户端在检测到所述消息的版本号不连续的情况下生成的,所述丢失消息拉取请求中包括丢失的版本号,所述版本号是所述服务器采用自增的方式生成的;
基于所述丢失的版本号,从所述本地缓存或所述分布式缓存中获取所述丢失的版本号对应的丢失消息;
将所述丢失消息发送给所述参与客户端。
12.根据权利要求1至10任一项所述的方法,其特征在于,所述方法还包括:
在所述消息对应于所述客户端的情况下,基于所述客户端的地址信息,将所述消息发送给所述客户端;
或者,
在所述消息对应于所述虚拟房间的情况下,基于所述虚拟房间的地址信息,将所述消息发送给所述虚拟房间中的各个所述客户端;
或者,
在所述消息对应于平台的情况下,基于所述平台的标识信息,将所述消息发送给使用所述平台的客户端。
13.一种消息接收方法,其特征在于,所述方法包括:
显示虚拟房间的用户界面;
接收所述虚拟房间对应的消息;其中,在所述虚拟房间中的客户端数量满足第一条件的情况下,所述消息是服务器主动向所述虚拟房间中的客户端推送的,在所述虚拟房间中的客户端数量满足第二条件的情况下,所述消息是所述服务器在接收到来自所述客户端的消息拉取请求后,发送给所述客户端的;
基于所述消息,更新显示所述用户界面。
14.根据权利要求13所述的方法,其特征在于,所述方法还包括:
在所述虚拟房间中的客户端数量满足所述第二条件的情况下,按照设定时间间隔向所述服务器发送所述消息拉取请求。
15.根据权利要求13所述的方法,其特征在于,所述接收所述虚拟房间对应的消息之后,还包括:
响应于所述消息的版本号不连续,向所述服务器发送丢失消息拉取请求;其中,所述丢失消息拉取请求中包括丢失的版本号,所述版本号是所述服务器采用自增的方式生成的;
获取来自所述服务器的丢失消息,所述丢失消息是指所述丢失的版本号对应的消息。
16.一种消息发送装置,其特征在于,所述装置包括:
消息获取模块,用于获取虚拟房间对应的待下发的消息;
消息存储模块,用于将所述消息存储至分布式缓存中;
消息发送模块,用于在所述虚拟房间中的客户端数量满足第一条件的情况下,采用第一下发方式发送所述消息;其中,所述第一下发方式是指服务器主动向所述虚拟房间中的客户端推送所述消息的下发方式;
所述消息发送模块,还用于在所述虚拟房间中的客户端数量满足第二条件的情况下,采用第二下发方式发送所述消息;其中,所述第二下发方式是指所述服务器在接收到来自所述客户端的消息拉取请求后,将所述消息发送给所述客户端的下发方式。
17.一种消息接收装置,其特征在于,所述装置包括:
界面显示模块,用于显示虚拟房间的用户界面;
消息接收模块,用于接收所述虚拟房间对应的消息;其中,在所述虚拟房间中的客户端数量满足第一条件的情况下,所述消息是服务器主动向所述虚拟房间中的客户端推送的,在所述虚拟房间中的客户端数量满足第二条件的情况下,所述消息是所述服务器在接收到来自所述客户端的消息拉取请求后,发送给所述客户端的;
界面更新模块,用于基于所述消息,更新显示所述用户界面。
18.一种计算机设备,其特征在于,所述计算机设备包括处理器和存储器,所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至12任一项所述的消息发送方法,或如权利要求13至15任一项所述的消息接收方法。
19.一种计算机可读存储介质,其特征在于,所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如权利要求1至12任一项所述的消息发送方法,或如权利要求13至15任一项所述的消息接收方法。
20.一种计算机程序产品或计算机程序,其特征在于,所述计算机程序产品或计算机程序包括计算机指令,所述计算机指令存储在计算机可读存储介质中,处理器从所述计算机可读存储介质读取并执行所述计算机指令,以实现如权利要求1至12任一项所述的消息发送方法,或如权利要求13至15任一项所述的消息接收方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111142612.0A CN115878304A (zh) | 2021-09-28 | 2021-09-28 | 消息发送方法、接收方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111142612.0A CN115878304A (zh) | 2021-09-28 | 2021-09-28 | 消息发送方法、接收方法、装置、设备及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115878304A true CN115878304A (zh) | 2023-03-31 |
Family
ID=85763396
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111142612.0A Pending CN115878304A (zh) | 2021-09-28 | 2021-09-28 | 消息发送方法、接收方法、装置、设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115878304A (zh) |
-
2021
- 2021-09-28 CN CN202111142612.0A patent/CN115878304A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10891177B2 (en) | Message management method and device, and storage medium | |
CN111555893B (zh) | 消息数据传输方法、装置、计算机设备和存储介质 | |
WO2021057086A1 (zh) | 通信交互方法、装置及电子设备 | |
US11736749B2 (en) | Interactive service processing method and system, device, and storage medium | |
US8990325B2 (en) | Real-time and interactive community-based content publishing system | |
CN105933213B (zh) | 一种聊天消息的处理方法、相关设备和系统 | |
US9621958B2 (en) | Deferred, on-demand loading of user presence within a real-time collaborative service | |
CN115408604A (zh) | 用于递送实时消息的消息传递平台 | |
JP2014523568A (ja) | 効率的な状態調整 | |
CN106533932B (zh) | 一种用于推送即时消息的方法和装置 | |
CN108540515B (zh) | 一种数据处理方法及服务器 | |
CN112118315A (zh) | 数据处理系统、方法、装置、电子设备和存储介质 | |
CN111314433B (zh) | 消息传输方法、装置及电子设备 | |
CN103139051A (zh) | 一种基于Websocket协议的即时通讯方法 | |
US20230208897A1 (en) | Custom content insertion for user groups | |
JP2022003510A (ja) | ライブ配信メッセージ伝送方法及び装置、電子機器、記憶媒体並びにコンピュータプログラム | |
CN111541555A (zh) | 群聊优化方法及相关产品 | |
CN111130986A (zh) | 消息发送方法、装置、设备及存储介质 | |
CN106411713B (zh) | 一种状态通知方法及服务器 | |
CN105323537A (zh) | 使用移动平台的视频会议 | |
CN115878304A (zh) | 消息发送方法、接收方法、装置、设备及存储介质 | |
CN116308671A (zh) | 基于mqtt协议的在线竞价方法、电子设备及存储介质 | |
KR102527601B1 (ko) | 서버 및 사용자 단말에서의 구독 채널 참조 기반의 주제별 메시지 채팅 방법 | |
CN114679602A (zh) | 一种数据处理方法、装置、电子设备及存储介质 | |
CN117014422A (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 | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40083836 Country of ref document: HK |