CN117560416A - 消息处理方法、装置、设备、存储介质及程序产品 - Google Patents

消息处理方法、装置、设备、存储介质及程序产品 Download PDF

Info

Publication number
CN117560416A
CN117560416A CN202311500157.6A CN202311500157A CN117560416A CN 117560416 A CN117560416 A CN 117560416A CN 202311500157 A CN202311500157 A CN 202311500157A CN 117560416 A CN117560416 A CN 117560416A
Authority
CN
China
Prior art keywords
message
pushed
client
database
logged
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
Application number
CN202311500157.6A
Other languages
English (en)
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.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen 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 Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202311500157.6A priority Critical patent/CN117560416A/zh
Publication of CN117560416A publication Critical patent/CN117560416A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2255—Hash tables
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1859—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast adapted to provide push services, e.g. data channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请提供了一种消息处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品；方法包括：将待推送消息基于读扩散机制写入数据库；基于无感知广播机制获取当前处于在线状态的第一对象；基于所述无感知广播机制从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息；针对处于离线状态的第二对象，响应于所述第二对象从所述离线状态切换至在线状态，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息。通过本申请，能够节约资源占用的同时解决在线场景以及离线场景下的客户端兼容性问题。

Description

消息处理方法、装置、设备、存储介质及程序产品
技术领域
本申请涉及消息收发技术，尤其涉及一种消息处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品。
背景技术
相关技术中许多应用服务提供商均会配置有消息系统，消息系统支持好友、群聊、陌生人、系统消息、运营消息。通常应用服务提供商有为全量用户推送消息的需求，但是由于全量用户的数量巨大，面向全量用户的全量消息推送系统会对服务器造成过大的压力。
发明内容
本申请实施例提供一种消息处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品，能够节约资源占用的同时解决在线场景以及离线场景下的客户端兼容性问题。
本申请实施例的技术方案是这样实现的：
本申请实施例提供一种消息处理方法，包括：
将待推送消息基于读扩散机制写入数据库；
基于无感知广播机制获取当前处于在线状态的第一对象；
基于所述无感知广播机制从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息；
针对处于离线状态的第二对象，响应于所述第二对象从所述离线状态切换至在线状态，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息。
本申请实施例提供一种消息处理装置，包括：
写入模块，用于将待推送消息基于读扩散机制写入数据库；
获取模块，用于基于无感知广播机制获取当前处于在线状态的第一对象；
在线推送模块，用于基于所述无感知广播机制从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息；
离线推送模块，用于针对处于离线状态的第二对象，响应于所述第二对象从所述离线状态切换至在线状态，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息。
本申请实施例提供一种消息处理方法，所述方法包括：
在目标对象登录的客户端上显示待推送消息；
其中，所述目标对象是从离线状态切换至在线状态的第二对象，或者所述目标对象是保持所述在线状态的第一对象，所述待推送消息是通过本申请实施例提供的消息处理方法推送至所述客户端的。
本申请实施例提供一种消息处理装置，所述装置包括：
显示模块，用于在目标对象登录的客户端上显示待推送消息；
其中，所述目标对象是从离线状态切换至在线状态的第二对象，或者所述目标对象是保持所述在线状态的第一对象，所述待推送消息是通过本申请实施例提供的消息处理方法推送至所述客户端的。
本申请实施例提供一种电子设备，包括：
存储器，用于存储计算机可执行指令；
处理器，用于执行所述存储器中存储的计算机可执行指令时，实现本申请实施例提供的消息处理方法。
本申请实施例提供一种计算机可读存储介质，存储有计算机可执行指令，用于引起处理器执行时，实现本申请实施例提供的消息处理方法。
本申请实施例提供一种计算机程序产品，包括计算机可执行指令，所述计算机可执行指令被处理器执行时，实现本申请实施例提供的消息处理方法。
本申请实施例具有以下有益效果：
通过本申请实施例将待推送消息基于读扩散机制写入数据库，读扩散机制写入数据库可以节约数据写入成本，基于无感知广播机制获取当前处于在线状态的第一对象，可以自动检测在线第一对象，基于所述无感知广播机制从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息，确保即使用户保持在线也能及时接收到待推送消息；针对处于离线状态的第二对象，响应于所述第二对象从所述离线状态切换至在线状态，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息，相当于使用条件推送策略，能够适配不同客户端环境，不需要额外的兼容性处理。
附图说明
图1是本申请实施例提供的消息处理系统的结构示意图；
图2是本申请实施例提供的电子设备的结构示意图；
图3A-图3C是本申请实施例提供的消息处理方法的流程示意图；
图4A-图4B是本申请实施例提供的消息处理方法的界面示意图；
图5是本申请实施例提供的消息处理方法的扩散机制示意图；
图6是本申请实施例提供的消息处理方法的广播机制示意图；
图7是本申请实施例提供的消息处理方法的整体框架示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。
1)全量推送：指一次向所有用户或一组用户发送消息，而不是仅针对某一用户发送消息。
2)读扩散：群里每条消息只存储一份，群成员共同读取同一份数据。
3)写扩散：真毒每个目标用户写入一份消息，消息在发送时立即推送给所有目标用户。
4)条件推送：只有在满足特定条件(如用户登录)时，才进行消息推送。
5)兼容性问题：指的是由于软件版本或操作系统差异导致的功能或显示问题。
6)在线用户与离线用户：在线用户是当前与服务器保持连接的用户，而离线用户是没有与服务器保持连接的用户。
7)分桶：在数据库存储方面，将数据划分为更小且更易于管理的部分。
8)数据库分片：将数据库划分为更小的分片，来提高数据库操作的效率。
9)缓冲区：临时存储数据的区域，用于缓解数据传输速率的不匹配。
10)限频机制：控制数据访问或操作频率的机制。
在不同操作系统的社区应用软件中，全量推送是常见用户需求，目前主要有以下几种推送方案：1)即时通信写扩散方案、2)单一版本的消息推送方案、3)轮询机制。在1)即时通信写扩散方案中，服务端会针对所有客户端分别写入消息并发送即时消息。这种方案在小规模系统中运作得相当好，但当面对大规模系统时，它会消耗大量的网络带宽和服务器资源。另外，由于必须立即发送消息，这种方案常常会遇到网络延迟和数据包丢失的问题。在2)单一版本的消息推送方案中，基于单一应用版本进行推送，每当有全量消息需要推送时，服务端会根据客户端的版本号发送相应的消息，它不解决多版本和多平台的兼容性问题。每当应用更新时，都需要重新配置和测试推送系统。在3)轮询机制方案中，客户端会定期向服务器发送请求，以检查是否有新的全量推送消息。它会增加服务器的负载，并可能导致不必要的网络流量。此外，如果用户一直在线，但在较长的时间段内没有进行轮询，他们可能会错过重要的全量推送消息。
本申请实施例提供一种消息处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品，能够节约资源占用的同时解决在线场景以及离线场景下的客户端兼容性问题。
下面说明本申请实施例提供的电子设备的示例性应用，本申请实施例提供的电子设备可以实施为终端或服务器。
参考图1，图1是本申请实施例提供的消息处理方法的应用模式示意图；示例的，图1中涉及服务器200、网络300及终端400-1以及终端400-2。终端400-1以及终端400-2通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合。
在一些实施例中，服务器200可以是应用程序对应的服务器，例如：应用程序是安装在终端400-1以及终端400-2中的游戏软件，则服务器200是游戏服务器。
在一些实施例中，服务器200接收到最新生成的待推送消息时，将待推送消息写入数据库500，服务器200基于无感知广播机制获取当前处于在线状态的第一对象；基于所述无感知广播机制从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息，即在第一对象使用的终端400-1上显示待推送消息，第二对象尚未登录客户端，当终端400-2接收到第二对象的登录请求时，终端400-2将登录请求发送到服务器200，服务器200响应第二对象的登录请求，从数据库中查询待推送消息并向第二对象登录的客户端发送所述待推送消息，即在终端400-2上显示待推送消息。
在一些实施例中，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、智能电视、车载终端等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例中不做限制。数据库500可以集成在服务器200上，或者数据库500可以设置在独立于服务器200的机器上，本申请实施例不做限制。
在一些实施例中，终端400可以通过运行计算机程序来实现本申请实施例提供的消息处理方法，例如，计算机程序可以是操作系统中的原生程序或软件模块；可以是本地(Native)应用程序(APP，Application)，即需要在操作系统中安装才能运行的程序，例如视频APP；也可以是小程序，即只需要下载到浏览器环境中就可以运行的程序；还可以是能够嵌入至任意APP中的小程序。总而言之，上述计算机程序可以是任意形式的应用程序、模块或插件。
参见图2，图2是本申请实施例提供的电子设备的结构示意图，电子设备为终端或者服务器，以电子设备是服务器为例进行说明，图2所示的服务器包括：至少一个处理器210、存储器250、至少一个网络接口220和用户接口230。终端400中的各个组件通过总线系统240耦合在一起。可理解，总线系统240用于实现这些组件之间的连接通信。总线系统240除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统240。
处理器210可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。
用户接口230包括使得能够呈现媒体内容的一个或多个输出装置231，可以包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口230还包括一个或多个输入装置232，可以包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。
存储器250可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器250可选地包括在物理位置上远离处理器210的一个或多个存储设备。
存储器250包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Me mory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memor y)。本申请实施例描述的存储器250旨在包括任意适合类型的存储器。
在一些实施例中，存储器250能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。
操作系统251，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；
网络通信模块252，用于经由一个或多个(有线或无线)网络接口220到达其他电子设备，示例性的网络接口220包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；
呈现模块253，用于经由一个或多个与用户接口230相关联的输出装置231(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；
输入处理模块254，用于对一个或多个来自一个或多个输入装置232之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。
在一些实施例中，本申请实施例提供的消息处理装置可以采用软件方式实现，图2示出了存储在存储器250中的消息处理装置255，其可以是程序和插件等形式的软件，包括以下软件模块：写入模块2551、获取模块2552、在线推送模块2553，离线推送模块2554，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
下面，说明本申请实施例提供的消息处理方法，如前，实现本申请实施例的消息处理方法的电子设备可以是服务器，因此下文中不再重复说明各个步骤的执行主体。参见图3A，图3A是本申请实施例提供的消息处理方法的流程示意图，结合图3A示出的步骤101至步骤104进行说明。
在步骤101中，将待推送消息基于读扩散机制写入数据库。
作为示例，待推送消息可以是订阅号中需要推送给所有订阅用户的消息，这里的待推送消息也可以是需要推送给整个群组的消息，或者这里的待推送消息可以是游戏客户端中的服务号需要推送所有游戏用户的消息。在服务号客户端接收到编辑输入的待推送消息时，服务号客户端将待推送消息发送至通信服务器，通信服务器将待推送消息基于读扩散机制写入数据库。
在一些实施例中，参见图3B，步骤101中将待全量推送消息基于读扩散机制写入数据库，可以通过图3B示出的步骤1011至步骤1013实现。
在步骤1011中，对所述目标对象进行分桶处理，得到对应所述目标对象的桶标识，其中，所述目标对象是第一对象或者第二对象；
在一些实施例中，步骤1011中对所述目标对象进行分桶处理，得到对应所述目标对象的桶标识，可以通过以下技术方案实现：获取所述目标对象的固定标识；对所述固定标识进行哈希处理，得到对应所述目标对象的桶标识。
作为示例，在全量推送消息生成后，首先进行分桶处理以减少数据库压力和提高查询速度，分桶策略基于用户ID的哈希值进行，对应的伪代码如下：
def get_bucket_id(user_id，num_buckets)://定义获取桶标识的方法
hash_value＝hash(user_id)//对用户id进行哈希处理得到哈希值
bucket_id＝hash_value％num_buckets//对哈希值以及总桶数进行取余数得到桶标识
return bucket_id//返回桶标识
在步骤1012中，确定所述数据库中与所述桶标识对应的目标数据库分片；
在步骤1013中，将所述待全量推送消息写入所述目标数据库分片。
当有新的全量推送消息生成时，首先系统通过某种策略(如按用户ID或其他标识)将消息分桶。根据分桶结果，将消息写入对应的数据库分片集群，在消息写入数据库后，系统会将该消息的元信息(如消息ID，时间戳等)写入Redis缓存，用以记录最近的全量消息刷新时间。
通过这样的消息写入流程、分桶策略、数据库分片策略，本申请实施例有效地解决全量推送消息在高并发大数据量场景下的性能和可扩展性问题。
在步骤102中，基于无感知广播机制获取当前处于在线状态的第一对象。
在一些实施例中，步骤103中从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息是通过通信服务器实现的；步骤102中基于无感知广播机制，获取当前处于在线状态的第一对象，可以通过以下技术方案实现：向多个接入层服务器发送第一广播信令，以使每个所述接入层服务器对各自关联的客户端进行遍历处理，得到处于所述在线状态的第一对象的客户端，并将承载有所述第一对象的对象标识的消息返回至所述通信服务器。
作为示例，参见图6，通信服务器chatsvr收到全量推送请求，通信服务器chatsvr生成第一广播信令，广播给所有的接入层服务器connsvr，接入层服务器connsvr中记载有各自关联的客户端是否在线，从而可以通过遍历的方式得到各自关联的处于在线状态的所有第一对象的客户端，然后生成应答消息，在应答消息中记载有在线状态的第一对象的标识，将应答消息发送至通信服务器chat svr之后，通信服务器chatsvr可以知晓所有的在线用户，且这个过程对于用户而言是无感知的。
在步骤103中，基于所述无感知广播机制从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息。
在一些实施例中，步骤103中从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息，可以通过以下技术方案实现：向多个接入层发送第二广播信令，以使每个所述接入层服务器对各自关联的处于所述在线状态的第一对象登录的客户端进行消息接收情况遍历处理，得到处于所述在线状态的第一对象登录的客户端的消息接收情况；当所述消息接收情况表征所述第一对象未接收到所述待推送消息时，从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息。
作为示例，参见图6，通信服务器chatsvr生成第二广播信令，广播给所有的接入层服务器connsvr，接入层服务器connsvr中记载有各自关联的客户端是否有接收过这条待推送消息(消息接收情况)，然后生成应答消息，在应答消息中记载有未接收过这条待推送消息的第一对象，将应答消息发送至通信服务器chatsvr之后，通信服务器chatsvr可以知晓所有的在线用户中未接收过这条待推送消息的第一对象，且这个过程对于用户而言是无感知的。
在一些实施例中，上述每个所述接入层服务器对各自关联的处于所述在线状态的第一对象登录的客户端进行消息接收情况遍历处理，得到处于所述在线状态的第一对象登录的客户端的消息接收情况，可以通过以下技术方案实现：每个所述接入层服务器执行以下处理：所述接入层针对各自关联的处于所述在线状态的第一对象登录的客户端以第一查询频次进行消息接收情况遍历处理，得到处于所述在线状态的第一对象登录的客户端的消息接收情况，其中，所述第一查询频次低于查询频次阈值；当针对任一第一对象登录的客户端进行消息接收情况遍历处理时的第一查询频次超过查询频次阈值时，将所述任一第一对象的对象标识存储于缓冲区；当进入下一个查询频次限制周期时，从所述缓冲区中提取所述任一第一对象的对象标识，并继续对所述任一第一对象登录的客户端进行消息接收情况遍历处理，得到所述任一第一对象登录的客户端的消息接收情况。
作为示例，通信服务器将全量推送消息写入到数据库MongoDB，通信服务器广播消息至每一个接入服务器，接入服务器开始遍历所有在线用户，查询其未读的全量推送消息，对应的伪代码如下：
如果接入层服务器遍历在线用户的速度超过了设定的限频，该用户ID将被放入缓冲区，以便稍后继续处理，限频(Rate Limiting)指的是设定每秒查询次数的上限，以防止系统过载。查询是限频的，所以当达到限频时，用户ID会先存储在缓冲区中，在下个限频周期，接入层服务器会从缓冲区取出用户ID，并继续查询未读的全量推送消息，以确保没有消息丢失。通过本申请实施例确保在线用户能及时地接收到全量推送消息，同时也有效地管理了系统资源，提高了性能和可靠性。
在步骤104中，针对处于离线状态的第二对象，响应于所述第二对象从所述离线状态切换至在线状态，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息。
在一些实施例中，参见图3C，步骤104中从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息，可以通过图3C示出的步骤1041至步骤1042实现。
在步骤1041中，查询所述第二对象上一次收到推送消息时的刷新时间；
在步骤1042中，基于所述刷新时间、所述第二对象的注册时间以及消息过期时间，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息。
在一些实施例中，步骤1041中查询所述第二对象上一次收到推送消息时的刷新时间，可以通过以下技术方案实现：从缓存中查询所述第二对象上一次收到推送消息时的刷新时间；在从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息之后，在缓存中将查询到所述待推送消息的时间更新为所述第二对象上一次收到推送消息时的刷新时间。
作为示例，用户登录并建立与接入层服务器的连接，接入层服务器通知通信服务器进行用户身份验证和会话建立，通信服务器查询Redis缓存，获取用户上次全量推送消息的刷新时间，使用用户的上次全量推送消息刷新时间、用户注册时间和消息过期时间，通信服务器从数据库MongoDB中拉取用户需要的全量推送消息，对应的伪代码如下：
在一些实施例中，步骤1042中基于所述刷新时间、所述第二对象的注册时间以及消息过期时间，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息，可以通过以下技术方案实现：基于所述刷新时间、所述第二对象的注册时间以及所述消息过期时间确定时间范围；从所述数据库中查询符合所述时间范围的消息作为所述待推送消息，并向所述第二对象登录的客户端发送所述待推送消息。
作为示例，这里的时间范围相当于是查询依据，表征需要查询数据库中对应某个时间范围的待推送消息，这里需要提取晚于注册时间的待推送消息，同时也会过滤掉已经过期的全量推送消息。
在一些实施例中，向所述第二对象登录的客户端发送提示信息，所述提示信息用于提示所述第二对象在对应所述第二对象的收件箱中查询所述待推送消息。
作为示例，在第二对象刚刚登录时，服务器会从数据库中读取待推送消息，并将读取的待推送消息发送至第二对象的收件箱，这个过程是需要花费时间的，因此如果第二对象登录后立即查看收件箱，可能无法查看到待推送消息，因此需要在推送的同时给第二对象发送提示信息，则可以在成功推送之后提醒第二对象再次查看收件箱。通过本申请实施例可以避免用户遗漏待推送消息。
在一些实施例中，在目标对象登录的客户端上显示待推送消息；其中，所述目标对象是从离线状态切换至在线状态的第二对象，或者所述目标对象是保持所述在线状态的第一对象，所述待推送消息是通过本申请实施例提供的消息处理方法推送至所述客户端的。
作为示例，参见图4A-图4B，本申请实施例提供的消息处理方法主要在游戏的消息系统中发挥作用，该消息系统支持好友、群聊、陌生人、系统消息、运营消息等待推送消息，对于保持在线的第二对象以及刚刚登录的第一对象均能够接收到待推送消息。
通过本申请实施例将待推送消息基于读扩散机制写入数据库，读扩散机制写入数据库可以节约数据写入成本，基于无感知广播机制获取当前处于在线状态的第一对象，可以自动检测在线第一对象，基于所述无感知广播机制从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息，确保即使用户保持在线也能及时接收到待推送消息；针对处于离线状态的第二对象，响应于所述第二对象从所述离线状态切换至在线状态，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息，相当于使用条件推送策略，能够适配不同客户端环境，不需要额外的兼容性处理。
下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。
在一些实施例中，服务器接收到最新生成的待推送消息时，将待推送消息写入数据库，服务器基于无感知广播机制获取当前处于在线状态的第一对象；基于所述无感知广播机制从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息，即在第一对象使用的第一终端上显示待推送消息，第二对象尚未登录客户端，当第二终端接收到第二对象的登录请求时，第二终端将登录请求发送到服务器，服务器响应第二对象的登录请求，从数据库中查询待推送消息并向第二对象登录的客户端发送所述待推送消息，即在第二终端上显示待推送消息。
参见图4A-图4B，本申请实施例提供的消息处理方法主要在游戏的消息系统中发挥作用，该消息系统支持好友、群聊、陌生人、系统消息、运营消息。通常官方有为全量用户推送消息的需求，但是由于全量用户的数量巨大，所以需要优化消息的全量推送系统，以免对服务器造成过大的压力。
社交APP可以作为游戏APP的社区软件，它包括两种操作系统的版本，该社交APP的用户量逐渐攀升，达到千万/亿级水平。消息推送是该社交APP的至关重要的功能，用于通知用户新动态、活动或其他信息，然而，当前消息全量推送解决方案面临如下几个关键性的技术挑战。
1、版本和平台多样性：社交APP有多个版本，并且同时运行在不同操作系统上，这种多样性导致兼容性问题。
2、用户在线状态的随机性：在任何给定时刻，社交APP内的用户可能处于在线或离线的不同状态。传统的推送机制可能无法很好地适应这种多样性，从而影响用户体验。
3、性能和可扩展性：随着用户数量的增加，数据中心和数据库在消息全量推送时面临更大的压力。传统的即时通信写扩散方案或者简单的轮询方案在高负载情况下容易出现性能瓶颈。
4、数据库热点问题：在高并发的环境下，大量的请求可能集中在数据库的某个或某几个节点上，从而导致热点问题，进一步降低系统性能。
参见图5，下面首先介绍读扩散机制与写扩散机制的区别，写扩散方案需要在每条消息产生时立即进行大规模的分发，这在用户群体庞大时可能产生性能问题和延迟。相反，读扩散方案仅在用户登录或进行某些活动时触发消息的推送。具体来说，假设社交APP有1亿用户，那么写扩散方案需要在全量消息推送过程中向数据库中写一亿条消息(考虑到收件箱以及消息确认ack消息，差不多应该是2-3倍)，需要写3亿次，假设数据库支持每秒50万的读写能力，考虑到稳定性，最多可以有25万读写可以分配给数据库，考虑到即时通信系统复杂的交互(读多写少)，实际有效写最高可以到3-5万，那么向数据库写完这些消息就需要6000秒，而且这段时间数据库的负载也是非常高的，消息也不具有实时性；选用读扩散方案，则消息只需要写几百条，可以极大降低对数据库的负载压力，消息实时性高，消息按需推送，活跃用户可以及时看到消息，因此，本申请实施例选择读扩散方案，它更适合应对大规模的并发访问。
为解决多版本和多平台带来的兼容性问题，本申请实施例还设计条件推送机制，该机制加入条件判断，以确保只有满足特定条件(如软件版本、平台等)的用户才会收到推送，参见表1，表1示出了条件推送策略的方案对比。考虑到性能与兼容性，本申请实施例选择表1中用户登录时拉取的策略。
针对在线用户的消息推送的情况，传统读扩散方案在处理长时间在线用户时存在不足，因为这些用户不会频繁触发登录事件，从而错过消息推送，另一方面，当前在线状态使用redis存储，kv类型，不支持全量遍历。为解决这一问题，本申请实施例引入对用户无感知的广播触发机制，该机制能够在用户在线时定时或根据某些条件触发全量推送。
参见图6，全量推送时，接入网关(接入服务器)替代客户端的职责，解析该广播信令，然后将接入服务器上的在线用户信息全量发送给通信服务，以实现全量消息推送，本申请实施例采取纯后台逻辑，兼容性好，限频、降级更可控。
考虑到数据中心的压力和数据库热点问题，本申请实施例使用数据库的分片集群以及消息分桶的方式，以保证用户信息能够均匀地分布在不同的数据库节点上。此外，还使用Redis作为缓存层，存储用户的全量消息刷新时间，以减少对数据库的频繁访问。
本申请实施例具体包括以下几个关键点：1、读扩散方案，当用户登录应用时，系统将自动判断该用户是否有新的、未收到的全量推送消息。如果存在这类消息，系统将自动推送给用户。这一方案优于即时通信的写扩散方案，因为它更为高效并能准确地推送到目标用户。2、条件推送，本方案利用了条件推送的机制，这意味着消息的发送是建立在原有的消息推送机制之上的，对客户端来说是透明的。因此，无需额外的兼容性处理。3、在线用户广播触发，为解决一直在线但不重新登录的用户无法收到消息的问题，本方案引入了一种巧妙的、对用户无感知的广播触发机制。该机制能在用户在线时自动推送全量消息。4、性能优化，针对性能问题，本方案使用了MongoDB分片集群和消息分桶的方式。这样可以确保用户数据分散在不同的MongoDB分片和不同的数据桶上，有效地避免了数据库热点问题。同时，通过使用Redis作为缓存，保存用户的全量消息刷新时间，从而减少对MongoDB的频繁访问。通过上述四个关键点，本申请实施例不仅解决全量推送的兼容性和性能问题，还增加推送的准确性和实时性，从而大大提升了用户体验和系统效率。
参见图7，客户端是社交APP，这里区分在线和离线用户，connsvr是社交APP即时通信服务接入层服务，其职责是长连接管理、会话管理、在线状态管理、心跳保活等，chatsvr是即时通信服务核心服务，绝大部分的即时通信逻辑在该服务上，即时通信服务的存储层使用了redis和数据库MongoDB，redis作为缓存可以存储部分时效性要求高的数据；数据库MongoDB则存储消息、会话等数据，pushsvr是推送服务器，用于推送在线和离线消息。
首先介绍消息写入数据库的流程。
当有新的全量推送消息生成时，首先系统通过某种策略(如按用户ID或其他标识)将消息分桶。根据分桶结果，将消息写入对应的数据库分片集群，在消息写入数据库后，系统会将该消息的元信息(如消息ID，时间戳等)写入Redis缓存，用以记录最近的全量消息刷新时间。
在全量推送消息生成后，首先进行分桶处理以减少数据库压力和提高查询速度，分桶策略基于用户ID的哈希值进行，对应的伪代码如下：
num_buckets是预先定义的总桶数，一般根据系统需求和数据库容量来设置。
数据库MongoDB分片集群中，每个桶均匀落在不同的数据库分片中，通过这样的方式，消息数据读写请求会分布在不同的分片上，从而避免单一数据库节点的瓶颈。
调用get_bucket_id函数，根据用户ID获取桶标识，根据桶标识，确定消息将存储在哪个数据库MongoDB分片，将消息写入该分片，对应的伪代码如下：
在消息成功写入数据库后，将该消息的元信息(如消息ID，时间戳)更新到Redis缓存，对应的伪代码如下：
def update_redis_cache(message_id，timestamp)://定义更新缓存
redis.set(f"latest_message:{message_id}"，timestamp)//将消息的元信息更新到Redis缓存
通过这样的消息写入流程、分桶策略、数据库分片策略，本申请实施例有效地解决全量推送消息在高并发大数据量场景下的性能和可扩展性问题。
下面介绍消息在线推送的流程。
在线用户通过某种机制(如WebSocket或长轮询)保持与服务器的连接，使用对用户无感知的广播触发机制，系统会周期性地检查在线用户是否有新的全量推送消息，如果有新消息，系统将利用已建立的连接，直接推送全量消息给在线用户。
假设平台的同时在线用户峰值为50万，接入层服务器需要在合理的时间范围内遍历这50万在线用户并完成全量消息的推送。
通信服务器将全量推送消息写入到数据库MongoDB，通信服务器广播消息至每一个接入服务器，接入服务器开始遍历所有在线用户，查询其未读的全量推送消息，对应的伪代码如下：
如果接入层服务器遍历在线用户的速度超过了设定的限频，该用户ID将被放入缓冲区，以便稍后继续处理，限频(Rate Limiting)指的是设定每秒查询次数的上限，以防止系统过载。查询是限频的，所以当达到限频时，用户ID会先存储在缓冲区中，在下个限频周期，接入层服务器会从缓冲区取出用户ID，并继续查询未读的全量推送消息，以确保没有消息丢失。该方案确保在线用户能及时地接收到全量推送消息，同时也有效地管理了系统资源，提高了性能和可靠性。
最后介绍离线用户登录时拉取全量推送消息的流程。
用户打开应用并开始登录，登录成功后，系统会首先检查Redis缓存，以判断该用户是否有新的、未收到的全量推送消息，如果缓存中没有相关信息，系统会查询MongoDB分片集群，如果存在未收到的全量推送消息，系统将推送这些消息给用户，拉取完成后，系统更新Redis缓存，标记该用户已经收到最新的全量推送消息。
假设平台每天的活跃用户数为1000万，同时在线用户峰值为50万。若每个用户在一天内平均登录2次，则登录次数为2000万次。每次登录都可能触发全量消息的拉取。
用户登录并建立与接入层服务器的连接，接入层服务器通知通信服务器进行用户身份验证和会话建立，通信服务器查询Redis缓存，获取用户上次全量推送消息的刷新时间，使用用户的上次全量推送消息刷新时间、用户注册时间和消息过期时间，通信服务器从数据库MongoDB中拉取用户需要的全量推送消息，对应的伪代码如下：
本申请实施例采取增量拉取，通过在Redis中记录用户上次全量推送消息的刷新时间，系统在用户下次登录时只需要拉取增量的全量推送消息，提高了效率。在拉取全量推送消息时，系统将不会拉取比用户的注册时间还要早的消息，同时也会过滤掉已经过期的全量推送消息。
通过这一系列设计和优化，本申请实施例有效地解决用户在不同状态(在线和离线)下接收全量推送消息的问题，同时也优化了系统性能和数据准确性。基于条件推送与读扩散机制，当用户登录时，系统判断该用户是否有新的全量推送消息，并在有的情况下进行消息推送。本申请实施例具有透明化兼容性，由于本申请实施例复用原有的消息推送机制，因此它对各种客户端(包括不同版本和平台)都是透明的，因此无需进行额外的兼容性处理。本申请实施例针对在线用户采取无感知广播触发，引入在线用户广播触发机制，该机制确保即使用户在线而没有重新登录，也能接收到全量推送消息。本申请实施例采取分布式存储与分桶优化，通过使用MongoDB分片和消息分桶，可以有效地解决数据库热点问题和提高整体性能。本申请实施例利用时间戳进行增量消息拉取，在Redis中记录每个用户上次全量消息刷新的时间，以支持更高效的增量消息拉取。
本申请实施例在实现全量推送需求中具有以下几个显著的优势：
1、兼容性和透明性。通过使用条件推送和复用现有的消息推送机制，本申请实施例能够在不同版本和平台(iOS/Android)的客户端上实现无缝集成，无需额外的兼容性处理。
2、动态和实时性。本申请实施例采用了读扩散和针对在线用户的广播触发机制，确保所有用户—无论在线还是离线—都能实时接收到全量推送消息。
3、性能优化。通过使用MongoDB分片集群和消息分桶技术，方案有效地避免了数据库热点问题。同时，Redis缓存管理实现了全量消息刷新时间的高效存储，大大减少了对MongoDB的频繁访问。
可以理解的是，在本申请实施例中，涉及到用户信息等相关的数据，当本申请实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
下面继续说明本申请实施例提供的消息处理装置255的实施为软件模块的示例性结构，在一些实施例中，如图2所示，存储在存储器250的消息处理装置255中的软件模块可以包括：写入模块2551，用于将待推送消息基于读扩散机制写入数据库；获取模块2552，用于基于无感知广播机制获取当前处于在线状态的第一对象；在线推送模块2553，用于基于所述无感知广播机制从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息；离线推送模块2554，用于针对处于离线状态的第二对象，响应于所述第二对象从所述离线状态切换至在线状态，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息。
在一些实施例中，所述写入模块2551，还用于：对所述目标对象进行分桶处理，得到对应所述目标对象的桶标识，其中，所述目标对象是第一对象或者第二对象；确定所述数据库中与所述桶标识对应的目标数据库分片；将所述待全量推送消息写入所述目标数据库分片。
在一些实施例中，所述写入模块2551，还用于：获取所述目标对象的固定标识；对所述固定标识进行哈希处理，得到对应所述目标对象的桶标识。
在一些实施例中，所述从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息是通过通信服务器实现的；所述在线推送模块2553，还用于：向多个接入层服务器发送第一广播信令，以使每个所述接入层服务器对各自关联的客户端进行遍历处理，得到处于所述在线状态的第一对象的客户端，并将承载有所述第一对象的对象标识的消息返回至所述通信服务器。
在一些实施例中，所述在线推送模块2553，还用于：向多个接入层发送第二广播信令，以使每个所述接入层服务器对各自关联的处于所述在线状态的第一对象登录的客户端进行消息接收情况遍历处理，得到处于所述在线状态的第一对象登录的客户端的消息接收情况；当所述消息接收情况表征所述第一对象未接收到所述待推送消息时，从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息。
在一些实施例中，所述在线推送模块2553，还用于：每个所述接入层服务器执行以下处理：所述接入层针对各自关联的处于所述在线状态的第一对象登录的客户端以第一查询频次进行消息接收情况遍历处理，得到处于所述在线状态的第一对象登录的客户端的消息接收情况，其中，所述第一查询频次低于查询频次阈值；当针对任一第一对象登录的客户端进行消息接收情况遍历处理时的第一查询频次超过查询频次阈值时，将所述任一第一对象的对象标识存储于缓冲区；当进入下一个查询频次限制周期时，从所述缓冲区中提取所述任一第一对象的对象标识，并继续对所述任一第一对象登录的客户端进行消息接收情况遍历处理，得到所述任一第一对象登录的客户端的消息接收情况。
在一些实施例中，所述离线推送模块2554，还用于：查询所述第二对象上一次收到推送消息时的刷新时间；基于所述刷新时间、所述第二对象的注册时间以及消息过期时间，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息。
在一些实施例中，所述离线推送模块2554，还用于：从缓存中查询所述第二对象上一次收到推送消息时的刷新时间；在从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息之后，在缓存中将查询到所述待推送消息的时间更新为所述第二对象上一次收到推送消息时的刷新时间。
在一些实施例中，所述离线推送模块2554，还用于：基于所述刷新时间、所述第二对象的注册时间以及所述消息过期时间确定时间范围；从所述数据库中查询符合所述时间范围的消息作为所述待推送消息，并向所述第二对象登录的客户端发送所述待推送消息。
在一些实施例中，所述离线推送模块2554，还用于：向所述第二对象登录的客户端发送提示信息，所述提示信息用于提示所述第二对象在对应所述第二对象的收件箱中查询所述待推送消息。
下面继续说明本申请实施例提供的消息处理装置的实施为软件模块的示例性结构，在一些实施例中，存储在存储器的消息处理装置中的软件模块可以包括：显示模块，用于在目标对象登录的客户端上显示待推送消息；其中，所述目标对象是从离线状态切换至在线状态的第二对象，或者所述目标对象是保持所述在线状态的第一对象，所述待推送消息是通过本申请实施例提供的消息处理方法推送至所述客户端的。
本申请实施例提供了一种计算机程序产品，该计算机程序产品包括计算机可执行指令，该计算机可执行指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机可执行指令，处理器执行该计算机可执行指令，使得该电子设备执行本申请实施例上述的消息处理方法。
本申请实施例提供一种存储有计算机可执行指令的计算机可读存储介质，其中存储有计算机可执行指令，当计算机可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的消息处理方法，例如，如图3A-图3C示出的消息处理方法。
在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EP ROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。
在一些实施例中，计算机可执行指令可以采用程序、软件、软件模块或脚本的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
作为示例，计算机可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，HyperText Markup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序的文件)中。
作为示例，可执行指令可被部署为在一个电子设备上执行，或者在位于一个地点的多个电子设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个电子设备上执行。
综上所述，通过本申请实施例将待推送消息基于读扩散机制写入数据库，读扩散机制写入数据库可以节约数据写入成本，基于无感知广播机制获取当前处于在线状态的第一对象，可以自动检测在线第一对象，基于所述无感知广播机制从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息，确保即使用户保持在线也能及时接收到待推送消息；针对处于离线状态的第二对象，响应于所述第二对象从所述离线状态切换至在线状态，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息，相当于使用条件推送策略，能够适配不同客户端环境，不需要额外的兼容性处理。
以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (16)

