消息处理方法及装置
技术领域
本申请涉及通信技术领域,尤其涉及消息处理方法及装置。
背景技术
网络直播技术是一种服务端将主播用户的直播视频数据广播至多个观众用户进行观看的互联网技术。相关技术中,直播服务商提供了很多供观众用户与主播用户进行互动的功能。例如,提供有评论功能,观众用户可以在直播过程中输入评论;也有送礼功能,观众用户可以在直播过程中向主播用户赠送虚拟礼物;还有应援游戏功能,观众用户可以在直播过程中参与游戏并对主播用户进行应援等。观众用户在进行上述互动功能时,服务端接收到观众用户所发起的互动信息,若参与互动的用户非常多,服务端会接收到很多客户端所发送的互动消息。
发明内容
为克服相关技术中存在的问题,本申请提供了消息处理方法及装置。
根据本申请实施例的第一方面,提供一种消息处理方法,所述方法包括:
服务端确定预设时间内各客户端所发送的互动消息的消息数量,并确定数量信息广播给各客户端,所述互动消息为需由服务端广播给各客户端,由客户端在直播界面中进行展示的消息,所述数量信息指示所述消息数量和预设的最大上报数量的大小关系;
客户端接收所述数量信息,并在获取到待发送给服务端的互动消息时,若所述数量信息指示所述消息数量大于所述最大上报数量,则根据预设策略确定所述互动消息是否发送给所述服务端,以控制向所述服务端所发送的互动消息的数量。
可选的,所述服务端确定预设时间内各客户端所发送的互动消息的消息数量,包括:所述服务端实时统计各客户端所发送的互动消息的消息数量。
可选的,所述方法还包括:
若所述数量信息指示所述消息数量不大于所述最大上报数量,则确定所述互动消息发送给所述服务端。
可选的,所述预设策略用于控制所述互动消息随机发送给所述服务端的概率为所述最大上报数量与所述消息数量的比值。
可选的,所述根据预设策略确定所述互动消息是否发送给所述服务端,包括:
利用随机算法产生0至X之间的随机数,并将所述随机数与相对参数进行比较,所述相对参数为max为所述最大上报数量,num为所述消息数量,X为预设正数;
若所述随机数不大于所述相对参数,则确定所述第一消息发送给服务端;
若所述随机数大于所述相对参数,则确定所述第一消息不发送给服务端。
根据本申请实施例的第二方面,提供一种消息处理方法,所述方法包括:
获取服务端发送的数量信息,所述数量信息指示消息数量和预设的最大上报数量的大小关系,所述消息数量为服务端获取的预设时间各客户端所发送的互动消息的数量;
获取待发送给服务端的互动消息,所述互动消息为需由服务端广播给其他客户端,由各其他客户端在直播界面中进行展示的消息;
若所述数量信息指示所述消息数量大于所述最大上报数量,则根据预设策略确定所述互动消息是否发送给所述服务端,以控制向所述服务端所发送的互动消息的数量。
可选的,所述方法还包括:
若所述数量信息指示所述消息数量不大于所述最大上报数量,则确定所述互动消息发送给所述服务端。
可选的,所述预设策略用于控制所述互动消息随机发送给所述服务端的概率为所述最大上报数量与所述消息数量的比值。
可选的,所述根据预设策略确定所述互动消息是否发送给所述服务端,包括:
利用随机算法产生0至X之间的随机数,并将所述随机数与相对参数进行比较,所述相对参数为max为所述最大上报数量,num为所述消息数量,X为预设正数;
若所述随机数不大于所述相对参数,则确定所述第一消息发送给服务端;
若所述随机数大于所述相对参数,则确定所述第一消息不发送给服务端。
根据本申请实施例的第三方面,提供一种消息处理装置,所述装置包括:
第一获取模块,用于获取服务端发送的数量信息,所述数量信息指示消息数量和预设的最大上报数量的大小关系,所述消息数量为服务端获取的预设时间各客户端所发送的互动消息的数量;
第二获取模块,用于获取待发送给服务端的互动消息;
确定模块,用于在所述数量信息指示所述消息数量大于所述最大上报数量时,根据预设策略确定所述互动消息是否发送给所述服务端,以控制向所述服务端所发送的互动消息的数量。
可选的,所述预设策略用于控制所述互动消息随机发送给所述服务端的概率为所述最大上报数量与所述消息数量的比值。
可选的,所述确定模块,还用于:
利用随机算法产生0至X之间的随机数,并将所述随机数与相对参数进行比较,所述相对参数为max为所述最大上报数量,num为所述消息数量,X为预设正数;
若所述随机数不大于所述相对参数,则确定所述第一消息发送给服务端;
若所述随机数大于所述相对参数,则确定所述第一消息不发送给服务端。
本申请的实施例提供的技术方案可以包括以下有益效果:
本申请实施例中,服务端可以统计预设时间内的消息数量,并确定数量信息,向各客户端广播数量信息,所述数量信息指示所述消息数量和预设的最大上报数量,客户端在获取待发送给服务端的互动消息时,可以在所述数量信息的指示下,若消息数量大于最大上报数量,则根据预设策略确定所述互动消息是否发送给所述服务端,以控制客户端所发送的互动消息的数量,减少对服务端的并发请求,并降低互动消息对直播界面展示效果的影响。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。
图1A是本申请根据一示例性实施例示出的一种消息处理的应用场景示意图。
图1B是相关技术中客户端所展示的一种直播界面的示意图。
图2是本申请根据一示例性实施例示出的一种消息处理方法的流程图。
图3是本申请根据一示例性实施例示出的另一种消息处理的应用场景示意图。
图4是根据一示例性实施例示出的另一种消息处理方法的流程图。
图5是本申请根据一示例性实施例示出的一种消息处理装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
本申请实施例的方案,可以应用于网络直播等涉及客户端向服务端发送消息的场景中,以直播场景为例,如图1A所示,是本申请根据一示例性实施例示出的一种消息处理的应用场景示意图,图1A中包括作为服务端设备的服务器、以及作为客户端设备的智能手机、平板电脑和个人计算机。其中,客户端设备还可以是PDA(Personal Digital Assistant,个人数字助理)、多媒体播放器、可穿戴设备等智能设备。
图1A中的服务端向各客户端提供直播服务,用户可以使用智能设备安装直播客户端,通过该直播客户端获得服务端所提供的直播服务,也可以使用智能设备安装浏览器客户端,通过浏览器客户端登录服务器所提供的直播页面,获得直播服务。通常,直播过程中涉及两类用户,一类用户为主播用户,另一类用户为观众用户。客户端提供有主播直播功能和直播收看功能,主播用户可以使用客户端提供的直播功能进行视频直播,具体的实现过程是客户端开启智能设备的视频拍摄模块,通过视频拍摄模块实时采集视频数据,并发送给服务端,服务端将所接收的视频数据广播给各观众用户的客户端,而观众用户可以使用客户端提供的收看功能观看主播用户的直播内容。
相关技术中,直播服务商提供了很多供观众用户与主播用户进行互动的功能。例如提供有评论功能,观众用户可以在直播过程中输入评论;还有送礼功能,观众用户可以在直播过程中向主播用户赠送虚拟礼物;还有应援游戏功能,应援表示援助、支持,通过应援游戏功能,观众用户可以在直播过程中参与应援游戏,以游戏的方式表示对主播用户的支持。观众用户在进行上述互动功能时,服务端可以接收到观众用户利用客户端所发起的互动信息,如图1B所示,是相关技术中客户端所展示的一种直播界面的示意图,服务端会将互动信息广播给其他客户端,以使各其他客户端展示在直播界面中。当参与互动的用户非常多,服务端会接收到大量的信息,对服务端的带宽要求或处理能力等都有较高要求,单一直播间大并发的请求甚至会造成服务器拥塞。另外,由于直播界面中需要展示互动信息,当直播界面所展示的互动信息较多时,也会造成直播界面展示效果较差的问题。
而本申请实施例所提供的方案,服务端可以统计预设时间内的消息数量,根据消息数量确定数量信息,并向各客户端广播数量信息,所述数量信息指示所述消息数量和预设的最大上报数量,客户端在获取待发送给服务端的互动消息时,可以在所述数量信息的指示下,若消息数量大于最大上报数量,则根据预设策略确定所述互动消息是否发送给所述服务端,以控制客户端所发送的互动消息的数量,减少对服务端的并发请求,并降低互动消息对直播界面展示效果的影响。接下来对本申请所提供的方案进行详细说明。
如图2所示,图2是本申请根据一示例性实施例示出的一种消息处理方法的流程图,包括以下步骤201至202:
201、服务端确定预设时间内各客户端所发送的互动消息的消息数量,并确定数量信息广播给各客户端,所述互动消息为需由服务端广播给各客户端,由客户端在直播界面中进行展示的消息,所述数量信息指示所述消息数量和预设的最大上报数量的大小关系。
202、客户端接收所述数量信息,并在获取到待发送给服务端的互动消息时,若所述数量信息指示所述消息数量大于所述最大上报数量,则根据预设策略确定所述互动消息是否发送给所述服务端,以控制向所述服务端所发送的互动消息的数量。
本申请实施例中,对于直播场景,观众用户会通过客户端向服务端发送互动消息,服务端会将所接收的互动消息展示在直播界面中,消息的展示时间可以是预设的几秒时间,或者是根据单位时间内所接收的互动消息的数量而确定展示时间,互动消息越多,则展示时间越短。在直播过程中,服务端会持续接收到各客户端的互动消息,并持续广播给各客户端,使各客户端在直播界面中进行展示。在参与直播的观众用户很多,且所上报的消息非常多的情况下,若所有互动消息都展示在直播界面中,则会导致直播界面中展示太多的互动消息,造成主播用户的直播内容被遮挡等直播效果较差的问题,同时也会造成服务端拥塞的问题。
因此,实施本申请方案的服务端操作人员可以预先设定最大上报数量,该最大上报数量可以根据多种因素确定,例如可以根据服务端的带宽要求或处理能力进行确定,或者是以达到较优的直播界面的展示效果为目的进行确定,例如,通过历史数据分析出直播界面中每秒最多同时展示200条消息,若展示更多消息则直播界面的展示效果很差,因此可以确定该最大上报数量为200条。在实际应用中可根据需求灵活配置,具体的数值和确定方式本实施例不作限定。
服务端可以通过多种方式确定预设时间内各客户端所发送的互动消息的消息数量,例如可以是根据直播过程中的用户数量而确定,或者是通过统计客户端所发送的互动消息的消息数量而确定,或者还可以是结合历史互动消息的数量而确定。其中,预设时间可以是1秒、1分钟或5分钟等时间,在实际应用中,为了提高消息处理的准确性,服务端可以是实时统计各客户端所发送的互动消息的消息数量,还可以实时广播数量信息给各客户端。
服务端在确定消息数量,并获取最大上报数量后,可以确定用于指示所述消息数量和最大上报数量的大小关系的数量信息,并广播给各客户端。其中,数量信息可以包括消息数量和最大上报数量的数值本身,也可以是两者的比值、百分比等其他形式的信息。
本申请的待发送给服务端的互动消息可以是指在直播场景中,任何由客户端产生并需要由服务端广播给其他客户端,由各其他客户端在直播界面中展示的消息。在设定了最大上报数量的情况下,若所述数量信息指示所述消息数量不大于所述最大上报数量,表示服务端有能力处理当前的消息数量,当前的消息数量不影响直播界面的展示效果,可以确定所述互动消息发送给所述服务端。若消息数量大于最大上报数量,则表示当前的互动消息的数量不在服务端的处理能力以内,当前的互动消息的数量将影响直播界面的展示效果,因此可以控制互动消息的数量。
本实施例中,由客户端进行互动消息的控制,客户端可以根据预设策略确定所述互动消息是否发送给所述服务端,使得所获取的某些互动消息不发送给服务端,以达到减少互动消息的数量的目的。在实际应用中,该预设策略可以灵活配置,例如可以是客户端每隔5秒发送一条互动消息,即在发送一条互动消息后,间隔的5秒时间内所获取的互动消息则不进行发送;也可以是利用某些随机算法确定该互动消息是否发送给服务端;还可以是客户端根据用户的等级等用户信息进行确定等等。由于本实施例中,客户端在根据用户请求产生了互动消息后,客户端不一定都将互动消息发送给服务端,而是通过一定策略限制某些互动消息不进行发送,因此能减少服务端所接收到的互动消息的数量,减少对服务端的并发请求。
其中,在确定互动消息不进行发送的情况下,该互动消息不会发送给服务器并通过服务端广播给其他客户端,即其他观众用户不会在直播界面中查阅到该消息,但本客户端可以将该互动消息展示在本端的直播界面中,使得本客户端的观众用户可以查阅到其所发起的互动消息。
为了防止客户端限制较多的互动消息,使服务端接收到的互动消息数量可以控制在最大上报数量,所述预设策略用于控制所述互动消息随机发送给所述服务端的概率为所述最大上报数量与所述消息数量的比值。在实际应用中,客户端可以通过设置随机算法,以控制互动消息随机发送的概率。利用上述方式,可以限制服务端所接收的互动消息的数量大约在最大上报数量,防止客户端可以将互动消息的数量限制得太多,或者是限制得太少,达不到较好的限制效果。
在一个可选的实现方式中,所述根据预设策略确定所述互动消息是否发送给所述服务端,包括:
利用随机算法产生0至X之间的随机数,并将所述随机数与相对参数进行比较,所述相对参数为max为所述最大上报数量,num为所述消息数量,X为预设正数;
若所述随机数不大于所述相对参数,则确定所述第一消息发送给服务端;
若所述随机数大于所述相对参数,则确定所述第一消息不发送给服务端。
其中,该相对参数可以是前述的数量信息,服务端根据消息数量和最大上报数量计算该相对参数并发送给客户端;若服务端发送给客户端的数量信息为消息数量和最大上报数量的数值本身,则客户端可以根据上述计算公式计算该相对参数。
本实施例中,假设max为100,num为160,X为100,max<num,相对参数为62.5,客户端接收到相对参数,并随机产生0至100之间的随机数,由于客户端有62.5%的概率产生小于或等于相对参数的随机数,有37.5%的概率产生大于相对参数的随机数,因此,通过上述方式,能快速地控制所述互动消息随机发送给所述服务端的概率为所述消息数量与所述最大上报数量的比例。
接下来通过一具体实施例再次说明本申请,如图3所示,是本申请根据一示例性实施例示出的另一种消息处理的应用场景示意图,为了示例方便,图3中只示出一服务器,该服务器用于实现服务端的功能,可以理解,在实际应用中,服务端的功能可以由一台服务器完成,也可以配置多台服务器,由多台服务器所构成的服务器集群完成,例如,可以设置公屏服务器用于对直播数据和互动消息的广播,可以设置互动事件服务器专用于处理互动事件、接收互动信息等。
图3中还包括主播用户所使用的客户端设备以及多个观众用户所使用的客户端设备,主播用户在直播过程中,主播用户所使用的客户端可以将直播内容发送给服务器,服务器将直播内容广播给各观众用户的客户端,观众用户可以利用客户端所展示的直播界面查看直播内容。其中,客户端还提供有互动功能,该功能可以通过在直播界面中提供一可触发互动事件的选项而实现,本实施例该互动事件可具体为一应援事件,观众用户可以通过点选图中所示的“应援开始”选项而触发该互动事件。当该选项被触发时,一方面客户端根据互动事件被触发,生成涉及互动事件开始进行的互动消息并发送给服务端,服务端可以根据所接收到的互动消息统计有多少观众用户发起该互动事件,另一方面,客户端提供该应援事件对应的游戏功能,观众用户可以开始应援游戏,在该应援游戏结束后产生游戏结果,本实施例中该游戏结果具体可以为一图片,客户端将该图片作为涉及互动结果、需在直播界面展示的互动消息发送给服务端,服务端将各客户端所发送的互动消息广播给各客户端,由各客户端展示在直播界面中,以使各观众用户能查阅到其他观众用户对主播用户的应援情况。
服务端的操作人员可以配置最大上报数量max,服务端实时统计每秒参与互动的用户数量num,服务端实时广播数量信息freqNum:freqNum=max/num*100;客户端实时获取该数量信息,并生成0~100的随机数rand。在生成互动消息后,如果rand<=freqNum,则发送给服务端,如果rand>freqNum则不进行发送。
如图4所示,是根据一示例性实施例示出的另一种消息处理方法的流程图,本实施例方法可应用在客户端设备中,包括如下步骤401至403:
401、获取服务端发送的数量信息,所述数量信息指示消息数量和预设的最大上报数量的大小关系,所述消息数量为服务端获取的预设时间各客户端所发送的互动消息的数量。
402、获取待发送给服务端的互动消息,所述互动消息为需由服务端广播给其他客户端,由各其他客户端在直播界面中进行展示的消息。
403、若所述数量信息指示所述消息数量大于所述最大上报数量,则根据预设策略确定所述互动消息是否发送给所述服务端,以控制向所述服务端所发送的互动消息的数量。
本实施例可参考前述图2所示实施例,在此不再赘述。
本申请实施例所提供的方案,可以获取到服务端所发送的数量信息,该数量信息指示所述消息数量和预设的最大上报数量,客户端在获取待发送给服务端的互动消息时,可以在所述数量信息的指示下,若消息数量大于最大上报数量,则根据预设策略确定所述互动消息是否发送给所述服务端,以控制客户端所发送的互动消息的数量,减少对服务端的并发请求,并降低互动消息对直播界面展示效果的影响。
在一个可选的实现方式中,所述方法还可包括:
若所述数量信息指示所述消息数量不大于所述最大上报数量,则确定所述互动消息发送给所述服务端。
在一个可选的实现方式中,所述预设策略用于控制所述互动消息随机发送给所述服务端的概率为所述最大上报数量与所述消息数量的比值。
在一个可选的实现方式中,所述根据预设策略确定所述互动消息是否发送给所述服务端,包括:
利用随机算法产生0至X之间的随机数,并将所述随机数与相对参数进行比较,所述相对参数为max为所述最大上报数量,num为所述消息数量,X为预设正数;
若所述随机数不大于所述相对参数,则确定所述第一消息发送给服务端;
若所述随机数大于所述相对参数,则确定所述第一消息不发送给服务端。
与前述消息处理方法的实施例相对应,本申请还提供了消息处理装置及其所应用的设备的实施例。
如图5所示,图5是本申请根据一示例性实施例示出的一种消息处理装置的框图,所述装置包括:
第一获取模块51,用于获取服务端发送的数量信息,所述数量信息指示消息数量和预设的最大上报数量的大小关系,所述消息数量为服务端获取的预设时间各客户端所发送的互动消息的数量。
第二获取模块52,用于获取待发送给服务端的互动消息,所述互动消息为需由服务端广播给各客户端,由客户端在直播界面中进行展示的消息。
确定模块53,用于在所述数量信息指示所述消息数量大于所述最大上报数量时,根据预设策略确定所述互动消息是否发送给所述服务端,以控制向所述服务端所发送的互动消息的数量。
在一个可选的实现方式中,所述确定模块53,还可用于在所述数量信息指示所述消息数量不大于所述最大上报数量时,确定所述互动消息发送给所述服务端。
在一个可选的实现方式中,所述预设策略用于控制所述互动消息随机发送给所述服务端的概率为所述最大上报数量与所述消息数量的比值。
在一个可选的实现方式中,所述确定模块,还用于:
利用随机算法产生0至X之间的随机数,并将所述随机数与相对参数进行比较,所述相对参数为max为所述最大上报数量,num为所述消息数量,X为预设正数;
若所述随机数不大于所述相对参数,则确定所述第一消息发送给服务端;
若所述随机数大于所述相对参数,则确定所述第一消息不发送给服务端。
上述装置中各个模块的功能和作用的实现过程具体详见上述消息处理方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
本领域技术人员在考虑说明书及实践这里申请的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。