CN108174305B - 直播聊天室的消息处理方法及装置 - Google Patents

直播聊天室的消息处理方法及装置 Download PDF

Info

Publication number
CN108174305B
CN108174305B CN201611116723.3A CN201611116723A CN108174305B CN 108174305 B CN108174305 B CN 108174305B CN 201611116723 A CN201611116723 A CN 201611116723A CN 108174305 B CN108174305 B CN 108174305B
Authority
CN
China
Prior art keywords
message
priority
live streaming
client
chatroom
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
CN201611116723.3A
Other languages
English (en)
Other versions
CN108174305A (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 Cloud In Faith Network Technology Co Ltd
Original Assignee
Beijing Cloud In Faith Network 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 Cloud In Faith Network Technology Co Ltd filed Critical Beijing Cloud In Faith Network Technology Co Ltd
Priority to CN201611116723.3A priority Critical patent/CN108174305B/zh
Publication of CN108174305A publication Critical patent/CN108174305A/zh
Application granted granted Critical
Publication of CN108174305B publication Critical patent/CN108174305B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/478Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4788Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/254Management at additional data server, e.g. shopping server, rights management server

Abstract

本发明公开了一种直播聊天室的消息处理方法及装置,属于计算机技术领域。所述方法包括:按照消息的优先级,将接收到的直播聊天室的消息进行选择性丢弃或保留,使得统计时间段内保留的该直播聊天室的消息的数量在预定范围内,同一统计时间段内在先被丢弃的消息的优先级不高于在后被丢弃的消息的优先级;在需要向客户端发送该直播聊天室的消息时,从保留的且被处理过的该直播聊天室的消息中读取尚未被发送给该客户端的消息,将读取的消息发送给该客户端。本发明在服务器可以直接丢弃直播聊天室的一些优先级较低的消息,从而使得服务器可以避免对高并发量的消息均进行处理,进而避免了高并发量的消息对服务器资源的浪费。

Description

直播聊天室的消息处理方法及装置
技术领域
本发明涉及计算机技术领域,特别涉及一种直播聊天室的消息处理方法及装置。
背景技术
直播聊天室具备消息并发量高的特点,对消息接收的实时性要求比较高。客户端的用户肉眼可看清的消息每秒钟最多100条左右,当聊天室中的消息并发量大,如每秒钟成千上万条甚至更高时,则需要考虑丢弃多余的消息。
相关技术中,在对直播聊天室内的消息进行丢弃时,采用的方式是在客户端丢弃多余的消息。比如客户端在接收消息时,采用消息队列的方式,确保每秒钟只处理100条消息,如消息队列的长度为100,每消费一条消息,等待10毫秒;当消息队列满了,客户端若再接收到服务器推送的消息,则丢弃服务器推送的这些消息。
由于服务器需要对上行消息进行处理之后才能推送给客户端,因此在直播聊天室的上行消息并发量很高时,每秒钟只有100条消息对客户端是有用的,其余的消息则会很大程度上浪费服务器端的资源。
发明内容
为了解决相关技术中对客户端无用的消息很大程度上浪费服务器端的资源的问题,本发明实施例提供了一种直播聊天室的消息处理方法及装置。所述技术方案如下:
第一方面,提供了一种直播聊天室的消息处理方法,所述方法包括:按照消息的优先级,将接收到的直播聊天室的消息进行选择性丢弃或保留,使得统计时间段内保留的所述直播聊天室的消息的数量在预定范围内,同一统计时间段内在先被丢弃的消息的优先级不高于在后被丢弃的消息的优先级;按照预定方式对保留的消息进行处理;在需要向客户端发送所述直播聊天室的消息时,从处理过的所述直播聊天室的消息中读取尚未被发送给所述客户端的消息,将读取的消息发送给所述客户端。
第二方面,提供了一种直播聊天室的消息处理装置,所述装置包括:保留模块,用于按照消息的优先级,将接收到的直播聊天室的消息进行选择性丢弃或保留,使得统计时间段内保留的所述直播聊天室的消息的数量在预定范围内,同一统计时间段内在先被丢弃的消息的优先级不高于在后被丢弃的消息的优先级;处理模块,用于按照预定方式对所述消息保留模块所保留的消息进行处理;读取模块,用于在需要向客户端发送所述直播聊天室的消息时,从所述消息处理模块所处理过的所述直播聊天室的消息中读取尚未被发送给所述客户端的消息;发送模块,用于将所述读取模块读取的消息发送给所述客户端。
本发明实施例提供的技术方案带来的有益效果是:
按照消息的优先级,将直播聊天室的上行消息进行选择性丢弃和保留,使得统计时间段内保留的消息的数量在合理范围内,这些消息被推送给客户端后可以满足肉眼对客户端所展示的消息的查看;由于在服务器可以直接丢弃直播聊天室的一些优先级较低的消息,从而使得服务器可以避免对高并发量的消息均进行处理,进而避免了高并发量的消息对服务器资源的浪费。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1A是本发明部分实施例中提供的直播聊天室的消息处理方法所涉及的实施环境的示意图;
图1B是本发明另一部分实施例中提供的直播聊天室的消息处理方法所涉及的实施环境的示意图;
图2是本发明一个实施例中提供的直播聊天室的消息处理方法的方法流程图;
图3A是本发明另一个实施例中提供的直播聊天室的消息处理方法的方法流程图;
图3B是本发明一个实施例中提供的直播聊天室对应的消息容器的示意图;
图3C是本发明一个实施例中提供的从直播聊天室对应的消息容器读取消息的示意图;
图4是本发明一个实施例中提供的直播聊天室的消息处理装置的结构示意图;
图5是本发明另一个实施例中提供的直播聊天室的消息处理装置的结构示意图;
图6是本发明一个实施例中提供的服务器的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明实施方式作进一步地详细描述。
为了便于对本发明各个实施例的理解,首先对本发明各个实施例中所涉及的名词进行解释说明:
主播:开启直播聊天室的用户,一般来讲,主播的摄像头所拍摄的视频图像被展示在直播聊天室中,其余的用户可以观看聊天室内主播的视频。
直播聊天室:专门为视频直播业务提供主播与观众(即参与直播聊天室的非主播用户)之间消息实时互动的云服务产品,其特点是聊天室中人数无上限,且支持消息海量并发、即时到达。
刷屏:指客户端显示聊天室的消息时,单位时间段内显示的消息条数过高导致消息在屏幕上滚动过快。在刷屏情况下容易因单位时间段内显示的消息数量过多导致用户无法看清。
上行消息:指直播聊天室中用户发送的消息,因为这些消息会被发送给服务器,由服务器转发给该直播聊天室内的其他客户端,因此这些消息相对服务器可以称为上行消息。
白名单消息:聊天室中白名单用户所发送的消息。这里所讲的白名单用户通常为发送重要消息的用户,如主播或发送触发系统行为消息的用户。
服务(英文:Server)应用程序编程接口(英文:Application ProgrammingInterface,简称:API)消息:从客户(使用直播聊天室客户端的单位或个人)服务器端向聊天室服务器端发送的消息,通常用于触发系统行为,例如把某个用户禁言、销毁聊天室等Server API消息。Server API消息区别于从客户端向聊天室服务器端发送的聊天消息,聊天消息一般是客户端的用户主发意识输入的消息,比如聊天消息、送给直播聊天室主播的虚拟礼物、点赞等。
为了方便理解,下面对本发明的整体构思进行说明。
在实际应用中,直播聊天室由于不限定参与人数,因此在同一时间段内可能会有大量的用户在直播聊天室发送消息,此时,这些消息均会被发送给直播聊天室所对应的服务器,由服务器对这些消息进行文本识别、敏感词过滤等处理。由于直播聊天室内的高并发性,会导致服务器在短时间内处理大量的消息,然后将处理后的消息推送至正开启该直播聊天室的客户端,客户端在短时间内需要显示大量的消息,从而导致直播聊天室的刷屏现象。为了保证用户可以肉眼查看清楚客户端所展示的消息,客户端仅会在单位时间段内保证显示预定条消息,比如在1s内保证显示100条左右的消息,因此客户端会丢掉服务器发送的其余大量的消息。这样会导致客户端原本不需要显示的消息也会大量占用服务器的处理资源。
因此,在本发明实施例中,在服务器侧预先选择性丢弃一些优先级比较低的消息,保证单位时间段内保留的消息数量在合理范围内,这样服务器仅需要对这些保留的消息进行处理,并将处理后的消息推送给客户端,从而避免了大量的对客户端无用的消息对服务器的资源占用,又可以保证这些消息被推送给客户端后可以满足肉眼对客户端所展示的消息的查看。
以下结合图1A、图1B所示的实施环境以及图2和图3A对直播聊天室中消息处理方法的实现进行说明。
图1A是本发明部分实施例中提供的直播聊天室的消息处理方法所涉及的实施环境的示意图,该实施环境可以包括服务器110和至少一个客户端120。
服务器110是提供直播聊天室业务的服务器计算机系统。服务器110通常是多台服务器的集群,每台服务器用于实现一个或一个以上的功能模块。服务器110还可以是提供直播聊天室业务的后台服务器系统的集群。其中,提供直播聊天室业务的后台服务器系统可以是微博客户端的后台服务器系统、即时聊天程序的后台服务器系统、视频聊天程序的后台服务器系统或社交类应用的后台服务器系统等等。
客户端120是由服务器110提供的具备视频直播聊天室功能的应用程序(英文简称:APP)。客户端120可以是直播聊天室客户端、微博客户端、博客客户端、社交类应用客户端或其他应用类客户端。客户端120可以向服务器110请求注册并开启一个直播聊天室。客户端120通常需要运行在用户所使用的移动终端上,这里的移动终端可以是智能手机、平板电脑、电子阅读器等。
客户端120通过有线网络或无线网络与服务器110相连。
可选的,服务器110在分配一个直播聊天室之后,可以在服务平台上进行该直播聊天室的展示,其余客户端120可以进入该直播聊天室。参与直播聊天室的各个客户端所发表的消息均会发送给服务器110,由服务器110对这些消息进行处理,并将处理后的消息推送给该直播聊天室的各个客户端120。
在直播聊天室开启后,通常会有较多的客户端120参与开启的直播聊天室。
可选的,在服务器110后台可以布局多个服务器,也即服务器110是多个服务器集群时,为了便于对同一个直播聊天室的消息的处理,可以将该直播聊天室相关的上行消息均推送至同一台服务器节点上。举例来讲,直播聊天室的上行消息均携带有聊天室标识,对聊天室标识取模运算,将消息推送至运算得到的数值所对应的服务器节点上。请参见图1B所示,服务器110包括服务器110a、服务器110b和服务器110c,通过取模运算,可以将开启同一个直播聊天室的各个客户端120发送的该直播聊天室的消息推送至服务器110b节点上。
图2是本发明一个实施例中提供的直播聊天室的消息处理方法的方法流程图,该直播聊天室的消息处理方法可以应用于图1A所示实施环境中的服务器110或图1B所示实施环境中的服务器110b中。该直播聊天室的消息处理方法包括如下步骤:
步骤201,按照消息的优先级,将接收到的直播聊天室的消息进行选择性丢弃或保留。
在实际应用中,参与某直播聊天室的客户端会产生一些消息,比如用户输入的消息或系统消息,这些消息均会被客户端发送给服务器,由服务器处理后推送给参与该直播聊天室的各个客户端,这样参与直播聊天室的各个客户端均可以查看到参与该直播聊天室的其他客户端所产生的消息。因此,这里所讲的直播聊天室的消息是客户端发送给服务器的,这些发送给服务器的直播聊天室的消息相对于服务器来讲为上行消息。
由于参与直播聊天室的用户有主播用户以及普通用户(即非主播用户),在直播聊天室发送的消息有主播用户发送的语音数据、其他普通用户输入的文本消息、语音消息、送礼物时产生的礼物消息、点赞消息以及各用户触发直播聊天室中的某些功能所产生的系统消息等,这些消息中主播用户产生的消息以及普通用户发送的礼物消息均比较重要,而普通用户产生的点赞消息等则相对来讲不太重要,因此直播聊天室的消息可以被设置为不同的优先级。
一般来讲,直播聊天室的主播用户所发送的消息以及系统消息均比较重要,通常可以将主播用户发送的消息以及系统消息设置为白名单消息,即作为最高优先级的消息。显然,主播用户也可以指定若干个白名单用户,这些被指定的白名单用户所发送的消息也为最高优先级的消息。一种可能的实现方式中,服务器接收主播用户所登录客户端发送的白名单通知,白名单通知中携带有被指定为白名单的用户,服务器将这些被指定为白名单的用户以及主播用户作为该直播聊天室的白名单用户。
参与直播聊天室的其他普通用户所发送的聊天消息以及送礼物的消息可以作为高优先级的消息,而点赞之类的消息则可以作为低优先级的消息。
显然,在实际应用中,消息还可以被划分为更多不同的优先级,也即服务器设置的消息的优先级的判定规则还可以包括:将点赞之类的消息的优先级设置为第一优先级,将非主播用户发送的聊天消息的优先级设置为第二优先级,将送礼物的消息的优先级设置为第三优先级,将白名单消息的优先级设置为第四优先级等,其中第一优先级低于第二优先级,第二优先级低于第三优先级,第三优先级低于第四优先级。
以上消息的优先级的判定规则仅是示例性举例,并不用于限定本发明各实施例的保护范围。
参与直播聊天室的客户端所发送的消息均包含直播聊天室的标识,以用于区分来自哪个直播聊天室,当服务器接收到直播聊天室的一条消息时,则可以根据预先设置的该直播聊天室对应的优先级判定规则,确定该接收到的消息的优先级。
服务器在对直播聊天室的上行消息进行选择性丢弃或保留时,需要使得统计时间段内保留的该直播聊天室的上行消息的数量在预定范围内。一般来讲,高优先级的消息更优于低优先级的消息,服务器可以优先考虑丢弃优先级较低的消息,而如果高优先级也过多时,则还需要丢弃高优先级的消息,因此同一统计时间段内在先被丢弃的消息的优先级不高于在后被丢弃的消息的优先级。
步骤202,按照预定方式对保留的消息进行处理。
服务器在将上行消息下发给直播聊天室的各客户端之前,需要按照预定方式对上行消息进行处理。比如,当消息是语音消息时,需要将语音消息转换成文本格式的消息;还比如,对消息进行敏感词过滤;还比如,对消息进行加密处理等。
上述对消息处理的过程一般会消耗服务器较多的资源,而当经过步骤201选择性地保留部分消息时,服务器仅需要对保留的消息进行上述处理,在消息并发量高的情况下,被丢弃的消息均不再占用服务器的资源,因此极大地减少了对服务器资源的消耗。
步骤203,在需要向客户端发送直播聊天室的消息时,从处理过的该直播聊天室的消息中读取尚未被发送给该客户端的消息,将读取的消息发送给该客户端。
在一种场景中,客户端每隔预定时间间隔会向服务器发送与指定的直播聊天室相关的消息拉取请求,服务器在接收到客户端发送的消息拉取请求后,会将该直播聊天室的尚未被推送给客户端的消息推送给该客户端。
在实际应用中,由于服务器需要为参与聊天室的不同客户端服务,而这些客户端的消息展示并不完全同步,因此,服务器会保留该直播聊天室的各条消息,以推送给参与该直播聊天室的各个客户端。为了避免消息的重复推送以及消息的遗漏推送,服务器需要从处理过的该直播聊天室的消息中读取尚未被发送给该客户端的消息,并将读取的消息推送给该客户端。
综上所述,本发明实施例中提供的直播聊天室的消息处理方法,按照消息的优先级,将直播聊天室的上行消息进行选择性丢弃和保留,使得统计时间段内保留的消息的数量在合理范围内,这些消息被推送给客户端后可以满足肉眼对客户端所展示的消息的查看;由于在服务器可以直接丢弃直播聊天室的一些优先级较低的消息,从而避免了服务器侧对高并发量的消息均进行处理,进而避免了高并发量的消息对服务器端资源的浪费。
在实际应用中,服务器一般会优先考虑丢弃优先级较低的消息,而如果高优先级的消息也比较多时,也会考虑丢弃高优先级的消息,但白名单消息一般会被保留,具体可以参见图3A所示的实现。
图3A是本发明另一个实施例中提供的直播聊天室的消息处理方法的方法流程图,该直播聊天室的消息处理方法可以应用于图1A所示实施环境中的服务器110或图1B所示实施环境中的服务器110b中。该直播聊天室的消息处理方法包括如下步骤:
步骤301,在每次接收到直播聊天室的一条消息时,获取该消息的优先级。
参与直播聊天室的客户端在向服务器发送一条消息之后,服务器可以接收到该消息,并获取该消息的优先级。
在实际应用中,服务器可以设置并存储有消息的优先级的判定规则,按照判定规则获取接收到的消息的优先级。
举例来讲,判定规则为:当消息为白名单消息时,判定该消息为最高优先级;当消息为普通用户发送的消息时,判定该消息为高优先级;当消息为点赞消息时,判定该消息为低优先级。
服务器在获取到消息的优先级之后,可以按照该消息的优先级,将接收到的该消息进行选择性丢弃或保留,使得统计时间段内保留的该直播聊天室的消息的数量在预定范围内,同一时间段内在先被丢弃的消息的优先级不高于在后被丢弃的消息的优先级,具体可以参见步骤302至步骤304的实现。
步骤302,根据当前统计时间段内已保留的该直播聊天室的消息的数量,确定该数量对应的当前需要丢弃的消息的优先级。
在每个统计时间段内,服务器会实时记录当前统计时间段内已保留的该直播聊天室的消息的数量。当前统计时间段已保留的该直播聊天室的消息的数量可以决定后续需要丢弃的消息的优先级。
在一种实现方式中,当前统计时间段内已保留的该直播聊天室的消息的数量与数量对应的需要丢弃的消息的优先级呈正相关关系。正相关关系是指两个变量的变化方向相同,即一个变量增大时,对应的另一个变量也增大;一个变量减小时,对应的另一个变量也减小,两者呈线性相关或非线性相关。比如,当前统计时间段内已保留的该直播聊天室的消息的数量越少,对应的需要丢弃的消息的优先级越低,当前统计时间段内已保留的该直播聊天室的消息的数量越高,对应的需要丢弃的消息的优先级越高。
在另一种实现方式中,当前统计时间段内已保留的该直播聊天室的消息的第一数量小于第二数量时,第一数量对应的需要丢弃的消息的优先级等于或低于第二数量对应的需要丢弃的消息的优先级。
一般来讲,当前统计时间段已保留的该直播聊天室的消息的数量较少时,可能意味着直播聊天室当前统计时间段并发的消息比较少,为了保证消息的完整性,可以不丢弃消息。而随着当前统计时间段保留的该直播聊天室的消息的数量的增多,表明直播聊天室当前统计时间段内并发的消息也较多,此时则可以选择丢弃较低优先级的消息。而若当前统计时间段已保留的该直播聊天室的消息的数量继续逐渐增多,则表明直播聊天室当前统计时间段内并发的消息过多,此时除了丢弃较低优先级的消息,也可以考虑丢弃较高优先级的消息。
在实际实现时,考虑到客户端在单位时间段(一般为1s)所展示的消息数量(1s展示的消息数量在100条左右)需要符合用户的肉眼查看,因此需要使得单位时间段内保留的该直播聊天室的消息数量在一个合理的范围,比如100-200条左右。
而在一种应用场景中,一个直播聊天室中每秒钟有一万条上行消息,在利用消息丢弃策略对直播聊天室的消息进行选择性丢地或保留时,每秒钟只允许保留前100条消息,那么,一秒钟内只有最初的1%的时间是有消息的,而在这一秒内99%时间是没有消息的。这样客户端会有卡顿现象,用户体验不好。因此这里考虑将单位时间段划分成若干个统计时间段,针对每个统计时间段执行消息丢弃策略,使得同一个单位时间段内各个统计时间段保留的消息数量总和在一个合理的范围。
在一种实现中,每个单位时间段包括a个统计时间段,每个单位时间段需要向同一个客户端发送的消息的数量为n个,服务器在根据当前统计时间段内已保留的该直播聊天室的消息的数量,确定该数量对应的当前需要丢弃的消息的优先级时,可以包括如下步骤:
第一,在当前统计时间内已经保留的该直播聊天室的消息的数量小于n/a时,确定该当前需要丢弃的消息的优先级为空。
当前需要丢弃的消息的优先级为空,表明不对消息进行丢弃。
以单位时间段为1秒,统计时间段为200ms,1秒钟适合用户查看的消息数量为100为例,这样n为100,a为5,则服务器在当前统计时间段200ms内已经保留的该直播聊天室的消息的数量小于20(即100/5=20)条时,确定该当前需要丢弃的消息的优先级为空。也就是说,当前统计时间段200ms内已经保留的该直播聊天室的消息的数量小于20条时,则保留接收到该直播聊天室的消息。
第二,在当前统计时间内已经保留的消息的数量大于n/a且小于2n/a时,将第一优先级确定为当前需要丢弃的消息的优先级。
仍旧以n为100,a为5为例,在当前统计时间段200ms内已经保留的消息的数量大于20(即100/5=20)条且小于40(即2*100/50=40)条时,将第一优先级确定为当前需要丢弃的消息的优先级。这里的第一优先级为最低优先级,也就是说,若当前统计时间段200ms内已经保留的消息数量大20条且小于40条时,则可以将最低优先级的消息进行丢弃。
第三,在当前统计时间内已经保留的消息的数量大于2n/a时,将第一优先级和第二优先级确定为当前需要丢弃的消息的优先级,第一优先级低于第二优先级。
可选的,在当前统计时间内已经保留的消息的数量大于2n/a时,将第一优先级和第二优先级确定为当前需要丢弃的消息的优先级,保留具备第三优先级的消息,其中,第一优先级低于第二优先级,第二优先级低于第三优先级。
仍旧以n为100,a为5为例,在当前统计时间段200ms内已经保留的消息的数量大于40(即2*100/50=40)条时,将第二优先级确定为当前需要丢弃的消息的优先级。这里的第一优先级为最低优先级,第二优先级为高于第一优先级的一个优先级。也就是说,若当前统计时间段200ms内已经保留的消息数量大于40条时,则可以将比最低优先级高一优先级的消息进行丢弃。
举例来讲,若服务器设置的优先级包括最高优先级(比如白名单消息对应的优先级)、高优先级(比如普通用户的消息和礼物消息所对应的优先级)和最低优先级(比如点赞消息),则第一优先级为最低优先级,第二优先级为高优先级,第三优先级为最高优先级。
步骤303,当获取的消息的优先级属于当前需要丢弃的消息的优先级时,则丢弃该消息。
当获取的消息的优先级属于当前需要丢弃的消息的优先级时,则丢弃该消息。仍旧以n为100,a为5为例,当在当前统计时间段200ms内已经保留的消息的数量大于20条且小于40条,且当前获取的消息的优先级为第一优先级,而判定的需要丢弃的消息的优先级为第一优先级,此时则丢弃该获取的消息。
步骤304,当获取的消息的优先级不属于当前需要丢弃的消息的优先级,则保留该消息。
当获取的消息的优先级属于当前需要丢弃的消息的优先级时,则丢弃该消息。仍旧以n为100,a为5为例,当在当前统计时间段200ms内已经保留的消息的数量大于20条且小于40条,且当前获取的消息的优先级为第二优先级,而判定的需要丢弃的消息的优先级为第一优先级,此时则保留该获取的消息。
由上述步骤可知,以单位时间段为1s,统计时间段为200ms为例,在并发量很高的情况下,单位时间段可以保留的消息大约为200条,这200条左右的消息中最多100条为第一优先级的消息,最少100条为第二优先级的消息,且由于白名单消息不会被丢弃,因此还可能保留若干个白名单消息。也就是说,经过步骤302的实现,在直播聊天室高并发消息的情况下,可以保证约100条较高优先级的消息被保留,而这些较高优先级的消息最可能是客户端需要展示的消息。
为了能够向客户端单位时间段内推送大约100条左右的消息,服务器会尽量将单位时间段内保留的消息中优先级较高的消息推送给客户端,针对这种情况,本实施例中在服务器设置用于承载不同优先级的消息容器。
步骤305,对保留的消息进行处理,将处理过的消息存储至与消息的优先级对应的消息容器中。
服务器在保留了某直播聊天室的消息之后,需要按照预定方式对保留的消息进行处理。比如,当消息是语音消息时,需要将语音消息转换成文本格式的消息;还比如,对消息进行敏感词过滤;还比如,对消息进行加密处理等。
上述对消息处理的过程一般会消耗服务器较多的资源,而当经过步骤301至步骤304选择性地保留部分消息时,服务器仅需要对保留的消息进行上述处理,在消息并发量高的情况下,被丢弃的消息均不再占用服务器的资源,因此极大地减少了对服务器资源的消耗。
服务器在将保留的消息进行处理之后,可以将处理过的消息存储至与消息的优先级对应的消息容器中。
一般来讲,针对一个直播聊天室的消息的不同优先级,服务器针对该直播聊天室设置不同的消息容器,且不同的聊天室对应不同的消息容器。
以服务器设置第一优先级(比如最低优先级)、第二优先级(比如高优先级)和第三优先级(比如最高优先级、白名单消息所具备的优先级)为例,服务器中可以设置有对应于第一优先级的第一消息容器、对应于第二优先级的第二消息容器以及对应于第三优先级的第三消息容器。
通常,每条消息均有生成时刻,消息的生成时刻也即该消息在客户端生成的时刻,或者是客户端获取用户输入的消息的时刻,客户端在向服务器发送该消息时,通常会携带该消息的生成时刻。对于直播聊天室对应的每个消息容器,均以队列的形式按照消息的生成时刻依次存储。比如对于第一优先级的消息若干条,按照这些消息的生成时刻从早到晚依次存储至与第一优先级对应的消息容器中,其中生成时刻在后的消息存储在生成时刻在前的消息的后面,生成时刻在后的消息相对于生成时刻在前的消息更考虑消息容器的尾部。
请参见图3B所示,其是本发明一个实施例中提供的直播聊天室对应的消息容器的示意图,在图3B中的三个消息容器中,第一消息容器用于承载该直播聊天室具备第一优先级的消息,比如消息11、消息12、消息13、消息14、消息15、消息16、消息17、消息18;第二消息容器用于承载该直播聊天室具备第二优先级的消息,比如消息21、消息22、消息23、消息24、消息25、消息26、消息27、消息28;第三消息容器用于承载该直播聊天室具备第三优先级的消息,比如消息31、消息32、消息33、消息34。其中第一优先级低于第二优先级,第二优先级低于第三优先级,第三优先级为白名单消息所具备的优先级。每个消息容器中时间在前的消息位于时间在后的消息的前面,也即时间在前的消息相对于时间在后的消息更靠近消息容器的头部位置。比如,第一消息容器中消息11的生成时刻早于消息12的生成时刻。
服务器在需要向客户端发送该直播聊天室的消息时,从各个消息容器中按照优先级从高到低读取尚未被发送给该客户端的消息,将读取的消息发送给该客户端。
服务器在按照优先级从高到低依次从各个消息容器中读取尚未被发送给客户端的预定数量的消息时,在一种实现中,可以参见步骤306和步骤307的步骤。
步骤306,在需要向客户端发送该直播聊天室的消息时,获取最后一次向该客户端发送消息时的时间戳。
在一种应用中,服务器在存储有尚未被推送给客户端的消息时,会向客户端发送通知,该通知用于告知客户端服务器存储有该客户端当前开启的直播聊天室的新消息。对应的,客户端可以向服务器发送该直播聊天室的消息拉取请求,服务器在接收到客户端发送的直播聊天室的消息拉取请求之后,则确定需要向该客户端发送该直播聊天室的消息。
在另一种应用中,服务器在存储有尚未被推送给客户端的消息时,可以每隔预定时间间隔主动向客户端推送该直播聊天是的消息,服务器可以将预定时间间隔所对应的时刻确定为需要向客户端发送直播聊天室的消息的时刻。
服务器在需要向客户端发送该直播聊天室的消息时,为了避免向该客户端发送重复的消息,或者避免向客户端遗漏较重要的消息,则需要获取最后一次向该客户端发送消息时的时间戳。对于被推送的客户端来讲,直播聊天室中消息生成时刻位于最后一次被推送消息时之后产生的消息才对客户端的显示有意义,而在最后一次被推送消息之前的消息如果被推送给该客户端,则会使得客户端显示的消息排序出错,因此,服务器可以向该客户端发送保留的该直播聊天室的该时间戳之后的消息。
步骤307,按照优先级从高到低依次从各个消息容器中读取该时间戳之后存储的预定数量的消息。
在实际应用中,服务器针对某个直播聊天室每秒可能需要向客户端发送若干次消息,但一般来讲,这若干次发送的消息的数量总和在100条左右,因此服务器在每次向客户端推送消息时,最多推送预定数量的消息。
由于客户端是按照消息的生成时刻展示消息的,因此服务器也应当按照消息的生成时刻向客户端推送优先级较高的消息。在一种实现方式中,服务器在按照优先级从高到低依次从各个消息容器中读取该时间戳之后存储的预定数量的消息时,首先,按照优先级从高到低依次从各个消息容器读取消息时,按照消息的存储时间从早到晚依次读取该时间戳之后存储的消息;然后,当已读取的消息的数量达到该预定数量时,停止读取存储的该直播聊天室的消息。
也就是说,服务器首先从优先级最高的消息容器中读取时间戳之后存储的消息,若读取的消息的数量未达到预定数量,则从下一个较低的优先级的消息容器中读取时间戳之后存储的消息,若读取的总消息数量未达到预定数量,则继续从下一个较低的优先级的消息容器中读取时间戳之后存储的消息,直到读取的消息的数量达到预定数量,停止本次从消息容器中读取存储的该直播聊天室的消息,执行步骤308。
请参见图3C所示,其是本发明一个实施例中提供的从直播聊天室对应的消息容器读取消息的示意图。结合图3C,以预定数量为10条为例,服务器首先确定上一次向该客户端推送消息的时刻t1,然后从第三优先级(也即最高优先级)对应的第三消息容器中读取出该时刻之后的消息,比如图3C中所示的消息34。由于读取的消息的数量尚未达到预定数量,因此服务器继续从第二优先级(也即低于最高优先级的高优先级)对应的第二消息容器读取出该时刻之后的消息,比如图3C所示的消息22至消息28,由于读取的消息的总数量(从第三消息容器中读取了1条,从第二消息容器中读取了7条,共8条)仍旧未达到预定数量10条,因此服务器继续从第一优先级(也即低于高优先级的最低优先级)对应的第一消息容器读取出该时刻之后的消息,比如图3C所示的消息14和消息15,第一消息容器中剩余的消息(比如消息17、消息18)则在本次不被读取。
考虑到消息的及时性,如果从各个消息容器读取上述时间戳之后存储的消息的总数量未达到预定数量,服务器也无需等待,直接执行步骤308。
步骤308,将读取的消息发送给该客户端。
服务器在从消息容器读取消息后,将读取的消息发送给对应的客户端。
在直播聊天室的消息高并发时,由于服务器仅按照统计时间段保留了预定范围的消息,使得服务器仅保留了单位时间段内合理数量的消息。当客户端从服务器拉取消息时,服务器仅提供较高优先级的合理数量的消息,因此客户端在直播聊天室的消息高并发时,也仅需要单位时间段显示合理数量的较高优先级的消息即可。
需要补充说明的是,服务器在在每个统计时间段结束时,对该统计时间段对保留的该直播聊天室的上行消息进行统计得到的数量进行清零,这样每个统计时间段的保留消息的数量均从零开始计数。
综上所述,本发明实施例中提供的直播聊天室的消息处理方法,按照消息的优先级,将直播聊天室的上行消息进行选择性丢弃和保留,使得统计时间段内保留的消息的数量在合理范围内,这些消息被推送给客户端后可以满足肉眼对客户端所展示的消息的查看;由于在服务器可以直接丢弃直播聊天室的一些优先级较低的消息,从而避免了服务器侧对高并发量的消息均进行处理,进而避免了高并发量的消息对服务器端资源的浪费。
下面为本发明中的装置实施例,对于装置实施例中未详尽描述的细节,可以结合参考上述一一对应的方法实施例。
图4是本发明一个实施例中提供的直播聊天室的消息处理装置的结构示意图,该直播聊天室的消息处理装置可以以软件、硬件或软硬件结合的方式实现成为服务器或服务器的一部分,这里所讲的服务器可以为图1A中的服务器110或为图1B中的服务器110b。该直播聊天室的消息处理装置可以包括:保留模块410、处理模块420、读取模块430和发送模块440。
保留模块410,用于按照消息的优先级,将接收到的直播聊天室的消息进行选择性丢弃或保留,使得统计时间段内保留的该直播聊天室的消息的数量在预定范围内,同一统计时间段内在先被丢弃的消息的优先级不高于在后被丢弃的消息的优先级;
处理模块420,用于按照预定方式对该保留模块410所保留的消息进行处理;
读取模块430,用于在需要向客户端发送该直播聊天室的消息时,从该处理模块420所处理过的该直播聊天室的消息中读取尚未被发送给该客户端的消息;
发送模块440,用于将该读取模块430读取的消息发送给该客户端。
综上所述,本发明实施例中提供的直播聊天室的消息处理装置,按照消息的优先级,将直播聊天室的上行消息进行选择性丢弃和保留,使得统计时间段内保留的消息的数量在合理范围内,这些消息被推送给客户端后可以满足肉眼对客户端所展示的消息的查看;由于在服务器可以直接丢弃直播聊天室的一些优先级较低的消息,从而避免了服务器侧对高并发量的消息均进行处理,进而避免了高并发量的消息对服务器端资源的浪费。
图5是本发明另一个实施例中提供的直播聊天室的消息处理装置的结构示意图,该直播聊天室的消息处理装置可以以软件、硬件或软硬件结合的方式实现成为服务器或服务器的一部分,这里所讲的服务器可以为图1A中的服务器110或为图1B中的服务器110b。该直播聊天室的消息处理装置可以包括:保留模块510、处理模块520、读取模块530和发送模块540。
该保留模块510可以用于按照消息的优先级,将接收到的直播聊天室的消息进行选择性丢弃或保留,使得统计时间段内保留的该直播聊天室的消息的数量在预定范围内,同一统计时间段内在先被丢弃的消息的优先级不高于在后被丢弃的消息的优先级;
该处理模块520可以用于按照预定方式对该保留模块510所保留的消息进行处理;
该读取模块530可以用于在需要向客户端发送该直播聊天室的消息时,从该处理模块520所处理过的该直播聊天室的消息中读取尚未被发送给该客户端的消息;
该发送模块540可以用于将该读取模块530读取的消息发送给该客户端。
在一种可能的实现方式中,保留模块510可以包括:获取单元511、确定单元512、丢弃单元513和保留单元514。
该获取单元511可以用于在每接收到该直播聊天室的一条消息时,获取该消息的优先级;
该确定单元512可以用于根据当前统计时间段内已保留的该直播聊天室的消息的数量,确定该数量对应的当前需要丢弃的消息的优先级;
该丢弃单元513可以用于当该获取单元511获取的消息的优先级属于该确定单元512确定的当前需要丢弃的消息的优先级时,则丢弃该消息;
该保留单元514可以用于当该获取单元511获取的消息的优先级不属于该确定单元512当前需要丢弃的消息的优先级,则保留该消息。
在另一种可能的实现方式中,该装置还可以包括:存储模块550。
该存储模块550可以用于将处理过的消息存储至与消息的优先级对应的消息容器中;
该读取模块530还可以用于按照优先级从高到低依次从各个消息容器中读取尚未被发送给该客户端的预定数量的消息。
在一种可能的实现方式中,每个单位时间段包括a个统计时间段,客户端在一个单位时间段允许显示的消息的数量小于n个,该确定单元512还可以包括:第一确定子单元512a、第二确定子单元512b和第三确定子单元512c。
该第一确定子单元512a可以用于当该当前统计时间内已经保留的该直播聊天室的消息的数量小于n/a时,确定该当前需要丢弃的消息的优先级为空;
该第二确定子单元512b可以用于当该当前统计时间内已经保留的消息的数量大于n/a且小于2n/a时,将第一优先级确定为该当前需要丢弃的消息的优先级;
该第三确定子单元512c可以用于当该当前统计时间内已经保留的消息的数量大于2n/a时,将该第一优先级和第二优先级确定为该当前需要丢弃的消息的优先级,保留具备第三优先级的消息,该第一优先级低于该第二优先级,该第二优先级低于第三优先级。
在另一种可能的实现方式中,该读取模块530可以包括:获取单元531和读取单元532。
获取单元531可以用于获取最后一次向该客户端发送消息时的时间戳;
读取单元532可以用于按照优先级从高到低依次从各个消息容器中读取获取单元531获取的时间戳之后存储的预定数量的消息。
在另一种可能的实现方式中,该读取单元532可以用于按照优先级从高到低依次从各个消息容器读取消息时,按照消息的存储时间从早到晚依次读取该时间戳之后存储的消息;当已读取的消息的数量达到该预定数量时,停止本次读取存储的该直播聊天室的消息,触发发送模块540将读取的消息发送给该客户端。
在另一种可能的实现方式中,该装置还可以包括:清零模块560。
该清零模块560可以用于在该统计时间段结束时,对在该统计时间段对保留的所述直播聊天室的消息进行统计得到的数量进行清零。
综上所述,本发明实施例中提供的直播聊天室的消息处理装置,按照消息的优先级,将直播聊天室的上行消息进行选择性丢弃和保留,使得统计时间段内保留的消息的数量在合理范围内,这些消息被推送给客户端后可以满足肉眼对客户端所展示的消息的查看;由于在服务器可以直接丢弃直播聊天室的一些优先级较低的消息,从而避免了服务器侧对高并发量的消息均进行处理,进而避免了高并发量的消息对服务器端资源的浪费。
需要说明的是:上述实施例中提供的直播聊天室中消息处理装置在处理直播聊天室中消息时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将服务器的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的直播聊天室中消息处理装置与直播聊天室中消息处理方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
图6是本发明一个实施例中提供的服务器的结构示意图。该服务器600为图1A实施环境中的服务器110或图1B实施环境中的服务器110b。
服务器600包括中央处理单元(英文:central processing unit,CPU)601、包括随机存取存储器(英文:random-access memory,RAM)602和只读存储器(英文:read-onlymemory,ROM)603的系统存储器604,以及连接系统存储器604和中央处理单元601的系统总线605。服务器600还包括帮助计算机内的各个器件之间传输信息的基本输入/输出(英文:input/output,I/O)系统606,和用于存储操作系统613、应用程序614和其他程序模块615的大容量存储设备607。
基本输入/输出系统606包括有用于显示信息的显示器608和用于用户输入信息的诸如鼠标、键盘之类的输入设备609。其中显示器608和输入设备609都通过连接到系统总线605的输入/输出控制器610连接到中央处理单元601。基本输入/输出系统606还可以包括输入/输出控制器610以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地,输入/输出控制器610还提供输出到显示屏、打印机或其他类型的输出设备。
大容量存储设备607通过连接到系统总线605的大容量存储控制器(未示出)连接到中央处理单元601。大容量存储设备607及其相关联的计算机可读介质为服务器600提供非易失性存储。也就是说,大容量存储设备607可以包括诸如硬盘或者CD-ROM驱动器之类的计算机可读介质(未示出)。
不失一般性,计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括静态随机存取存储器(英文:static random access memory,SRAM),电可擦除可编程只读存储器(英文:electrically erasable programmable read-only memory,EEPROM),可擦除可编程只读存储器(英文:erasable programmable read only memory,EPROM),可编程只读存储器(英文:programmable read only memory,PROM)、RAM、ROM、闪存或其他固态存储其技术,CD-ROM、数字通用光盘(英文:digital versatile disc,DVD)或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然,本领域技术人员可知计算机存储介质不局限于上述几种。上述的系统存储器604和大容量存储设备607可以统称为存储器。
根据本发明的各种实施例,服务器600还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器600可以通过连接在系统总线605上的网络接口单元611连接到网络612,或者说,也可以使用网络接口单元611来连接到其他类型的网络或远程计算机系统(未示出)。
上述系统存储器604还包括一个或者一个以上的程序,这些程序经配置以由一个或者一个以上处理器执行。
在示例性实施例中,还提供了一种包括指令的非临时性计算机可读存储介质,例如包括指令的存储器,上述指令可由服务器的处理器执行以完成上述直播聊天室的消息处理方法。例如,所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
除非另作定义,此处使用的技术术语或者科学术语应当为本发明所属领域内具有一般技能的人士所理解的通常意义。本发明专利申请说明书以及权利要求书中使用的“第一”、“第二”、“第三”以及类似的词语并不表示任何顺序、数量或者重要性,而只是用来区分不同的组成部分。同样,“一个”或者“一”等类似词语也不表示数量限制,而是表示存在至少一个。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接,而是可以包括电性的连接,不管是直接的还是间接的。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (8)

1.一种直播聊天室的消息处理方法,其特征在于,应用于服务器中,所述方法包括:
按照消息的优先级,将接收到的直播聊天室的消息进行选择性丢弃或保留,使得统计时间段内保留的所述直播聊天室的消息的数量在预定范围内,同一统计时间段内在先被丢弃的消息的优先级不高于在后被丢弃的消息的优先级;
按照预定方式对保留的消息进行处理;
在需要向客户端发送所述直播聊天室的消息时,从处理过的所述直播聊天室的消息中读取尚未被发送给所述客户端的消息,将读取的消息发送给所述客户端;
在所述按照预定方式对保留的消息进行处理之后,所述方法还包括:
将处理过的消息存储至与消息的优先级对应的消息容器中;
所述从处理过的所述直播聊天室的消息中读取尚未被发送给所述客户端的消息,包括:
按照优先级从高到低依次从各个消息容器中读取尚未被发送给所述客户端的预定数量的消息。
2.根据权利要求1所述的方法,其特征在于,所述按照消息的优先级,将接收到的直播聊天室的消息进行选择性丢弃或保留,包括:
在每接收到所述直播聊天室的一条消息时,获取所述消息的优先级;
根据当前统计时间段内已保留的所述直播聊天室的消息的数量,确定所述数量对应的当前需要丢弃的消息的优先级;
当所述获取的消息的优先级属于所述当前需要丢弃的消息的优先级时,则丢弃所述消息;
当所述获取的消息的优先级不属于所述当前需要丢弃的消息的优先级,则保留所述消息。
3.根据权利要求2所述的方法,其特征在于,每个单位时间段包括a个统计时间段,客户端在一个单位时间段允许显示的消息的数量小于n个,所述根据当前统计时间段内已保留的所述直播聊天室的消息的数量,确定所述数量对应的当前需要丢弃的消息的优先级,包括:
当所述当前统计时间内已经保留的所述直播聊天室的消息的数量小于n/a时,确定所述当前需要丢弃的消息的优先级为空,从而不对消息进行丢弃;
当所述当前统计时间内已经保留的消息的数量大于n/a且小于2n/a时,将第一优先级确定为所述当前需要丢弃的消息的优先级;
当所述当前统计时间内已经保留的消息的数量大于2n/a时,将所述第一优先级和第二优先级确定为所述当前需要丢弃的消息的优先级,确定保留具备第三优先级的消息,所述第一优先级低于所述第二优先级,所述第二优先级低于所述第三优先级。
4.根据权利要求1所述的方法,其特征在于,所述按照优先级从高到低依次从各个消息容器中读取尚未被发送给所述客户端的预定数量的消息,包括:
获取最后一次向所述客户端发送消息时的时间戳;
按照优先级从高到低依次从各个消息容器中读取所述时间戳之后存储的预定数量的消息;
将读取的消息发送给所述客户端。
5.根据权利要求4所述的方法,其特征在于,所述按照优先级从高到低依次从各个消息容器中读取所述时间戳之后存储的预定数量的消息,包括:
按照优先级从高到低依次从各个消息容器读取消息时,按照消息的存储时间从早到晚依次读取所述时间戳之后存储的消息;
当读取的消息的数量达到所述预定数量时,执行所述将读取的消息发送给所述客户端的步骤。
6.根据权利要求1至5中任一所述的方法,其特征在于,所述方法还包括:
在所述统计时间段结束时,对在所述统计时间段对保留的所述直播聊天室的消息进行统计得到的数量进行清零。
7.一种直播聊天室的消息处理装置,其特征在于,应用于服务器中,所述装置包括:
保留模块,用于按照消息的优先级,将接收到的直播聊天室的消息进行选择性丢弃或保留,使得统计时间段内保留的所述直播聊天室的消息的数量在预定范围内,同一统计时间段内在先被丢弃的消息的优先级不高于在后被丢弃的消息的优先级;
处理模块,用于按照预定方式对所述保留模块所保留的消息进行处理;
读取模块,用于在需要向客户端发送所述直播聊天室的消息时,从所述处理模块所处理过的所述直播聊天室的消息中读取尚未被发送给所述客户端的消息;
发送模块,用于将所述读取模块读取的消息发送给所述客户端;
所述装置还包括:
存储模块,用于将处理过的消息存储至与消息的优先级对应的消息容器中;
所述读取模块,还用于:
按照优先级从高到低依次从各个消息容器中读取尚未被发送给所述客户端的预定数量的消息。
8.根据权利要求7所述的装置,其特征在于,所述保留模块,包括:
获取单元,用于在每接收到所述直播聊天室的一条消息时,获取所述消息的优先级;
确定单元,用于根据当前统计时间段内已保留的所述直播聊天室的消息的数量,确定所述数量对应的当前需要丢弃的消息的优先级;
丢弃单元,用于当所述获取单元获取的消息的优先级属于所述确定单元确定的当前需要丢弃的消息的优先级时,则丢弃所述消息;
保留单元,用于当所述获取单元获取的消息的优先级不属于所述确定单元当前需要丢弃的消息的优先级,则保留所述消息。
CN201611116723.3A 2016-12-07 2016-12-07 直播聊天室的消息处理方法及装置 Active CN108174305B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201611116723.3A CN108174305B (zh) 2016-12-07 2016-12-07 直播聊天室的消息处理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611116723.3A CN108174305B (zh) 2016-12-07 2016-12-07 直播聊天室的消息处理方法及装置

Publications (2)

Publication Number Publication Date
CN108174305A CN108174305A (zh) 2018-06-15
CN108174305B true CN108174305B (zh) 2019-03-12

Family

ID=62526229

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611116723.3A Active CN108174305B (zh) 2016-12-07 2016-12-07 直播聊天室的消息处理方法及装置

Country Status (1)

Country Link
CN (1) CN108174305B (zh)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110971920B (zh) * 2018-09-30 2021-11-26 武汉斗鱼网络科技有限公司 一种消息的降级方法及相关装置
CN110971921B (zh) * 2018-09-30 2022-03-25 武汉斗鱼网络科技有限公司 一种礼物消息的降级方法及相关装置
CN110493610A (zh) * 2019-08-14 2019-11-22 北京达佳互联信息技术有限公司 聊天室开启视频画面的方法、装置、电子设备及存储介质
CN110662085B (zh) 2019-10-16 2021-10-01 北京字节跳动网络技术有限公司 消息发送方法、装置、可读介质及电子设备
CN111277847B (zh) * 2020-01-21 2022-02-25 卓米私人有限公司 直播中聊天消息的展示方法、装置、服务器及系统
CN111414516A (zh) * 2020-03-17 2020-07-14 北京字节跳动网络技术有限公司 一种直播间消息处理方法、装置、电子设备及存储介质
CN111416765A (zh) * 2020-03-20 2020-07-14 北京字节跳动网络技术有限公司 一种互动消息处理的方法及装置
CN112199174A (zh) * 2020-09-30 2021-01-08 北京字节跳动网络技术有限公司 消息发送的控制方法、装置、电子设备及计算机可读存储介质
CN112436997B (zh) * 2020-11-10 2023-03-03 杭州米络星科技(集团)有限公司 聊天室的消息分发方法、消息分发系统及电子设备
CN112988417A (zh) * 2021-03-04 2021-06-18 长沙市到家悠享网络科技有限公司 消息处理方法、装置、电子设备及计算机可读介质
CN113098781B (zh) * 2021-03-19 2023-01-20 北京达佳互联信息技术有限公司 会话列表处理方法、装置、服务器及存储介质
CN113645508B (zh) * 2021-08-10 2023-09-19 北京读我科技有限公司 一种消息输出方法、装置及系统
CN115334331B (zh) * 2022-08-23 2023-09-22 苏州青颖飞帆软件科技股份有限公司 一种教学直播的通讯方法、设备及存储介质
CN115633194A (zh) * 2022-12-21 2023-01-20 易方信息科技股份有限公司 直播回放方法、装置、计算机设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101026572A (zh) * 2006-01-23 2007-08-29 美国阿尔卡特资源有限合伙公司 具有智能分组丢弃功能的视频分组复用器
CN104506715A (zh) * 2014-12-05 2015-04-08 小米科技有限责任公司 通知消息显示方法及装置
CN105657519A (zh) * 2016-02-18 2016-06-08 海信电子科技(深圳)有限公司 电视提示信息管理方法及电视
CN105868247A (zh) * 2015-12-15 2016-08-17 乐视网信息技术(北京)股份有限公司 一种信息显示方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101026572A (zh) * 2006-01-23 2007-08-29 美国阿尔卡特资源有限合伙公司 具有智能分组丢弃功能的视频分组复用器
CN104506715A (zh) * 2014-12-05 2015-04-08 小米科技有限责任公司 通知消息显示方法及装置
CN105868247A (zh) * 2015-12-15 2016-08-17 乐视网信息技术(北京)股份有限公司 一种信息显示方法及装置
CN105657519A (zh) * 2016-02-18 2016-06-08 海信电子科技(深圳)有限公司 电视提示信息管理方法及电视

Also Published As

Publication number Publication date
CN108174305A (zh) 2018-06-15

Similar Documents

Publication Publication Date Title
CN108174305B (zh) 直播聊天室的消息处理方法及装置
CN106487781B (zh) 基于直播的资源数据处理方法、装置和系统
US10210342B2 (en) Centralized throttling service
WO2018133306A1 (zh) 内容分发网络中的调度方法和设备
CN106161219B (zh) 消息处理方法及装置
CN110191348A (zh) 视频直播中互动消息的处理方法及装置
CN110830735B (zh) 一种视频生成方法、装置、计算机设备和存储介质
US9686329B2 (en) Method and apparatus for displaying webcast rooms
CN104539977B (zh) 直播预览方法及装置
US8244822B1 (en) Push notification delivery system
CN104901863B (zh) 发送即时提示消息的方法、装置及系统
WO2014183427A1 (en) Method and apparatus for displaying webcast rooms
CN108540868A (zh) Hls直播的处理方法、装置、服务器、终端及存储介质
CN107979525A (zh) 一种红包发放方法、设备以及介质
CN103986715A (zh) 一种网络流量控制的方法及装置
CN112468836A (zh) 虚拟物品发放管理方法、装置、电子设备及存储介质
CN110324680B (zh) 一种视频推送方法、装置及服务器、客户端、存储介质
CN110808922A (zh) 一种消息处理方法、装置、存储介质及电子设备
CN108123866B (zh) 消息传输方法及装置
CN106790696A (zh) 一种消息传输方法和装置
CN108924609A (zh) 流媒体数据传输的方法、电子设备、装置及存储介质
CN110635921A (zh) 基于群组的交互方法、装置、设备及可读介质
CN110099292B (zh) 一种数据中心节点确定方法、装置及电子设备
EP3577861A1 (en) Method for the exchange of multimedia data among mobile devices via instant messaging
WO2020007266A1 (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