1.一种消息处理方法，其特征在于，所述方法包括：
将待推送消息基于读扩散机制写入数据库；
基于无感知广播机制获取当前处于在线状态的第一对象；
基于所述无感知广播机制从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息；
针对处于离线状态的第二对象，响应于所述第二对象从所述离线状态切换至在线状态，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息。
2.根据权利要求1所述的消息处理方法，其特征在于，所述将待全量推送消息基于读扩散机制写入数据库，包括：
对所述目标对象进行分桶处理，得到对应所述目标对象的桶标识，其中，所述目标对象是第一对象或者第二对象；
确定所述数据库中与所述桶标识对应的目标数据库分片；
将所述待全量推送消息写入所述目标数据库分片。
3.根据权利要求2所述的消息处理方法，其特征在于，所述对所述目标对象进行分桶处理，得到对应所述目标对象的桶标识，包括：
获取所述目标对象的固定标识；
对所述固定标识进行哈希处理，得到对应所述目标对象的桶标识。
4.根据权利要求1所述的消息处理方法，其特征在于，所述从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息是通过通信服务器实现的；
所述基于无感知广播机制，获取当前处于在线状态的第一对象，包括：
向多个接入层服务器发送第一广播信令，以使
每个所述接入层服务器对各自关联的客户端进行遍历处理，得到处于所述在线状态的第一对象的客户端，并将承载有所述第一对象的对象标识的消息返回至所述通信服务器。
5.根据权利要求1所述的消息处理方法，其特征在于，所述从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息，包括：
向多个接入层发送第二广播信令，以使
每个所述接入层服务器对各自关联的处于所述在线状态的第一对象登录的客户端进行消息接收情况遍历处理，得到处于所述在线状态的第一对象登录的客户端的消息接收情况；
当所述消息接收情况表征所述第一对象未接收到所述待推送消息时，从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息。
6.根据权利要求5所述的消息处理方法，其特征在于，所述每个所述接入层服务器对各自关联的处于所述在线状态的第一对象登录的客户端进行消息接收情况遍历处理，得到处于所述在线状态的第一对象登录的客户端的消息接收情况，包括：
每个所述接入层服务器执行以下处理：
所述接入层针对各自关联的处于所述在线状态的第一对象登录的客户端以第一查询频次进行消息接收情况遍历处理，得到处于所述在线状态的第一对象登录的客户端的消息接收情况，其中，所述第一查询频次低于查询频次阈值；
当针对任一第一对象登录的客户端进行消息接收情况遍历处理时的第一查询频次超过查询频次阈值时，将所述任一第一对象的对象标识存储于缓冲区；
当进入下一个查询频次限制周期时，从所述缓冲区中提取所述任一第一对象的对象标识，并继续对所述任一第一对象登录的客户端进行消息接收情况遍历处理，得到所述任一第一对象登录的客户端的消息接收情况。
7.根据权利要求1所述的消息处理方法，其特征在于，所述从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息，包括：
查询所述第二对象上一次收到推送消息时的刷新时间；
基于所述刷新时间、所述第二对象的注册时间以及消息过期时间，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息。
8.根据权利要求7所述的消息处理方法，其特征在于，所述查询所述第二对象上一次收到推送消息时的刷新时间，包括：
从缓存中查询所述第二对象上一次收到推送消息时的刷新时间；
在从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息之后，所述方法还包括：
在缓存中将查询到所述待推送消息的时间更新为所述第二对象上一次收到推送消息时的刷新时间。
9.根据权利要求7所述的消息处理方法，其特征在于，所述基于所述刷新时间、所述第二对象的注册时间以及消息过期时间，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息，包括：
基于所述刷新时间、所述第二对象的注册时间以及所述消息过期时间确定时间范围；
从所述数据库中查询符合所述时间范围的消息作为所述待推送消息，并向所述第二对象登录的客户端发送所述待推送消息。
10.根据权利要求7所述的消息处理方法，其特征在于，所述方法还包括：
向所述第二对象登录的客户端发送提示信息，所述提示信息用于提示所述第二对象在对应所述第二对象的收件箱中查询所述待推送消息。
11.一种消息处理方法，其特征在于，所述方法包括：
在目标对象登录的客户端上显示待推送消息；
其中，所述目标对象是从离线状态切换至在线状态的第二对象，或者所述目标对象是保持所述在线状态的第一对象，所述待推送消息是通过权利要求1至10任一项所述的消息处理方法推送至所述客户端的。
12.一种消息处理装置，其特征在于，所述装置包括：
写入模块，用于将待推送消息基于读扩散机制写入数据库；
获取模块，用于基于无感知广播机制获取当前处于在线状态的第一对象；
在线推送模块，用于基于所述无感知广播机制从所述数据数据库中查询所述待推送消息并向所述第一对象登录的客户端发送所述待推送消息；
离线推送模块，用于针对处于离线状态的第二对象，响应于所述第二对象从所述离线状态切换至在线状态，从所述数据库中查询所述待推送消息并向所述第二对象登录的客户端发送所述待推送消息。
13.一种消息处理装置，其特征在于，所述装置包括：
显示模块，用于在目标对象登录的客户端上显示待推送消息；
其中，所述目标对象是从离线状态切换至在线状态的第二对象，或者所述目标对象是保持所述在线状态的第一对象，所述待推送消息是通过权利要求1至10任一项所述的消息处理方法推送至所述客户端的。
14.一种电子设备，其特征在于，所述电子设备包括：
存储器，用于存储计算机可执行指令；
处理器，用于执行所述存储器中存储的计算机可执行指令时，实现权利要求1至10或权利要求11中任一项所述的消息处理方法。
15.一种计算机可读存储介质，存储有计算机可执行指令，其特征在于，所述计算机可执行指令被处理器执行时实现权利要求1至10或权利要求11中任一项所述的消息处理方法。
16.一种计算机程序产品，包括计算机可执行指令，其特征在于，所述计算机可执行指令被处理器执行时实现权利要求1至10或权利要求11中任一项所述的消息处理方法。
CN202311500157.6A 2023-11-10 2023-11-10 消息处理方法、装置、设备、存储介质及程序产品 Pending CN117560416A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311500157.6A CN117560416A (zh) 2023-11-10 2023-11-10 消息处理方法、装置、设备、存储介质及程序产品

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311500157.6A CN117560416A (zh) 2023-11-10 2023-11-10 消息处理方法、装置、设备、存储介质及程序产品

