CN113965810A - 基于聊天室的数据处理方法以及装置 - Google Patents
基于聊天室的数据处理方法以及装置 Download PDFInfo
- Publication number
- CN113965810A CN113965810A CN202111137132.5A CN202111137132A CN113965810A CN 113965810 A CN113965810 A CN 113965810A CN 202111137132 A CN202111137132 A CN 202111137132A CN 113965810 A CN113965810 A CN 113965810A
- Authority
- CN
- China
- Prior art keywords
- message
- chat room
- message data
- users
- data 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.)
- Granted
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 16
- 238000012545 processing Methods 0.000 claims abstract description 103
- 238000004891 communication Methods 0.000 claims abstract description 87
- 238000000034 method Methods 0.000 claims abstract description 33
- 230000000977 initiatory effect Effects 0.000 claims abstract description 9
- 230000007246 mechanism Effects 0.000 claims description 20
- 238000002955 isolation Methods 0.000 claims description 12
- 238000009792 diffusion process Methods 0.000 claims description 11
- 230000002159 abnormal effect Effects 0.000 claims description 9
- 230000004044 response Effects 0.000 claims description 5
- 230000008569 process Effects 0.000 description 7
- 238000013461 design Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 238000007619 statistical method Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 239000002360 explosive Substances 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000005856 abnormality Effects 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000011218 segmentation Effects 0.000 description 2
- 238000004880 explosion Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
- H04N21/4788—Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
- H04N21/2407—Monitoring of transmitted content, e.g. distribution time, number of downloads
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/44204—Monitoring of content usage, e.g. the number of times a movie has been viewed, copied or the amount which has been watched
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/65—Transmission of management data between client and server
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本申请公开了一种基于聊天室的数据处理方法以及装置。该方法包括确定所述聊天室中当前在线用户人数；响应于当前发起网络请求的所述用户的消息通信指令；基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据。本申请解决了大规模在线人数的聊天室中消息处理稳定性以及正确性处理能力不足的技术问题。通过本申请使得聊天室中每个用户所发送的信息正确正常的发送，且用户又能非常迅速与正确的接收到其他用户所发送的信息。本申请适用于拍卖业务场景下的不同角色在聊天室中实时消息的处理。
Description
技术领域
本申请涉及计算机软件领域，具体而言，涉及一种基于聊天室的数据处理方法以及装置。
背景技术
随着直播和类直播场景的增长，相关业务对于在线状态时的实时消息需求日益增长，需要通过直播聊聊天室完成。
当聊天室中的用户人数达到一定数量之后，无法支持聊天室中消息的稳定性以及造成正确性处理能力降低，从而影响用户体验。
针对相关技术中大规模在线人数的聊天室中消息处理稳定性以及正确性处理能力不足的问题，目前尚未提出有效的解决方案。
发明内容
本申请的主要目的在于提供一种基于聊天室的数据处理方法以及装置，以解决大规模在线人数的聊天室中消息处理稳定性以及正确性处理能力不足的问题。
为了实现上述目的，根据本申请的一个方面，提供了一种基于聊天室的数据处理方法。
根据本申请的基于聊天室的数据处理方法包括：确定所述聊天室中当前在线用户人数；响应于当前发起网络请求的所述用户的消息通信指令；基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据。
进一步地，方法还包括：按照业务访问流量预估结果，将所述聊天室划分至少包括第一聊天室以及第二聊天室；根据所述第一聊天室以及第二聊天室以及不同预设消息隔离通道，得到第一聊天室消息通道以及第二聊天室消息通道；通过所述第一聊天室消息通道下发第一消息数据，其中所述第一消息数据用于通过指定的所述第一聊天室消息通道下发；通过所述第二聊天室消息通道下发第二消息数据，其中所述第一消息数据用于通过所述第二聊天室消息通道或者第三聊天室消息通道下发。
进一步地，通过所述第一聊天室消息通道下发第一消息数据，其中所述第一消息数据用于通过指定的所述第一聊天室消息通道下发之后，包括：通过所述第一聊天室消息通道接收在所述第一聊天室中的消息数据；通过所述第二聊天室消息通道下发第二消息数据，其中所述第一消息数据用于通过所述第二聊天室消息通道或者第三聊天室消息通道下之后，包括：通过所述第二聊天室消息通道接收在所述第二聊天室和/或第三聊天室的消息数据。
进一步地，所述响应于当前发起网络请求的所述用户的消息通信指令，还包括：所述聊天室中不同角色的用户包括：第一角色用户，所述第一角色用户用于促成所述聊天室中的交易；接收所述第一角色用户写入的新消息，并存储消息数据；基于对所述第一角色用户的订阅用户，响应于当前发起网络请求的所述订阅用户的消息通信指令，将所述消息数据下发。
进一步地，所述基于所述消息通信指令、预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：接收客户端用于拉取消息数据的网络请求；基于长轮询机制，如果当前没有新消息，则与所述客户端保持长链接直到产生新消息；在预设周期内，再次接收所述客户端用于拉取消息数据的网络请求；基于与所述第一角色用户的所述消息通信指令、长连接消息数据处理策略以及所述聊天室中的所述第一角色用户，向所述客户端下发所述消息数据，和/或接收消息数据。
进一步地，所述基于所述消息通信指令、预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：当所述聊天室中在线状态时的实时消息发生异常的情况下，通过异步线程任务向客户端下发消息数据；基于所述异常的消息通信指令、NoCache消息数据处理策略以及所述聊天室中不同角色的用户，至少向所述客户端下发一次所述消息数据，和/或接收消息数据。
进一步地，所述基于所述消息通信指令、预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：基于所述消息通信指令对消息进行标记，用以在客户端获取消息数据时区分不同的消息列表；根据所述消息列表中的预设消息优先级消息数据处理策略，向所述聊天室中不同角色的用户的客户端下发所述消息数据，和/或接收消息数据。
进一步地，所述基于所述消息通信指令、预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：基于所述消息通信指令对消息进行去重统计，用以在客户端获取消息数据时提前进行去重；根据预设去重消息数据处理策略，向所述聊天室中不同角色的用户的客户端下发去重后的所述消息数据，和/或接收消息数据。
进一步地，所述基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：通过所述聊天室中的应用场景，确定所述消息通信指令中的交易指令，其中所述应用场景包括拍卖业务；基于所述在线用户人数，确定对应的所述预设消息数据处理策略；基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，向参与拍卖业务的所述客户端下发和/或接收消息数据，其中所述在线用户人数的预设消息数据处理策略至少包括如下之一：读扩散机制、longpolling策略、NoCache策略、消息列表分级策略、基于hyperloglog统计策略、隔离VIP消息服务器策略。
为了实现上述目的，根据本申请的另一方面，提供了一种用于聊天室的数据处理装置。
根据本申请的用于聊天室的数据处理装置包括：确定模块，用于确定所述聊天室中当前在线用户人数；响应模块，用于响应于当前发起网络请求的所述用户的消息通信指令；消息处理模块，用于基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据。
在本申请实施例中基于聊天室的数据处理方法以及装置，采用确定所述聊天室中当前在线用户人数的方式，通过响应于当前发起网络请求的所述用户的消息通信指令，达到了基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据的目的，从而实现了基于聊天室的消息数据高稳定性以及实时性的技术效果，进而解决了大规模在线人数的聊天室中消息处理稳定性以及正确性处理能力不足的技术问题。
附图说明
构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是根据本申请实施例的基于聊天室的数据处理方法的系统架构示意图；
图2是根据本申请实施例的基于聊天室的数据处理方法流程示意图；
图3是根据本申请实施例的基于聊天室的数据处理装置结构示意图；
图4是根据本申请优选实施例的基于聊天室的数据处理方法流程示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
如图1所示，是根据本申请实施例的基于聊天室的数据处理方法的系统架构示意图，其中包括客户端100、业务后台200、聊天室后台300。可以理解，所述业务后台200、聊天室后台300在服务端，用于响应所述客户端100的网络请求。在本申请的实施例中的数据处理方法主要集中在所述聊天室后台300中。通过所述聊天室后台300对用户的聊天信息数据进行接收、发送的同时，尽可能缓解后台服务器的压力。
如图2所示，该方法包括如下的步骤S201至步骤S203：
步骤S201，确定所述聊天室中当前在线用户人数；
步骤S202，响应于当前发起网络请求的所述用户的消息通信指令；
步骤S203，基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据。
上述步骤S201中服务器端需要统计当前所述聊天室中当前在线用户人数，对于不同量级的在线用户人数，服务器端可以采用相应的方式对消息数据进行处理。
作为一种可选的实施方式，在服务器端可以统计基于历史在线用户人数。
作为一种优选的实施方式，在服务器端可以预先预计在线用户人数。
上述步骤S202中在服务器端响应于当前发起网络请求的所述用户的消息通信指令。当用户端需要用通过聊天室进行聊天时会发送相应的通信指令。当用户端有聊天信息数据发送需求时，都是相应地发送通信指令。
作为一种可选的实施方式，所述通信指令携带有用户ID。
作为一种优选的实施方式，所述通信指令包括但不限于：基于不同场景下的聊天信息数据。
上述步骤S203中基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，在服务器端实现下发和/或接收消息数据。在所述服务器端响应于所述消息通信指令，同时在搜书服务器端结合所述在线用户人数的预设消息数据处理策略和所述聊天室中不同角色的用户，向不同角色的用户下发消息数据。并且，同时，接收不同角色的用户通过消息通信指令发送的消息数据。
作为一种可选的实施方式，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的。所述用户通过所述聊天室进行交互的场景可以是，不用角色的用户对商品的拍卖行为，比如包括拍卖师、客户、买家等用户，这些用户可以通过所述聊天室进行聊天并进行拍卖。
作为一种优选的实施方式，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据。每个用户都可以通过所述用户端进入到所述聊天室。此外，需要注意的是，预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据。当有新消息产生，用户端的用户可以拉取消息数据。
从以上的描述中，可以看出，本申请实现了如下技术效果：
采用确定所述聊天室中当前在线用户人数的方式，通过响应于当前发起网络请求的所述用户的消息通信指令，达到了基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据的目的，从而实现了基于聊天室的消息数据高稳定性以及实时性的技术效果，进而解决了大规模在线人数的聊天室中消息处理稳定性以及正确性处理能力不足的技术问题。
作为本实施例中的优选，还包括：按照业务访问流量预估结果，将所述聊天室划分至少包括第一聊天室以及第二聊天室；根据所述第一聊天室以及第二聊天室以及不同预设消息隔离通道，得到第一聊天室消息通道以及第二聊天室消息通道；通过所述第一聊天室消息通道下发第一消息数据，其中所述第一消息数据用于通过指定的所述第一聊天室消息通道下发；通过所述第二聊天室消息通道下发第二消息数据，其中所述第一消息数据用于通过所述第二聊天室消息通道或者第三聊天室消息通道下发。
如果发生海量直播间会带来爆发式的请求量，故不能让海量直播间引起的失败影响占大多数的小直播间。具体实施时，按照业务访问流量预估结果比如通过运营预估或者历史数据获取。按照业务访问流量预估结果，将所述聊天室划分至少包括第一聊天室以及第二聊天室；根据所述第一聊天室以及第二聊天室以及不同预设消息隔离通道，得到第一聊天室消息通道以及第二聊天室消息通道；并且通过所述第一聊天室消息通道下发第一消息数据，其中所述第一消息数据用于通过指定的所述第一聊天室消息通道下发；通过所述第二聊天室消息通道下发第二消息数据，其中所述第一消息数据用于通过所述第二聊天室消息通道或者第三聊天室消息通道下发。
所述第一聊天室消息通道即作为隔离VIP消息服务器，比如热门聊天室与普通聊天室服务器的分割，应对所占资源的不同，以及出现问题的影响，进行从硬件服务器，流量请求进行隔离。比如，通过业务运营预判，将热门拍卖设置为VIP消息服务器，其他就走不通消息服务器，降低系统对于服务器的压力。所述第二聊天室消息通道作为普通消息通道。
优选地，隔离VIP消息服务器人为的将热门与普通拍卖聊天室进行物理服务器的分离，异常发生时可以有效预防热门与普通的拍卖聊天室服务器的互相影响。
作为本实施例中的优选，通过所述第一聊天室消息通道下发第一消息数据，其中所述第一消息数据用于通过指定的所述第一聊天室消息通道下发之后，包括：通过所述第一聊天室消息通道接收在所述第一聊天室中的消息数据；通过所述第二聊天室消息通道下发第二消息数据，其中所述第一消息数据用于通过所述第二聊天室消息通道或者第三聊天室消息通道下之后，包括：通过所述第二聊天室消息通道接收在所述第二聊天室和/或第三聊天室的消息数据。
具体实施时，如果发生海量直播间会带来爆发式的请求量，故不能让海量直播间引起的失败影响占大多数的小直播间。具体实施时，通过所述第一聊天室消息通道接收在所述第一聊天室中的消息数据；通过所述第二聊天室消息通道下发第二消息数据，其中所述第一消息数据用于通过所述第二聊天室消息通道或者第三聊天室消息通道下之后，包括：通过所述第二聊天室消息通道接收在所述第二聊天室和/或第三聊天室的消息数据。
作为本实施例中的优选，所述响应于当前发起网络请求的所述用户的消息通信指令，还包括：所述聊天室中不同角色的用户包括：第一角色用户，所述第一角色用户用于促成所述聊天室中的交易；接收所述第一角色用户写入的新消息，并存储消息数据；基于对所述第一角色用户的订阅用户，响应于当前发起网络请求的所述订阅用户的消息通信指令，将所述消息数据下发。
所述第一角色用户用于促成所述聊天室中的交易，比如，第一角色可以是拍卖师。
具体实施时，对于所述聊天室中不同角色的用户中的第一角色用户。在后台服务端接收所述第一角色用户写入的新消息，并存储消息数据；基于对所述第一角色用户的订阅用户，响应于当前发起网络请求的所述订阅用户的消息通信指令，将所述消息数据下发。上述方式即是读扩散机制，通过读扩散机制使得写入数据非常方便以及数据存储比较少量。
作为本实施例中的优选，所述基于所述消息通信指令、预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：接收客户端用于拉取消息数据的网络请求；基于长轮询机制，如果当前没有新消息，则与所述客户端保持长链接直到产生新消息；在预设周期内，再次接收所述客户端用于拉取消息数据的网络请求；基于与所述第一角色用户的所述消息通信指令、长连接消息数据处理策略以及所述聊天室中的所述第一角色用户，向所述客户端下发所述消息数据，和/或接收消息数据。
具体实施时，通过longpolling机制，当客户端主动向服务端发出请求时，能够拉取相关数据。当客户端发起Long Polling请求，此时如果服务端没有相关数据，会hold住请求，直到服务端有相关数据，或者等待一定时间超时才会返回。返回后客户端又会立即再次发起下一次Long Polling。基于长轮询机制，如果在服务器端当前没有新消息，则与所述客户端保持长链接直到产生新消息；在预设周期内，服务器端再次接收所述客户端用于拉取消息数据的网络请求；基于与所述第一角色用户的所述消息通信指令、长连接消息数据处理策略以及所述聊天室中的所述第一角色用户，通过所述服务器端向所述客户端下发所述消息数据，和/或接收消息数据。
作为本实施例中的优选，所述基于所述消息通信指令、预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：当所述聊天室中在线状态时的实时消息发生异常的情况下，通过异步线程任务向客户端下发消息数据；基于所述异常的消息通信指令、NoCache消息数据处理策略以及所述聊天室中不同角色的用户，至少向所述客户端下发一次所述消息数据，和/或接收消息数据。
具体实施时，NoCache即无状态cache。无状态cache可以实现包括但不限于通过实时通知：发送消息后写入列表，向消息服务器集群发送通知。异步拉取：消息服务器收到消息通知后，触发异步线程拉取。兜底轮询：当消息服务器接收到聊天室请求，触发轮询以保证该聊天室1秒内至少访问过一次消息列表。无锁读取：通过读写表分离和原子切换，做到无锁读取。达到消息能够顺利的被各个客户端读取到消息。
当所述聊天室中在线状态时的实时消息发生异常的情况下，服务器端通过异步线程任务向客户端下发消息数据，同时通过异步线程任务向客户端下发消息数据；基于所述异常的消息通信指令、NoCache消息数据处理策略以及所述聊天室中不同角色的用户，至少向所述客户端下发一次所述消息数据。
作为本实施例中的优选，所述基于所述消息通信指令、预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：基于所述消息通信指令对消息进行标记，用以在客户端获取消息数据时区分不同的消息列表；根据所述消息列表中的预设消息优先级消息数据处理策略，向所述聊天室中不同角色的用户的客户端下发所述消息数据，和/或接收消息数据。
具体实施时，采用消息列表分级设计，在消息爆炸的情况下，消息服务器列表只会保存大概至多1000条消息，存在可能消息还未被接收可能就被覆盖或淘汰。通过对消息进行打标记，再拉消息时分为普通与重要列表，优先接收重要消息，再接收普通消息，这样避免消息丢失的情况发生。
服务器端基于所述消息通信指令对消息进行标记，用以在客户端获取消息数据时区分不同的消息列表；根据所述消息列表中的预设消息优先级消息数据处理策略，向所述聊天室中不同角色的用户的客户端下发所述消息数据，和/或接收消息数据。
作为本实施例中的优选，所述基于所述消息通信指令、预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：基于所述消息通信指令对消息进行去重统计，用以在客户端获取消息数据时提前进行去重；根据预设去重消息数据处理策略，向所述聊天室中不同角色的用户的客户端下发去重后的所述消息数据，和/或接收消息数据。
具体实施时，预设去重消息数据处理策略基于hyperloglog统计方法，使用概率算法来统计集合的近似基数，即算法的最本源则是伯努利过程。
服务器端基于所述消息通信指令对消息进行去重统计，用以在客户端获取消息数据时提前进行去重服务器端；根据预设去重消息数据处理策略，向所述聊天室中不同角色的用户的客户端下发去重后的所述消息数据，和/或接收消息数据。
作为本实施例中的优选，所述基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：通过所述聊天室中的应用场景，确定所述消息通信指令中的交易指令，其中所述应用场景包括拍卖业务；基于所述在线用户人数，确定对应的所述预设消息数据处理策略；基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，向参与拍卖业务的所述客户端下发和/或接收消息数据，其中所述在线用户人数的预设消息数据处理策略至少包括如下之一：读扩散机制、longpolling策略、NoCache策略、消息列表分级策略、基于hyperloglog统计策略、隔离VIP消息服务器策略。
具体实施时，通过所述聊天室中的应用场景，确定所述消息通信指令中的交易指令，其中所述应用场景包括拍卖业务。
基于上述业务场景，根据聊天室特性达到我们需要支持高在线人数目标，采用读扩散机制是比较好的一个合理方式。并且采用其他合理的机制措施，组合成一个合理有效的技术架构方案，其中需要包含读扩散机制、longpolling机制、NoCache设计、消息列表分级、基于hyperloglog统计方法、隔离VIP消息服务器。
需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
根据本申请实施例，还提供了一种用于实施上述方法的用于聊天室的数据处理装置，如图3所示，该装置包括：
确定模块301，用于确定所述聊天室中当前在线用户人数；
响应模块302，用于响应于当前发起网络请求的所述用户的消息通信指令；
消息处理模块303，用于基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据
本申请实施例中的所述确定模块301中服务器端需要统计当前所述聊天室中当前在线用户人数，对于不同量级的在线用户人数，服务器端可以采用相应的方式对消息数据进行处理。
作为一种可选的实施方式，在服务器端可以统计基于历史在线用户人数。
作为一种优选的实施方式，在服务器端可以预先预计在线用户人数。
本申请实施例中的所述响应模块302中在服务器端响应于当前发起网络请求的所述用户的消息通信指令。当用户端需要用通过聊天室进行聊天时会发送相应的通信指令。当用户端有聊天信息数据发送需求时，都是相应地发送通信指令。
作为一种可选的实施方式，所述通信指令携带有用户ID。
作为一种优选的实施方式，所述通信指令包括但不限于：基于不同场景下的聊天信息数据。
本申请实施例中的所述消息处理模块303中基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，在服务器端实现下发和/或接收消息数据。在所述服务器端响应于所述消息通信指令，同时在搜书服务器端结合所述在线用户人数的预设消息数据处理策略和所述聊天室中不同角色的用户，向不同角色的用户下发消息数据。并且，同时，接收不同角色的用户通过消息通信指令发送的消息数据。
作为一种可选的实施方式，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的。所述用户通过所述聊天室进行交互的场景可以是，不用角色的用户对商品的拍卖行为，比如包括拍卖师、客户、买家等用户，这些用户可以通过所述聊天室进行聊天并进行拍卖。
作为一种优选的实施方式，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据。每个用户都可以通过所述用户端进入到所述聊天室。此外，需要注意的是，预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据。当有新消息产生，用户端的用户可以拉取消息数据。
显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。
为了更好的理解上述基于聊天室的数据处理方法流程，以下结合优选实施例对上述技术方案进行解释说明，但不用于限定本发明实施例的技术方案。
本申请实施例中的基于聊天室的数据处理方法采用确定所述聊天室中当前在线用户人数的方式，通过响应于当前发起网络请求的所述用户的消息通信指令，达到了基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据的目的，从而实现了基于聊天室的消息数据高稳定性以及实时性，
如图4所示，是本申请实施例中基于聊天室的数据处理方法的流程示意，实现的具体过程包括如下步骤：
步骤S401，按照业务访问流量预估结果，将所述聊天室划分至少包括第一聊天室以及第二聊天室。
步骤S402，根据所述第一聊天室以及第二聊天室以及不同预设消息隔离通道，得到第一聊天室消息通道以及第二聊天室消息通道。
步骤S403，通过所述第一聊天室消息通道下发第一消息数据，其中所述第一消息数据用于通过指定的所述第一聊天室消息通道下发。
步骤S404，通过所述第二聊天室消息通道下发第二消息数据，其中所述第一消息数据用于通过所述第二聊天室消息通道或者第三聊天室消息通道下发。
所述第一聊天室消息通道即作为隔离VIP消息服务器，比如热门聊天室与普通聊天室服务器的分割，应对所占资源的不同，以及出现问题的影响，进行从硬件服务器，流量请求进行隔离。比如，通过业务运营预判，将热门拍卖设置为VIP消息服务器，其他就走不通消息服务器，降低系统对于服务器的压力。所述第二聊天室消息通道或第三聊天室消息通道作为普通消息通道。
优选地，隔离VIP消息服务器人为的将热门与普通拍卖聊天室进行物理服务器的分离，异常发生时可以有效预防热门与普通的拍卖聊天室服务器的互相影响。
步骤S405，通过所述第二聊天室消息通道接收在所述第二聊天室和/或第三聊天室的消息数据。
步骤S406，判断是否通过所述第一聊天室消息通道下发第一消息数据。
步骤S407，通过所述第一聊天室消息通道接收在所述第一聊天室中的消息数据。
具体实施时，如果发生海量直播间会带来爆发式的请求量，故不能让海量直播间引起的失败影响占大多数的小直播间。具体实施时，通过所述第一聊天室消息通道接收在所述第一聊天室中的消息数据；通过所述第二聊天室消息通道下发第二消息数据，其中所述第一消息数据用于通过所述第二聊天室消息通道或者第三聊天室消息通道下之后，包括：通过所述第二聊天室消息通道接收在所述第二聊天室和/或第三聊天室的消息数据。
步骤S408，通过所述第二聊天室消息通道接收在所述第二聊天室和/或第三聊天室的消息数据。
服务器端需要统计当前所述聊天室中当前在线用户人数，对于不同量级的在线用户人数，服务器端可以采用相应的方式对消息数据进行处理。
步骤S409，通过所述第二聊天室消息通道接收在所述第二聊天室和/或第三聊天室的消息数据。
在服务器端响应于当前发起网络请求的所述用户的消息通信指令。当用户端需要用通过聊天室进行聊天时会发送相应的通信指令。当用户端有聊天信息数据发送需求时，都是相应地发送通信指令。
步骤S410，通过所述第二聊天室消息通道接收在所述第二聊天室和/或第三聊天室的消息数据。
基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，在服务器端实现下发和/或接收消息数据。在所述服务器端响应于所述消息通信指令，同时在搜书服务器端结合所述在线用户人数的预设消息数据处理策略和所述聊天室中不同角色的用户，向不同角色的用户下发消息数据。并且，同时，接收不同角色的用户通过消息通信指令发送的消息数据。
作为一种可选的实施方式，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的。所述用户通过所述聊天室进行交互的场景可以是，不用角色的用户对商品的拍卖行为，比如包括拍卖师、客户、买家等用户，这些用户可以通过所述聊天室进行聊天并进行拍卖。
作为一种优选的实施方式，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据。每个用户都可以通过所述用户端进入到所述聊天室。此外，需要注意的是，预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据。当有新消息产生，用户端的用户可以拉取消息数据。
通过所述聊天室中的应用场景，确定所述消息通信指令中的交易指令，其中所述应用场景包括拍卖业务。
基于上述业务场景，根据聊天室特性达到需要支持高在线人数目标，采用读扩散机制是比较好的一个合理方式。并且采用其他合理的机制措施，组合成一个合理有效的技术架构方案，其中需要包含读扩散机制、longpolling机制、NoCache设计、消息列表分级、基于hyperloglog统计方法、隔离VIP消息服务器。读扩散机制写入数据非常方便以及数据存储比较少量。
采用longpolling机制，通过客户端去拉取消息，减少服务端的压力，达到再高在线人数时，消息的不丢失。
采用NoCache设计采用异步消息扩散且在如有异常情况下会采用兜底措施进行消息至少被拉取一次。
采用hyperloglog基于概率的统计方法，尽量降低代价的去重数据，从时间和空间角度减少代价。
采用通过消息列表分级设计把重要消息与普通消息进行隔离。
以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
Claims (10)
1.一种基于聊天室的数据处理方法，其特征在于，包括：
确定所述聊天室中当前在线用户人数；
响应于当前发起网络请求的所述用户的消息通信指令；
基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据。
2.根据权利要求1所述的方法，其特征在于，还包括：
按照业务访问流量预估结果，将所述聊天室划分至少包括第一聊天室以及第二聊天室；
根据所述第一聊天室以及第二聊天室以及不同预设消息隔离通道，得到第一聊天室消息通道以及第二聊天室消息通道；
通过所述第一聊天室消息通道下发第一消息数据，其中所述第一消息数据用于通过指定的所述第一聊天室消息通道下发；
通过所述第二聊天室消息通道下发第二消息数据，其中所述第一消息数据用于通过所述第二聊天室消息通道或者第三聊天室消息通道下发。
3.根据权利要求2所述的方法，其特征在于；
通过所述第一聊天室消息通道下发第一消息数据，其中所述第一消息数据用于通过指定的所述第一聊天室消息通道下发之后，包括：
通过所述第一聊天室消息通道接收在所述第一聊天室中的消息数据；
通过所述第二聊天室消息通道下发第二消息数据，其中所述第一消息数据用于通过所述第二聊天室消息通道或者第三聊天室消息通道下之后，包括：
通过所述第二聊天室消息通道接收在所述第二聊天室和/或第三聊天室的消息数据。
4.根据权利要求1所述的方法，其特征在于，所述响应于当前发起网络请求的所述用户的消息通信指令，还包括：
所述聊天室中不同角色的用户包括：第一角色用户，所述第一角色用户用于促成所述聊天室中的交易；
接收所述第一角色用户写入的新消息，并存储消息数据；
基于对所述第一角色用户的订阅用户，响应于当前发起网络请求的所述订阅用户的消息通信指令，将所述消息数据下发。
5.根据权利要求4所述的方法，其特征在于，所述基于所述消息通信指令、预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：
接收客户端用于拉取消息数据的网络请求；
基于长轮询机制，如果当前没有新消息，则与所述客户端保持长链接直到产生新消息；
在预设周期内，再次接收所述客户端用于拉取消息数据的网络请求；
基于与所述第一角色用户的所述消息通信指令、长连接消息数据处理策略以及所述聊天室中的所述第一角色用户，向所述客户端下发所述消息数据，和/或接收消息数据。
6.根据权利要求1所述的方法，其特征在于，所述基于所述消息通信指令、预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：
当所述聊天室中在线状态时的实时消息发生异常的情况下，通过异步线程任务向客户端下发消息数据；
基于所述异常的消息通信指令、NoCache消息数据处理策略以及所述聊天室中不同角色的用户，至少向所述客户端下发一次所述消息数据，和/或接收消息数据。
7.根据权利要求1所述的方法，其特征在于，所述基于所述消息通信指令、预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：
基于所述消息通信指令对消息进行标记，用以在客户端获取消息数据时区分不同的消息列表；
根据所述消息列表中的预设消息优先级消息数据处理策略，向所述聊天室中不同角色的用户的客户端下发所述消息数据，和/或接收消息数据。
8.根据权利要求1所述的方法，其特征在于，所述基于所述消息通信指令、预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：
基于所述消息通信指令对消息进行去重统计，用以在客户端获取消息数据时提前进行去重；
根据预设去重消息数据处理策略，向所述聊天室中不同角色的用户的客户端下发去重后的所述消息数据，和/或接收消息数据。
9.根据权利要求1所述的方法，其特征在于，所述基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据包括：
通过所述聊天室中的应用场景，确定所述消息通信指令中的交易指令，其中所述应用场景包括拍卖业务；
基于所述在线用户人数，确定对应的所述预设消息数据处理策略；
基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，向参与拍卖业务的所述客户端下发和/或接收消息数据，其中所述在线用户人数的预设消息数据处理策略至少包括如下之一：读扩散机制、longpolling策略、NoCache策略、消息列表分级策略、基于hyperloglog统计策略、隔离VIP消息服务器策略。
10.一种用于聊天室的数据处理装置，其特征在于，包括：
确定模块，用于确定所述聊天室中当前在线用户人数；
响应模块，用于响应于当前发起网络请求的所述用户的消息通信指令；
消息处理模块，用于基于所述消息通信指令、所述在线用户人数的预设消息数据处理策略以及所述聊天室中不同角色的用户，下发和/或接收消息数据，所述消息数据为所述不同聊天角色的用户通过所述聊天室交互时产生的，每个所述用户通过用户端进入所述聊天室，所述预设消息数据处理策略用于在有新消息的情况下从所述不同角色的用户获取消息数据。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111137132.5A CN113965810B (zh) | 2021-09-27 | 2021-09-27 | 基于聊天室的数据处理方法以及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111137132.5A CN113965810B (zh) | 2021-09-27 | 2021-09-27 | 基于聊天室的数据处理方法以及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113965810A true CN113965810A (zh) | 2022-01-21 |
| CN113965810B CN113965810B (zh) | 2024-10-22 |
Family
ID=79462302
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111137132.5A Active CN113965810B (zh) | 2021-09-27 | 2021-09-27 | 基于聊天室的数据处理方法以及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113965810B (zh) |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007016851A1 (fr) * | 2005-08-10 | 2007-02-15 | Huawei Technologies Co., Ltd. | Procede etablissant un canal de transmission de donnees pour dialogue en ligne afin de realiser la transmission du message |
| US20140149522A1 (en) * | 2012-11-27 | 2014-05-29 | Nhn Corporation | System and method for online fan meeting |
| CN107038631A (zh) * | 2017-04-21 | 2017-08-11 | 山东佳联电子商务有限公司 | 一种点拍网的智能拍卖方法 |
| CN107222316A (zh) * | 2017-05-25 | 2017-09-29 | 游密科技(深圳)有限公司 | 一种自适应房间人数的聊天室配置方法及聊天室系统 |
| CN107707404A (zh) * | 2017-10-19 | 2018-02-16 | 福建中金在线信息科技有限公司 | 网站在线人数统计方法、装置和网站服务器 |
| CN108173917A (zh) * | 2017-12-22 | 2018-06-15 | 杭州顺网珑腾信息技术有限公司 | 一种分布式无上限的网络聊天室消息转发系统 |
| CN109361932A (zh) * | 2018-11-23 | 2019-02-19 | 武汉斗鱼网络科技有限公司 | 直播热度预测的方法，装置，设备及介质 |
| CN109831417A (zh) * | 2018-12-28 | 2019-05-31 | 广州华多网络科技有限公司 | 防骚扰处理帐号的方法、装置、服务器及存储介质 |
| CN111277848A (zh) * | 2020-01-22 | 2020-06-12 | 北京字节跳动网络技术有限公司 | 直播间互动消息的处理方法、装置、电子设备及存储介质 |
| CN111414516A (zh) * | 2020-03-17 | 2020-07-14 | 北京字节跳动网络技术有限公司 | 一种直播间消息处理方法、装置、电子设备及存储介质 |
-
2021
- 2021-09-27 CN CN202111137132.5A patent/CN113965810B/zh active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007016851A1 (fr) * | 2005-08-10 | 2007-02-15 | Huawei Technologies Co., Ltd. | Procede etablissant un canal de transmission de donnees pour dialogue en ligne afin de realiser la transmission du message |
| US20140149522A1 (en) * | 2012-11-27 | 2014-05-29 | Nhn Corporation | System and method for online fan meeting |
| CN107038631A (zh) * | 2017-04-21 | 2017-08-11 | 山东佳联电子商务有限公司 | 一种点拍网的智能拍卖方法 |
| CN107222316A (zh) * | 2017-05-25 | 2017-09-29 | 游密科技(深圳)有限公司 | 一种自适应房间人数的聊天室配置方法及聊天室系统 |
| CN107707404A (zh) * | 2017-10-19 | 2018-02-16 | 福建中金在线信息科技有限公司 | 网站在线人数统计方法、装置和网站服务器 |
| CN108173917A (zh) * | 2017-12-22 | 2018-06-15 | 杭州顺网珑腾信息技术有限公司 | 一种分布式无上限的网络聊天室消息转发系统 |
| CN109361932A (zh) * | 2018-11-23 | 2019-02-19 | 武汉斗鱼网络科技有限公司 | 直播热度预测的方法，装置，设备及介质 |
| CN109831417A (zh) * | 2018-12-28 | 2019-05-31 | 广州华多网络科技有限公司 | 防骚扰处理帐号的方法、装置、服务器及存储介质 |
| CN111277848A (zh) * | 2020-01-22 | 2020-06-12 | 北京字节跳动网络技术有限公司 | 直播间互动消息的处理方法、装置、电子设备及存储介质 |
| CN111414516A (zh) * | 2020-03-17 | 2020-07-14 | 北京字节跳动网络技术有限公司 | 一种直播间消息处理方法、装置、电子设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113965810B (zh) | 2024-10-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10817195B2 (en) | Key-value based message oriented middleware | |
| US10701012B2 (en) | Method, apparatus and system for customer service information forwarding | |
| CN111555963B (zh) | 消息推送方法、装置、电子设备及存储介质 | |
| CN115004673B (zh) | 消息推送方法、装置、电子设备及计算机可读介质 | |
| US20140328478A1 (en) | Method and system for identifying prank call, client, server, and storage medium | |
| CN109547807B (zh) | 一种基于直播的信息处理方法、装置及服务器 | |
| CN110719221B (zh) | 即时通信方法、装置、设备及存储介质 | |
| CN111277483B (zh) | 一种多端消息的同步方法、服务器及可存储介质 | |
| CN113391979A (zh) | 监控数据展示的处理方法、设备、系统及存储介质 | |
| CN113055461B (zh) | 一种基于ZooKeeper的无人集群分布式协同指挥控制方法 | |
| CN112995266A (zh) | 一种信息推送方法及相关设备 | |
| CN108063832B (zh) | 一种云存储系统及其存储方法 | |
| CN114338769A (zh) | 访问请求的处理方法及装置 | |
| CN110839061B (zh) | 数据分发方法、装置及存储介质 | |
| CN112632093A (zh) | 工单处理方法、设备、系统、存储介质及程序产品 | |
| CN111797352A (zh) | 封禁帐号的方法、装置及封禁系统 | |
| CN113965810A (zh) | 基于聊天室的数据处理方法以及装置 | |
| CN106789568A (zh) | 一种通讯信息获取方法及装置 | |
| CN107730380B (zh) | 联名账户处理方法、系统及服务器 | |
| CN106533891A (zh) | 一种基于群组的信息处理方法及装置 | |
| CN107729359A (zh) | 统计投票数据的方法及装置 | |
| CN113472892A (zh) | 一种消息未读与已读的状态多终端同步方法及系统 | |
| CN114205320A (zh) | 消息显示方法和装置、电子设备及存储介质 | |
| CN115373831A (zh) | 数据处理方法、装置以及计算机可读存储介质 | |
| EP2194679B1 (en) | A method and system for managing the user information in the instant messaging system |
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 |