Publications (1)

Publication Number Publication Date
CN117560416A true CN117560416A (zh) 2024-02-13

Family

ID=89815839

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311500157.6A Pending CN117560416A (zh) 2023-11-10 2023-11-10 消息处理方法、装置、设备、存储介质及程序产品

Country Status (1)

Country Link
CN (1) CN117560416A (zh)

Similar Documents

Publication Publication Date Title
CN107861686B (zh) 文件存储方法、服务端和计算机可读存储介质
WO2016061898A1 (zh) 直播间的频道访问方法和系统
CN108390933B (zh) 消息分发方法、装置、服务器及存储介质
CN108429777B (zh) 一种基于缓存的数据更新方法及服务器
CN103166827A (zh) 用户行为数据上报方法和系统
TW201317799A (zh) 網路資源下載資訊的分享控制系統和方法
CN103491055A (zh) 一种在多个客户端间同步信息的方法、客户端和服务器
CN111221469B (zh) 同步缓存数据的方法、装置和系统
CN109462631B (zh) 数据处理方法、装置、存储介质及电子装置
CN112118315A (zh) 数据处理系统、方法、装置、电子设备和存储介质
CN112121413B (zh) 功能服务的响应方法、系统、装置、终端及介质
CN102411598A (zh) 一种实现数据一致性的方法及其系统
CN111355986B (zh) 一种直播间中的消息处理方法、装置和存储介质
CN104394182A (zh) 一种实现内容分发网络加速的方法及源服务器
CN108540367B (zh) 一种消息处理方法及系统
CN111541555A (zh) 群聊优化方法及相关产品
WO2012110079A1 (en) Distribution of data processing
CN101677317B (zh) 更新内容发送方法及动态内容分发服务器
CN110990213A (zh) 一种集群环境用户日志实时监控方法及装置
CN117560416A (zh) 消息处理方法、装置、设备、存储介质及程序产品
CN111935316B (zh) 一种前端设备目录获取方法及装置
CN114979234A (zh) 分布式集群系统中会话控制共享方法及系统
CN116781780A (zh) 请求处理方法、装置、服务器和存储介质
CN111586438B (zh) 一种业务数据的处理方法、装置及系统
CN110392104B (zh) 数据同步方法、系统、服务器及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication