CN114461595A - 发送消息的方法、装置、介质和电子设备 - Google Patents

Abstract

本申请的实施例提供了一种发送消息的方法。该方法包括：从用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据。解压所述目标用户集合压缩数据，并向解压得到的目标用户集合内的用户发送所述目标消息。其中，所述用户集合压缩数据的存储方法包括：从源数据表对应的副表中，选取预设副表；所述副表由所述源数据表存储的至少部分用户数据离线同步生成；根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户以生成用户集合；对所述用户集合进行压缩存储，以提升消息发送效率，降低对应用程序的影响。此外，本公开的实施例提供了一种发送消息的装置，介质与电子设备。

Description

发送消息的方法、装置、介质和电子设备

技术领域

本申请的实施例涉及发送消息的领域，更具体地，本申请的实施例涉及一种发送消息的方法、装置、介质和电子设备。

背景技术

本部分旨在为权利要求书中陈述的本申请的实施例提供背景或上下文。此处的描述不因为包括在本部分中就承认是相关技术。

应用程序运营商会向目标用户推送消息，使得所述目标用户可以及时了解到一些消息资讯。所述目标用户是指需要被通知所述信息的一些用户。这些目标用户一般满足预设的用户筛选条件。所述应用程序可以是电脑程序、小程序、手机应用程序(Application，APP)等。

相关技术中，消息推送的流程如下：在有待发送的目标消息的情形下，通过查询源数据表，确定满足预设筛选条件的目标用户并存储形成目标用户集合，然后向目标用户集合内的目标用户推送所述目标消息。

所述源数据表包含应用程序在运行过程中依赖的用户数据。所述用户数据可以根据需求设定。比如，在发送歌手新专辑的场景中，应用程序在运行过程中需要存储关注歌手的用户数据，买过专辑的用户数据，开启和关闭消息推送功能的用户数据，为歌曲点过赞的用户数据等等，则所述源数据表可以存储这些用户数据。

以应用程序为音乐APP为例。当A歌手发布了新专辑，音乐APP运营人员可以查询源数据表关注了该歌手(用户筛选条件)的粉丝(目标用户)，并向这些粉丝推送消息：“你关注的歌手A，发布新专辑了，快来听听吧”。由此可以使粉丝及时了解到A歌手发布新专辑的消息。

相关技术中会存在以下问题：

第一，由于所述应用程序在运行过程中会产生大量的用户数据，所述源数据表的数据量会比较庞大，在有待发送的目标消息的情形下，查询源数据表确定目标用户的方式，查询效率低，延迟高。

第二，确定的目标用户以明文的方式存储，存储成本较高，数据安全性低。

第三，在确定目标用户时直接查询了所述源数据表，频繁地数据查询会影响应用程序的运行，从而影响应用程序功能。

发明内容

在本上下文中，本申请的实施例期望提供一种发送消息的方法、装置、介质和电子设备。

在本申请实施例的第一方面中，提供了一种发送消息的方法。所述方法可以包括：从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据；解压所述目标用户集合压缩数据，得到目标用户集合；向所述目标用户集合内的用户发送所述目标消息；所述用户集合压缩数据的存储方法包括：从源数据表对应的副表中，选取与确定用户集合相关的预设副表；所述源数据表包含应用程序在运行过程中依赖的用户数据，所述副表由所述源数据表存储的至少部分用户数据离线同步生成；根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户以生成用户集合；对所述用户集合进行压缩存储。

在一些实施例中，所述副表包括存储在缓存中的第一副表与存储在非缓存的第二副表，所述第一副表用于存储发送所述目标消息依赖的预设类型数据，所述第二副表用于存储非预设类型数据。

在一些实施例中，离线同步生成副表的方法包括：响应于源数据表存储增量数据，将包含所述增量数据的日志信息同步至消息队列；从所述消息队列中读取所述日志信息并进行解析；在所述日志信息包含的增量数据包含所述预设类型数据的情形下，将所述增量数据转发至所述第一副表进行存储；在所述日志信息包含的增量数据不包含所述预设类型数据的情形下，将所述增量数据转发至所述第二副表进行存储。

在一些实施例中，所述将包含所述增量数据的日志信息同步至消息队列，包括：通过预设的第一节点将所述增量数据写入日志信息；所述第一节点与第二节点建立通信连接；通过所述第二节点获取所述日志信息，并将所述日志信息发送至消息队列。

在一些实施例中，所述根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户以生成用户集合，包括：响应于当前时刻与上一次筛选出所述目标用户的时刻之间的时长达到预设时长，查询所述预设副表存储的用户数据，得到满足预设用户筛选条件的用户以生成用户集合。

在一些实施例中，所述预设副表包括第一预设副表，第二预设副表与第三预设副表；其中，所述第一预设副表用于存储关注预设类型对象的第一用户数据；所述第二预设副表用于存储购买过所述预设类型对象关联产品的第二用户数据；所述第三预设副表用于存储关闭和打开消息发送功能的第三用户数据；所述预设用户筛选条件包括关注所述预设类型对象或购买过所述预设类型对象关联产品，并且打开消息发送功能；所述根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户以生成用户集合，包括：针对所述预设类型对象中的每一对象：查询所述第一预设副表中的所述第一用户数据，得到关注所述对象的第一用户集合；查询所述第二预设副表中的所述第二用户数据，得到购买过所述对象关联产品的第二用户集合；将所述第一用户集合与所述第二用户集合进行合并得到第四用户集合；查询所述第三预设副表中的所述第三用户数据，得到关闭消息发送功能的第三用户集合；在所述第四用户集合中删除所述第三用户集合包含的用户，得到与所述对象对应的最终用户集合。

在一些实施例中，所述对所述用户集合进行压缩存储，包括：针对每一所述对象，利用预设压缩算法对所述对象对应的最终用户集合进行压缩处理，得到用户集合压缩数据，以及，将所述用户集合压缩数据与所述对象关联存储。

在一些实施例中，所述利用预设压缩算法对所述对象对应的最终用户集合进行压缩处理，得到用户集合压缩数据，以及，将所述用户集合压缩数据与所述对象关联存储，包括：针对所述最终用户集合内的每一最终用户执行以下步骤：获取所述最终用户对应的用户标识；将所述用户标识转换为预设进制数；根据所述预设进制数包括的前N位数字，在为所述对象预先分配的多个数据桶中，确定所述最终用户对应的目标数据桶；将所述预设进制数的剩余数字存储至所述目标数据桶。

在一些实施例中，所述将所述预设进制数的剩余数字存储至所述目标数据桶，包括以下至少一种方式：响应于所述最终用户集合内包含的最终用户数量未达到预设阈值，将所述预设进制数的剩余数字以数组格式存储至所述目标数据桶；所述目标数据桶的类型默认为数组类型；响应于所述最终用户集合内包含的最终用户数量达到预设阈值，将所述目标数据桶的类型转换为位图类型，将所述剩余数字组成的数值转换为十进制数，将所述位图中与所述十进制数对应的位置设置为预设值。

在一些实施例中，在将所述用户集合压缩数据与所述对象关联存储之前，还包括：获取验证所述预设压缩算法所需的验证数据；所述验证数据包含以下至少一项：采样数据对，所述采样数据对包括从用户集合获取的采样用户的采样标识，以及对利用所述预设压缩算法对所述采样标识进行压缩得到的压缩数据；所述用户集合包含的用户数量；所述将所述用户集合压缩数据与所述对象关联存储，包括：将所述用户集合压缩数据和所述验证数据，与所述对象关联存储。

在一些实施例中，所述方法还包括：将所述最终用户集合以明文形式存储至离线数据库以进行数据追踪。

在一些实施例中，在从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据之前，还包括：响应于消息生成请求，生成消息；将所述消息发送至缓存队列与非缓存任务表中分别进行存储。

在一些实施例中，确定目标消息的方法包括：响应于缓存队列中包括消息，将所述缓存队列中包括的消息确定为目标消息；响应于缓存队列中不包括消息，将非缓存任务表中未执行过的消息确定为目标消息。

在一些实施例中，所述非缓存任务表中包括了消息的执行状态；所述将所述消息发送至缓存队列与非缓存任务表中分别进行存储，包括：将所述消息发送至所述缓存队列的队尾进行存储，以及，将所述消息发送非缓存任务表中，并将所述消息的执行状态调整为未执行状态；所述响应于缓存队列中包括消息，将所述缓存队列中包括的消息确定为目标消息，包括：响应于缓存队列中包括消息，从所述缓存队列的头部读取消息，将读取的消息确定为目标消息；所述响应于缓存队列中不包括消息，将非缓存任务表中未执行过的消息确定为目标消息，包括：响应于缓存队列中不包括消息，将所述非缓存任务表中处于未执行状态的消息确定为目标消息。

在一些实施例中，所述用户集合压缩数据与预设类型对象中的每一对象关联存储；所述目标消息对应于所述预设类型对象中的目标对象；所述从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据，包括：从与每一所述对象关联存储的用户集合压缩数据中，获取与所述目标对象关联存储的目标用户集合压缩数据。

在一些实施例中，所述向所述目标用户集合内的用户发送所述目标消息，包括：响应于所述目标消息的类型为私信，根据所述目标用户集合内的用户的用户标识，向与所述用户标识关联的账户发送所述目标消息；响应于所述目标消息的类型为PUSH消息，根据所述目标用户集合内的用户的用户标识，从缓存的第一副表中获取所述用户对应的预设类型数据，向与所述预设类型数据指示的终端设备发送所述目标消息；所述第一副表存储了用户标识与预设类型数据的对应关系。

在一些实施例中，所述目标消息存储于非缓存任务表；所述非缓存任务表包括所述目标消息的执行状态；在向所述目标用户集合内的用户发送所述目标消息之后，还包括：将所述目标消息对应的执行状态更新为已执行状态。

在本申请实施例的第二方面中，提供了一种发送消息的装置。所述装置可以包括：获取模块，用于从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据；解压模块，用户解压所述目标用户集合压缩数据，得到目标用户集合；发送模块，用于向所述目标用户集合内的用户发送所述目标消息；存储模块，用于存储所述用户集合压缩数据；所述存储模块包括：选取模块，用于从源数据表对应的副表中，选取与确定用户集合相关的预设副表；所述源数据表包含应用程序在运行过程中依赖的用户数据，所述副表由所述源数据表存储的至少部分用户数据离线同步生成；筛选模块，用于根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户以生成用户集合；压缩存储模块，用于对所述用户集合进行压缩存储。

在本申请实施例的第三方面中，提供了一种介质，所述介质存储有计算机程序，所述计算机程序用于使处理器执行如前述任一实施例示出的发送消息的方法。

在本申请实施例的第四方面中，提供了一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器通过运行所述可执行指令以实现如前述任一实施例示出的发送消息的方法。

在前述记载的技术方案中，第一，通过将用户集合的确定和存储过程与目标消息的发送过程进行解耦，可以预先完成用户集合的确定与存储，与相关技术相比，不仅可以降低确定与存储用户集合的频次，从而降低对应用程序功能的影响，而且可以提升目标用户集合的获取效率，降低延迟，达到近乎实时发送消息的效果；

第二，可以利用源数据表包含的至少部分数据离线同步生成副表，然后在从副表中选取与确定用户集合相关的预设副表，并根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户，形成用户集合，与相关技术相比，不仅不需要查询存储完整数据的源数据表，降低了数据查询量，从而提升用户数据查询效率，降低延迟，而且可以将确定用户集合依赖的数据源，与应用程序运行过程依赖的数据源隔离开，降低对应用程序运行产生的影响。

第三，对确定的用户集合进行压缩存储，与相关技术相比，不仅可以降低数据所需存储空间，而且可以提升数据安全性。

附图说明

通过参考附图阅读下文的详细描述，本申请示例性实施例的前述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本申请的若干实施例，其中：

图1为本申请实施例示出的一种发送消息的方法的应用场景示意图；

图2为本申请实施例示出的一种发送消息的方法的方法流程图；

图3为本申请实施例示出的一种用户集合压缩数据的存储方法的方法流程图；

图4为本申请实施例示出的一种离线同步生成副表的方法的流程示意图；

图5为本申请实施例示出的一种离线数据同步流程示意图；

图6为本申请实施例示出的一种确定用户集合的方法的流程示意图；

图7为本申请实施例示出的一种用户集合确定流程示意图；

图8为本申请实施例示出的一种压缩存储方法的流程示意图；

图9为本申请实施例示出的一种在缓存队列存储与读取消息的流程示意图；

图10为本申请实施例示出的一种发送消息的方法流程示意图；

图11为本申请实施例示出的一种用户集合的确定与压缩存储的方法的方法流程图；

图12为本申请实施例示出的一种发送目标消息的方法的方法流程图；

图13为本申请实施例示出的一种发送消息的装置的结构示意图；

图14为本申请实施例示出的一种应用于发送消息的方法的程序产品；

图15为本申请实施例示出的一种电子设备的结构示意图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施例来描述本申请的原理和精神。应当理解，给出这些实施例仅仅是为了使本领域技术人员能够更好地理解进而实现本申请，而并非以任何方式限制本申请的范围。相反，提供这些实施例是为了使本申请更加透彻和完整，并且能够将本申请的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本申请的实施例可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本申请可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

此外，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

根据本申请的实施例，提出了一种发送消息的方法、装置、介质和电子设备。

下面参考本申请的若干代表性实施例，详细阐释本申请的原理和精神。

发明概述

第一方面，发明人发现，相关技术中是将用户集合的确定和存储过程与目标消息的发送过程耦合在一起的，由于发送目标消息的频率较高，也会导致用户集合的确定和存储频率也高，进而导致查询源数据表的频率也很高，由于硬件资源的有限性，高频率的查询动作会影响源数据表的存储数据的功能，从而影响应用程序功能。

因此，本申请中，发明人通过将用户集合的确定和存储过程与目标消息的发送过程进行解耦，可以预先完成用户集合的确定与存储，不仅可以降低确定与存储用户集合的频次，从而降低对应用程序功能的影响，而且可以提升目标用户集合的获取效率，降低延迟，达到近乎实时发送消息的效果。

第二方面，发明人发现，相关技术中在有待发送的目标消息的情形下，是直接查询源数据表确定目标用户的，由于源数据表的数据量很庞大，是导致查询效率低的关键因素。

因此，本申请中，发明人利用源数据表包含的至少部分数据离线同步生成副表，然后在从副表中选取与确定用户集合相关的预设副表，并根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户，形成用户集合，不仅在确定用户集合的时候，不需要查询存储完整数据的源数据表，降低了数据查询量，从而提升用户数据查询效率，降低延迟，而且可以将确定用户集合依赖的数据源，与应用程序运行过程依赖的数据源隔离开，降低对应用程序运行产生的影响。

第三方面，发明人发现，相关技术中，确定目标用户是以明文的方式存储的，而明文的方式既占用空间，又不安全，是导致存储成本较高，数据安全性低的关键因素。

因此，本申请中，发明人对确定的用户集合进行压缩存储，不仅可以降低数据所需存储空间，而且可以提升数据安全性。

在介绍了本申请的基本原理之后，下面具体介绍本申请的各种非限制性实施例。

应用场景总览

请参考图1，图1为本申请实施例示出的一种发送消息的方法的应用场景示意图。

前述应用场景可以为任意类型的发送消息的场景。示例性的，所述应用场景可以是歌手新专辑推送场景，试用产品推送场景，广告推送场景等等。

在这些应用场景中，可以包含相互解耦的两个过程：其一为用户集合的确定与存储过程，其二为发送消息过程。其中，发送消息的过程中需要利用存储的用户集合压缩数据。用户集合的确定与存储过程可以理解为发送消息的预处理过程。

在预处理过程中，可以从源数据表对应的副表中，选取与确定用户集合相关的预设副表；所述源数据表包含应用程序在运行过程中依赖的用户数据，所述副表由所述源数据表存储的至少部分用户数据离线同步生成；根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户以生成用户集合；对所述用户集合进行压缩存储。

在发生消息过程中，从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据；解压所述目标用户集合压缩数据，得到目标用户集合；向所述目标用户集合内的用户发送所述目标消息。

以图1示出场景为例。如图1所示，数据源即为源数据表中存储的数据。通过对数据源进行数据离线同步处理，可以得到数据副本。这些数据副本可以存储在副表中。这些副表不会被应用程序直接使用，属于离线副表。

周期性地可以利用数据副本中的数据，确定满足预设用户筛选条件的用户以生成用户集合。得到的用户集合可压缩存储起来，得到用户集合压缩数据。

在有消息发送需求的时候，可以从消息集合中获取到目标消息，然后从存储的用户集合压缩数据中，获取与所述目标消息对应的目标用户集合压缩数据并进行解压得到目标用户集合。之后可以将所述目标消息发送至目标用户集合内的用户对应的终端设备中。

在前述场景中，第一，通过将用户集合的确定和存储过程与目标消息的发送过程进行解耦，可以预先完成用户集合的确定与存储，不仅可以降低确定与存储用户集合的频次，从而降低对应用程序功能的影响，而且可以提升目标用户集合的获取效率，降低延迟，达到近乎实时发送消息的效果。

第二，可以利用数据副本确定用户集合，不仅降低了数据查询量，提升用户数据查询效率，降低延迟，而且可以将确定用户集合依赖的数据源，与应用程序运行过程依赖的数据源隔离开，降低对应用程序运行产生的影响。

第三，可以对用户集合进行压缩存储，不仅可以降低数据所需存储空间，而且可以提升数据安全性。

示例性方法

请参见图2，图2为本申请实施例示出的一种发送消息的方法的方法流程图。

如图2所示，所述发送消息的方法可以包括S202-S206。除特别说明外，本申请不特别限定这些步骤的执行顺序。

其中，S202，从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据。

所述用户集合压缩数据，是指对用户集合进行压缩得到的压缩数据。

所述用户集合包括需要接收消息的用户。所述接收消息的用户可以是预先确定的满足预设用户筛选条件的用户。

所述预设用户筛选条件可以根据业务需求进行设定。比如，在歌手新专辑推送场景中，所述预设用户筛选条件可以被设定为关注歌手或者购买过该歌手专辑，并且没有关闭消息推送功能。通过所述预设用户筛选条件筛选出的需要接收消息的用户即为歌手粉丝或者购买过该歌手专辑，并且没有关闭消息推送功能的用户。

所述用户集合是被预先确定和存储的，确定和存储用户集合的过程与发送消息过程是相互独立的。发送消息时会使用预先存储的用户集合压缩数据。

请参见图3，图3为本申请实施例示出的一种用户集合压缩数据的存储方法的方法流程图。

如图3所示，所述存储方法可以包括S302-S306。除特别说明外，本申请不特别限定这些步骤的执行顺序。

S302，从源数据表对应的副表中，选取与确定用户集合相关的预设副表。

所述源数据表包含应用程序在运行过程中依赖的用户数据。需要说明的是，本申请记载的各种类型的表均是一类表的统称，不是单指某一张具体的表。比如，源数据表即是存储应用程序运营数据的表的统称，并不是单指某一张表。副表即是由源数据表同步而来的离线表，也不是单指某一张具体的表。

所述源数据表包含的用户数据类型可以根据需求设定。比如，在歌手新专辑推送场景中，需要存储关注歌手的用户数据，买过歌手专辑的用户数据，开启和关闭消息推送功能的用户数据，为歌曲点过赞的用户数据等等，则所述源数据表可以存储这些类型的用户数据。当然所述源数据表中还可以存储其它类型的数据，比如歌手ID(Identity document，身份标识)，专辑名称，购买专辑时间等数据。本申请不对源数据表存储的数据类型进行特别限定。

在一些方式中，为了便于查询和存储用户数据，所述源数据表可以为关系型数据表。以存储关注歌手的用户数据为例，可以歌手ID为关键字(Key)，以关注该歌手的用户ID为值(Value)在源数据表中进行数据存储。

本申请还可以基于所述源数据表存储的至少部分用户数据离线同步生成与所述源数据表对应的副表。在确定用户集合的过程中可以查询这些副表中的数据，从而将确定用户集合依赖的数据源，与应用程序运行过程依赖的数据源隔离开，使得确定用户集合的过程不会对应用程序运行产生影响，从而不会影响应用程序功能。所述离线同步的方法在后续实施例中有说明，在此不做详述。

所述副表中存储的数据中只有部分数据对确定用户集合有用。本申请中，可以将存储这部分有用数据的副表称为预设副表。

所述预设副表可以根据需要预先被设置。比如，在歌手新专辑推送场景中，确定用户集合可能需要歌手粉丝表，购买歌手专辑用户表，消息推送状态表设置表，则以上这三种副表可以被设置为所述预设副表。S302中，可以从源数据表对应的副表中，选出以上三种预设副表。

S304，根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户以生成用户集合。

所述预设用户筛选条件与预设副表一般是相关联的，都是可以根据业务需求预先进行设定的。预设副表中存储的即是确定用户集合所需的数据。

S304中，通过查询预设副表中的数据可以筛选出满足预设用户筛选条件的用户。

比如，在歌手新专辑推送场景中，所述预设用户筛选条件可以被设定为关注歌手或者购买过该歌手专辑，并且没有关闭消息推送功能。

为了筛选出满足以上筛选条件的用户，则预设副表可以被设置为歌手粉丝表，购买歌手专辑用户表，消息推送状态设置表。

通过查询以上三种预设副表中的用户数据，则可以筛选出歌手粉丝或者购买过该歌手专辑，并且没有关闭消息推送功能的用户作为满足条件的用户。

S306，对所述用户集合进行压缩存储。

本步骤中，可以采用诸如位图，咆哮位图等压缩存储方法，将用户集合压缩为用户集合压缩数据并进行存储。

通过S302-S306可以实现用户集合的预先确定与存储。得到的这部分用户集合中包括很多用户，需要接收目标消息的可能只是其中的一部分用户。在S202中，即是从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据。

以歌手新专辑推送场景为例。通过S302-S306可以得到针对很多歌手的用户集合压缩数据，但是目标消息只是针对歌手A发布新专辑的消息，因此S202中需要获取与歌手A相关的目标用户集合压缩数据。

S204，解压所述目标用户集合压缩数据，得到目标用户集合。

在S306存储用户集合时，会采用预设的压缩存储方法将用户集合压缩为压缩数据，则S204中，可以采用与所述压缩存储方法对应的解压方法，解压所述目标用户集合压缩数据，得到目标用户集合。

以利用咆哮位图压缩方法对用户集合进行压缩存储为例。用户集合中包括了多个32位的用户ID。

在S306中，会将每一用户的用户ID的前16位作为数据桶号，后16位存储在与所述数据桶号对应的数据桶中，以完成压缩存储。即用户ID压缩数据为用户ID的后16位数字。

在S204中，可以将每一用户的用户ID压缩数据存储的数据桶的桶号作为前16位数字，与用户ID压缩数据拼接为32位的用户ID，完成解压。

S206，向所述目标用户集合内的用户发送所述目标消息。

得到目标用户集合之后，则可以将目标消息发送给该集合内的用户对应的终端设备。

前述方案中，通过S202-S206实现了发送消息，通过S302-306实现了用户集合的确定与存储。第一，通过将用户集合的确定和存储过程与目标消息的发送过程进行解耦，可以预先完成用户集合的确定与存储，与相关技术相比，不仅可以降低确定与存储用户集合的频次，从而降低对应用程序功能的影响，而且可以提升目标用户集合的获取效率，降低延迟，达到近乎实时发送消息的效果；

第二，可以利用源数据表包含的至少部分数据离线同步生成副表，然后在从副表中选取与确定用户集合相关的预设副表，并根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户，形成用户集合，与相关技术相比，不仅不需要查询存储完整数据的源数据表，降低了数据查询量，从而提升用户数据查询效率，降低延迟，而且可以将确定用户集合依赖的数据源，与应用程序运行过程依赖的数据源隔离开，降低对应用程序运行产生的影响。

第三，对确定的用户集合进行压缩存储，与相关技术相比，不仅可以降低数据所需存储空间，而且可以提升数据安全性。

本申请还提出一种发送消息的方法。该方法中发送消息的方法可以参照S202-S206，用户集合的确定与存储的方法可以参照S302-S306。与前述实施例重复的内容在此不做详述。

其中，与源数据表对应的副表可以包括存储在缓存中的第一副表与存储在非缓存的第二副表，所述第一副表用于存储发送所述目标消息依赖的预设类型数据，所述第二副表用于存储非预设类型数据。由此可以将发送目标消息依赖的预设类型数据存储在缓存中，由此提升发送消息时获取所述预设类型数据的效率，进而提升发送消息的速度。

所述预设类型数据可以根据业务需求进行设定。在推送歌手新专辑的场景中，所述预设类型数据可以是设备标识数据。

在一些方式中，所述设备标识数据可以是设备Token。

所述设备Token，是指根据设备国际移动设备识别码Imei信息生成，并且带有时间和用户属性的唯一设备标识。设备Token比设备Imei信息多了有效期属性和用户信息属性，时间属性决定了Token只在一定时间内有效。如果Token过期可以为用户派发新的唯一设备Token。

以下介绍一种离线同步生成副表的方法，可以将预设类型数据存储于第一副表，将非预设类型数据存储与第二副表。

请参见图4，图4为本申请实施例示出的一种离线同步生成副表的方法的流程示意图。如图4所示所述方法包括S402-S408。除特别说明外，本申请不特别限定这些步骤的执行顺序。

S402，响应于源数据表存储增量数据，将包含所述增量数据的日志信息同步至消息队列。

在一些方式中，可以通过预设的第一节点将所述增量数据写入日志信息；所述第一节点与第二节点建立通信连接；通过所述第二节点获取所述日志信息，并将所述日志信息发送至消息队列。

所述第一节点可以是对源数据表对应的日志服务进行管理的管理节点(Master)。第一节点可以在源数据表存储增量数据的情形下，基于增量数据生成日志信息。

所述第二节点可以是进行日志转发的通道节点(Canel)。所述第二节点可以预先与第一节点建立通信连接，从第一节点处获取关于增量数据的日志信息，并将获取的日志信息转发到消息队列。

以下举例说明离线同步数据的流程。请参见图5，图5为本申请实施例示出的一种离线数据同步流程示意图。

图5中，Master可以将增量数据以Binlog方式写入日志。

与Master对应的Slaver(执行者节点)与Master之间已有成熟的交互协议。Slaver可以向Master发起请求，获取所述日志。

Slaver在获取Binlog日志后，可以将Binlog日志写入Relay Log，以将增量数据写入源数据表。

Canal可以通过模拟Slaver与Master之间已有成熟的交互协议，伪装为Slaver，与Master建立链接。

Canal可以模拟Slaver向Master发起请求，获取所述日志。Canal在获取Binlog日志后，可以将Binlog日志写入Relay Log，并将Relay Log写到RocketMQ(一种消息队列)中，完成数据同步。

S404，从所述消息队列中读取所述日志信息并进行解析。

本步骤中，可以从消息队列读取日志信息，并解析所述日志信息得到增量数据。

S406-S408，在所述日志信息包含的增量数据包含所述预设类型数据的情形下，将所述增量数据转发至所述第一副表进行存储；在所述日志信息包含的增量数据不包含所述预设类型数据的情形下，将所述增量数据转发至所述第二副表进行存储。

通过S402-S408即可实现离线同步生成副表，并且可以将预设类型数据存储于第一副表，将非预设类型数据存储与第二副表。

本申请还提出一种发送消息的方法。该方法中发送消息的方法可以参照S202-S206，用户集合的确定与存储的方法可以参照S302-S306。与前述实施例重复的内容在此不做详述。

其中，在S304中，可以响应于当前时刻与上一次筛选出所述目标用户的时刻之间的时长达到预设时长，查询所述预设副表存储的用户数据，得到满足预设用户筛选条件的用户以生成用户集合。

所述预设时长可以根据需求进行设定。如果需要提升生成用户集合的频次，则可以减小所述预设时长。如果需要降低生成用户集合的频次，则可以增加所述预设时长。以上周期性生成用户集合的方法中，可以通过调整预设时长的大小，以调整生成目标用户集合的频率，适用多种业务需求。

本申请还提出一种发送消息的方法。该方法中发送消息的方法可以参照S202-S206，用户集合的确定与存储的方法可以参照S302-S306。与前述实施例重复的内容在此不做详述。

其中，在S304中，可以通过查询所述预设副表存储的用户数据，得到满足预设用户筛选条件的用户以生成用户集合。

所述预设副表包括第一预设副表，第二预设副表与第三预设副表；其中，所述第一预设副表用于存储关注预设类型对象的第一用户数据；所述第二预设副表用于存储购买过所述预设类型对象关联产品的第二用户数据；所述第三预设副表用于存储关闭和打开消息发送功能的第三用户数据。

所述预设类型对象可以根据业务需求进行设定。所述预设类型对象可以是人物对象，动物对象等。比如，所述预设类型对象可以是艺人，运动员，作者，漫画家等。在歌手新专辑推送场景中，所述预设类型对象为歌手。

所述预设用户筛选条件包括关注所述预设类型对象或购买过所述预设类型对象关联产品，并且打开消息发送功能。

所述关联产品为任意类型的产品。例如，与艺人关联的艺人娃娃，表情包，专辑等。在歌手新专辑推送场景中，所述关联产品为歌手的专辑。

请参见图6，图6为本申请实施例示出的一种确定用户集合的方法的流程示意图。图6示意的步骤为对S304的补充说明。需要说明的是预设类型对象是一类对象的统称，其可以包括很多数量的对象。需要针对每一对象均执行S602-S610的步骤，以确定与每一对象分别对应的用户集合。比如预设类型对象为歌手，需要针对每一歌手执行S602-S610的步骤，以确定与每一歌手分别对应的用户集合。图6示意的S602-S610是确定某一个对象对应的用户集合的方法。除特别说明外，本申请不特别限定这些步骤的执行顺序。

S602，查询所述第一预设副表中的所述第一用户数据，得到关注所述对象的第一用户集合。

本步骤中，可以通过建立SQL查询语句，在第一预设副表中，查询与所述对象关联存储的第一用户，得到第一用户集合。

S604，查询所述第二预设副表中的所述第二用户数据，得到购买过所述对象关联产品的第二用户集合。

本步骤中，可以通过建立SQL查询语句，在第二预设副表中，查询与所述关联产品关联存储的第二用户，得到第二用户集合。

S606，将所述第一用户集合与所述第二用户集合进行合并得到第四用户集合。

本步骤中，得到的第四用户集合则包括关注了所述对象或者购买过所述对象关联产品的用户。

S608，查询所述第三预设副表中的所述第三用户数据，得到关闭消息发送功能的第三用户集合。

本步骤中，可以通过建立SQL查询语句，在第三预设副表中，查询关闭消息发送功能的第三用户，得到第三用户集合。

S610，在所述第四用户集合中删除所述第三用户集合包含的用户，得到与所述对象对应的最终用户集合。

本步骤中，可以在第四用户集合中，删除关闭消息发送功能的第三用户。完成本步骤，剩余的则是关注所述预设类型对象或购买过所述预设类型对象关联产品，并且打开消息发送功能的最终用户。这些最终用户构成的集合可以被称为最终用户集合。

通过针对每一对象执行S602-S610，即可得到与每一对象分别对应的最终用户集合。后续需要发送与某一目标对象相关的消息的时候，可以获取与所述目标对象对应的目标用户集合，并向所述目标用户集合内的用户发送消息，从而实现有针对性地发送消息。

在得到每一对象分别对应的最终用户集合后，还可以针对每一所述对象，利用预设压缩算法对所述对象对应的最终用户集合进行压缩处理，得到用户集合压缩数据，以及，将所述用户集合压缩数据与所述对象关联存储。由此一方面节省存储空间，提升数据安全性，另一方面，便于后续进行数据查询。

在一些实施例中，可以将所述最终用户集合以明文形式存储至离线数据库以进行数据追踪。

以歌手新专辑推送场景为例。请参见图7，图7为本申请实施例示出的一种用户集合确定流程示意图。

所述第一预设副表为歌手粉丝表，第二预设副表为购买歌手专辑用户表，第三预设副表为消息推送状态设置表。

所述预设用户筛选条件可以被设定为关注歌手或者购买过该歌手专辑，并且没有关闭消息推送功能。

图7中的调度器，可以根据所述预设用户筛选条件设置若干SQL查询逻辑，以查询出关注歌手或者购买过该歌手专辑，并且没有关闭消息推送功能的用户。

可以针对每一歌手，通过调度器实现：

查询歌手粉丝表，得到由关注所述歌手的第一用户构成的第一用户集合；

查询购买歌手专辑用户表，得到由购买过所述歌手专辑的第二用户构成的第二用户集合；

合并第一用户集合与第二用户集合，得到由关注所述歌手或购买过所述歌手专辑的用户构成的第四用户集合；

查询消息推送状态设置表，得到由关闭消息推送功能的第三用户构成的第三用户集合；

在第四用户集合中，删除第三用户集合中的第三用户，即可得到关注歌手或者购买过该歌手专辑，并且没有关闭消息推送功能的最终用户。这些最终用户构成与所述歌手对应的最终用户集合。

得到的最终用户集合一方面可以被压缩存储至Mysql(一种数据库)，另一方面，可以明文形式存储在Hive(一种数据库)，便于验证压缩的数据是否正确。

在所述歌手发布新专辑后，则可以获取与所述歌手对应的最终用户集合，并向该集合内的用户推送歌手发布新专辑的消息，以使这部分用户及时了解所述新专辑的相关讯息，从而达到增加专辑销量和提高用户留存率的目的。

在一些实施例中，在将所述用户集合压缩数据与所述对象关联存储之前，还包括：

获取验证所述预设压缩算法所需的验证数据；所述验证数据包含以下至少一项：采样数据对，所述采样数据对包括从用户集合获取的采样用户的采样标识，以及对利用所述预设压缩算法对所述采样标识进行压缩得到的压缩数据；所述用户集合包含的用户数量；

所述将所述用户集合压缩数据与所述对象关联存储，包括：

将所述用户集合压缩数据和所述验证数据，与所述对象关联存储。

本例中，可以将所述采样数据对中的压缩数据进行解压，得到解压数据，然后与所述采样标识进行比对，如果二者一致，说明压缩算法的压缩结果是正确的，从而验证了压缩算法的准确性。

本例中，还可以利用所述用户数量，与通过S602-S610得到的最终用户的数量进行比较，如果二者一致，也可以说明压缩算法的压缩结果是正确的，从而验证了压缩算法的准确性。

由此可以通过将所述用户集合压缩数据和所述验证数据，与所述对象关联存储，方便验证压缩算法的正确性。

在一些实施例中，所述利用预设压缩算法可以包括咆哮位图算法。

请参见图8，图8为本申请实施例示出的一种压缩存储方法的流程示意图。图8示意的方法是对利用预设压缩算法，针对每一对象对应的最终用户集合进行压缩存储的步骤的补充说明。如图8所示所述方法包括S802-S808。除特别说明外，本申请不特别限定这些步骤的执行顺序。

S802，获取所述最终用户对应的用户标识。

所述用户标识是为用户唯一分配的标识。通过用户标识可以唯一标记用户。在一些方式中，当用户完成注册后，可以为用户分配唯一的所述用户ID(用户标识)。

所述最终用户即为所述最终用户集合中的用户。

本步骤中，可以获取为所述最终用户分配的唯一用户ID。

S804，将所述用户标识转换为预设进制数。

所述预设进制数可以根据业务需求进行设定。一般情形下咆哮位图算法可以对32位的2进制数进行压缩。即所述预设进制数为32位的2进制数。

S806，根据所述预设进制数包括的前N位数字，在为所述对象预先分配的多个数据桶中，确定所述最终用户对应的目标数据桶。

所述N可以根据经验设定。

一般预先在数据库(例如Mysql数据库)中为每一对象分配一段存储空间，所述存储空间可以对应于多个数据桶。所述数据桶的具体数量与所述前N位数字有关。假设N为16，则所述数据桶的具体数量为2的16次方，即65536个。所述多个数据桶的数据桶号为从0开始一直到65535(一共65536个数据桶)。

本步骤中，可以根据所述前N位数字，确定数据桶号，然后将与确定数据桶号对应的数据桶确定所述目标数据桶。

以用户ID为32位2进制数为例，所述N为16，则可以为每一对象分配65536个数据桶。数据桶编号从0开始一直到65535。假设将用户ID的前16位数字转换为十进制数后为0，则可以将桶号为0的数据桶确定为所述目标数据桶。

S808，将所述预设进制数的剩余数字存储至所述目标数据桶。

对象对应的最终用户集合内的每一最终用户执行S802-S808之后，则可以对所述最终用户集合内的每一最终用户进行压缩，并存储在与所述对象对应的目标数据桶中，由此实现对最终用户集合的压缩存储，既节省存储空间，又提升数据安全性。

在一些实施例中，在所述将所述预设进制数的剩余数字存储至所述目标数据桶，包括以下至少一种方式：

响应于所述最终用户集合内包含的最终用户数量未达到预设阈值，将所述预设进制数的剩余数字以数组格式存储至所述目标数据桶；所述目标数据桶的类型默认为数组类型；

响应于所述最终用户集合内包含的最终用户数量达到预设阈值，将所述目标数据桶的类型转换为位图类型，将所述剩余数字组成的数值转换为十进制数，将所述位图中与所述十进制数对应的位置设置为预设值。

所述剩余数字是指所述预设进制数除去前N位数后剩余的数字。

以存储32位2进制的用户ID为例。N为16，除去前16位数后，剩余的后16位数即为所述剩余数字。

所述目标数据桶默认的类型为数组类型。可以默认将所述后16位数以数组形式存储在目标数据桶中。

所述预设阈值为经验阈值。用户数量低于预设阈值时，采用数组形式存储用户标识占用的存储空间更小。用户数量高于预设阈值时，采用位图形式存储用户标识占用的存储空间更小。在咆哮位图算法中，所述预设阈值为4096。所述预设值为经验阈值。假设所述预设值为1。

在所述目标数据桶存储的数据达到4096之后，可以将目标数据桶的类型转换为位图类型。由于需要存储2的16次方个数，所以可以为目标数据桶设置65536个位。存储所述后16位数的时候，可以将所述后16位数转换为十进制，假设为2000，则可以将位图中与2000对应的位置为1，完成用户ID的压缩存储。

以上方法中，在用户数量低于预设阈值时，可以采用占用存储空间更小的数组形式存储用户标识，在用户数量高于预设阈值时，可以采用占用存储空间更小的位图形式存储用户标识，从而可以根据实际情形，灵活选择占用存储空间更小的存储方式进行数据存储，从而节省数据存储空间。

本申请还提出一种发送消息的方法。该方法中发送消息的方法可以参照S202-S206，用户集合的确定与存储的方法可以参照S302-S306。与前述实施例重复的内容在此不做详述。

其中，在S202，从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据之前，还包括：响应于消息生成请求，生成消息，然后将所述消息发送至缓存队列与非缓存任务表中分别进行存储。由此可以在缓存队列和非缓存任务表中分别存储待发送的消息，从而尽量防止消息的漏发。

所述消息生成请求，可以由运营人员创建。例如，在歌手新专辑推送场景中，在歌手发布新专辑之后，运营人员可以针对所述歌手的新专辑，发起推送新专辑消息的生成请求。

响应于所述生成请求，可以生成相应的消息。

生成的消息可以被发送至缓存队列的队尾进行存储，以及被发送至非缓存任务表中进行存储。

在一些实施例中，可以优先从缓存队列中获取待发送的目标消息，由此可以提升获取目标消息的速度，从而提升发送消息的速度。

具体地，可以响应于缓存队列中包括消息，将所述缓存队列中包括的消息确定为目标消息；响应于缓存队列中不包括消息，将非缓存任务表中未执行过的消息确定为目标消息。

在一些实施例中，所述非缓存任务表中包括了消息的执行状态。所述消息被发送至非缓存任务表中存储后，还可以将所述消息的执行状态调整为未执行状态。

在确定目标消息的时候，可以响应于缓存队列中包括消息，从所述缓存队列的头部读取消息，将读取的消息确定为目标消息，以及响应于缓存队列中不包括消息，将所述非缓存任务表中处于未执行状态的消息确定为目标消息。由此可以在缓存队列中没有消息的时候从非缓存任务表中获取未执行过的消息，可以避免由于缓存队列中丢失消息而导致的消息漏发。

在一些实施例中，利用为所述缓存队列预设容量。所述预设容量可以被设置为经验值。将所述预设容量设置为经验值既不会导致内存溢出，也不会导致数据吞吐率太低。

请参见图9，图9为本申请实施例示出的一种在缓存队列存储与读取消息的流程示意图。

如图9所示，在向缓存队列存储消息的时候，可以判断所述缓存队列的当前消息量是否小于预设容量，如果是，可以将待存储消息写入所述缓存队列，如果否，则消息写入失败。由于该待存储消息始终要写入非缓存任务表，后续还是会被执行。

在从缓存队列读取消息的时候，可以判断所述缓存队列的当前消息量是否大于0，如果是，可以从缓存队列中读取消息，如果否，则读取消息失败。后续从非缓存任务表中读取未执行过的消息，以进行消息发送。

在确定目标消息之后，可以通过S202-S206进行消息发送。

在一些实施例中，所述用户集合压缩数据与预设类型对象中的每一对象关联存储；所述目标消息对应于所述预设类型对象中的目标对象。在S202中，可以从与每一所述对象关联存储的用户集合压缩数据中，获取与所述目标对象关联存储的目标用户集合压缩数据。

以推送歌手新专辑为例。在一些方式中，可以参照S602-S610示出的方法确定每一所述歌手分别对应的最终用户集合，然后通过S802-808记载的压缩存储方法，针对每一所述歌手，将所述歌手对应的最终用户集合压缩为用户集合压缩数据，并与所述歌手关联存储。

在目标歌手发布新专辑后，可以获取与所述目标歌手关联存储的目标用户集合压缩数据。

之后在S204中，可以对所述用户集合压缩数据进行解压，得到目标用户集合。关于解压的步骤可以参照前述实施例，在此不做详述。

之后在S206中，可以响应于所述目标消息的类型为私信，根据所述目标用户集合内的用户的用户标识，向与所述用户标识关联的账户发送所述目标消息；以及响应于所述目标消息的类型为PUSH消息，根据所述目标用户集合内的用户的用户标识，从缓存的第一副表中获取所述用户对应的预设类型数据，向与所述预设类型数据指示的终端设备发送所述目标消息。

目标消息可以包括私信消息与PUSH消息两种类型。

PUSH消息，是指需要主动发送至用户移动设备(手机、PAD等设备)的消息。用户可以在移动设备锁定屏幕和/或通知栏看到Push消息，在通知栏点击该消息通知时可唤起应用程序并跳转到指定页面。

私信消息(Private message)，是指需要发送至应用程序内的消息。私信消息也是消息通知的一种，与Push消息相比主要有以下几点不同：1、Push消息是发送到移动设备(例如通知栏)，而私信消息是发送至应用程序的内部页面；2、Push消息需要设备的唯一标识(例如设备Token)来精准的定位发送到哪一个设备，而私信消息只需要用户唯一标识(例如用户ID)；3、Push消息需要调用手机厂商的Push消息推送接口才能发送消息，并且发送频率和发送速度都要受到手机厂商接口规范的制约，而私信消息不需要调用手机厂商服务接口，因此无此类频控限制；4、私信消息只有用户打开应用程序时候才能看到私信消息，而Push消息不需要用户打开App在设备通知栏就能收到通知。综上，PUSH消息的曝光度更高更加及时，效果更好。

在S206中，可以先确定目标消息的消息类型，如果为私信消息，则可以根据目标用户集合内的用户的用户标识，即可将所述目标消息发送给的登录用户标识指示的用户账户的客户端应用程序。

如果为PUSH消息，则可以查询第一副表，所述第一副表存储了用户标识与预设类型数据的对应关系，获取与目标用户集合内的用户的用户标识对应的设备Token信息，然后通过与手机厂商服务端进行交互，将所述消息发送至所述设备Token指示的设备终端的通知栏中。

在一些实施例中，所述目标消息存储于非缓存任务表；所述非缓存任务表包括所述目标消息的执行状态；在向所述目标用户集合内的用户发送所述目标消息之后，还包括：将所述目标消息对应的执行状态更新为已执行状态。由此在发送目标消息后，保证所述目标消息的执行状态未已执行。

以歌手新专辑推送场景为例。请参见图10，图10为本申请实施例示出的一种发送消息的方法流程示意图。

如图10所示，第1步，在歌手A发布新专辑后，运营人员可以通过客户端程序生成歌手A发布新专辑的消息1，并将所述消息发送给发送节点。

第2步，发送节点可以通过接收线程池将所述消息1发送至第一Mysql的任务列表中进行存储，并将所述消息1的执行状态更新为未执行。

第3步，发送节点可以通过接收线程池将所述消息1发送至消息队列的尾端进行存储。

第4步，发送节点可以通过调度线程池，响应于所述消息队列包括消息，可以从所述消息队列的头部获取消息，并将获取的消息确定为目标消息，以及响应于所述消息队列不包括任何消息，从任务表中获取未执行过的消息作为目标消息。

假设本步骤中从所述消息队列的头部获取到消息1。

第5步，发送节点可以根据所述歌手A的歌手ID，通过调度线程池，从第二Mysql中获取目标用户集合压缩数据，并对该数据进行解压，得到目标用户集合。

第6步，发送节点可以判断消息1的类型，如果为PUSH消息，可以从第一副表获取目标用户的目标设备token，并执行第7步，与手机厂商服务端交互，将消息1推送到目标设备token指示的用户终端的通知栏，如果所述消息1为私信消息，则直接发送给的登录目标用户账号的客户端程序中。

第8步，完成消息发送后，可以将任务表中消息1的执行状态更新为已执行状态。

下面结合图1的应用场景，进行实施例说明。需要注意的是，前述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施例在此方面不受任何限制。相反，本申请的实施例可以应用于适用的任何场景。

以下结合歌手新专辑推送场景进行说明。该场景中用户使用的应用程序可以为音乐APP。

本申请中与图1示出的场景对应的系统称为消息推送系统。所述信息推送系统可以由预处理子系统与发送子系统构成。其中预处理子系统通过包括的硬件设备实现图1中的用户集合的确定与存储的过程，发送子系统通过包括的硬件设备实现图1中的发送消息的过程。所述硬件设备可以是笔记本电脑，计算机，手机，PDA(Personal DigitalAssistant，个人数字助理终端)等。在本申请中不限定这些硬件设备的具体类型。

以下介绍预处理子系统实现用户集合的确定与存储的过程。该过程也可以被称为预处理。所述预处理中可以分为相互解耦的数据离线同步与用户集合的确定与压缩存储。

用户在使用音乐APP时候会产出很多运营数据，比如，用户注册时会被分配用户ID，用户会被分配设备token，用户还会关注歌手，会购买专辑，会开启或关闭消息推送功能，给歌曲点赞，转发歌曲等，以上运营数据被存储在关系型源数据表中，形成图1示意的数据源。

在数据离线同步中，响应于源数据表存储增量运营数据，会判断增量运营数据的类型，并根据所述类型，将所述增量运营数据存储在相应的副表，形成图1示意的数据副本。这些副表为离线表，不会被音乐APP直接使用。

比如，如果增量运营数据是设备token，则将该运营数据和该运营数据(设备token)指示的用户ID关联存储在第一副表中。所述第一副表存储在缓存中，由此便于后续根据用户ID可以快速查询关联的设备token信息，提升消息发送效率。

比如，如果增量运营数据是关注歌手数据，可以将该运营数据存储在歌手粉丝表中。

以上数据同步方法的具体步骤可以参见S402-S408和图5示意的流程，在此不做详述。

用户集合的确定与压缩存储是被周期性触发的。在预处理子系统中可以设置时钟，每已经过预设时长可以触发执行用户集合的确定与压缩存储。所述预设时长可以根据触发频次设定。

请参见图11，图11为本申请实施例示出的一种用户集合的确定与压缩存储的方法的方法流程图。如图11所示，所述方法可以包括S1101-S1103。除特别说明外，本申请不特别限定这些步骤的执行顺序。

S1101，从副表中，获取歌手粉丝表，歌手专辑表，购买专辑用户表以及推送功能状态表。

S1102，针对音乐APP中维护的每一歌手，确定与每一歌手分别对应的用户集合；

本步骤中，可以将每一歌手分别作为当前歌手，然后执行：

根据当前歌手的歌手ID，查询歌手粉丝表，获取关注该当前歌手的第一用户，形成第一用户集合；

根据当前歌手的歌手ID，查询歌手专辑表，确定当前歌手发布过的专辑，并查询购买专辑用户表，获取购买过当前歌手发布过的专辑的第二用户，形成第二用户集合；

合并第一用户集合与第二用户集合得到第四用户集合；

查询推送功能状态表，获取关闭消息推送功能的第三用户，形成第三用户集合；

在第四用户集合中，删除第三用户集合中的第三用户，得到与所述当前歌手对应的最终用户集合。该集合中包括很多是当前歌手粉丝或买过当前歌手专辑，并且开启消息推送功能的用户的用户ID。

S1103，针对音乐APP中维护的每一歌手，将所述歌手对应的用户集合进行压缩，并与所述歌手ID关联存储。

本步骤中可以采用咆哮位图压缩算法。所述预处理子系统中可以为每一歌手分配一段存储空间。所述存储空间中包括65536个数据桶，数据桶的编号从0至65535。所述用户ID可以为32位的2进制数。

利用咆哮位图压缩存储用户集合的方法可以参照前述S802-S808，在此不做详述。完成压缩存储后，与歌手对应的用户集合会被压缩为用户集合压缩数据，存储在为歌手分配的存储空间中，完成关联存储。

以下介绍发送子系统实现发送消息的过程。该过程可以包括相互解耦的生成消息和发送消息两个子过程。

以目标歌手发布新专辑为例。

在目标歌手发布新专辑后，运营人员可以通过自身对应的客户端程序生成目标歌手发布新专辑的消息，然后将该消息存储在缓存队列的尾部，与任务列表中。所述任务列表存储在非易失存储器中，并且维护了消息的执行状态。

发送子系统可以在消息队列有消息的时候从消息队列的头部获取消息作为待发送的目标消息，在消息队列没有消息的时候，从任务列表获取未执行过的消息作为目标消息，并发送所述目标消息。

以获取到目标歌手发布新专辑的目标消息为例。

请参见图12，图12为本申请实施例示出的一种发送目标消息的方法的方法流程图。如图12所示，所述方法可以包括S1201-S1204。除特别说明外，本申请不特别限定这些步骤的执行顺序。

S1201，从与目标歌手对应的存储空间中，获取为所述目标歌手确定的目标用户集合的压缩数据。

S1202，对所述压缩数据进行解压，得到与目标歌手对应的目标用户集合。

该目标集合中包括解压得到的目标用户的用户ID。

确定目标消息的消息类型，S1203，如果所述目标消息为PUSH消息，可以根据所述目标用户的用户ID查询缓存的第一副表，获取与所述目标用户的手机终端对应的设备Token，并通过该Token与手机终端厂商服务端进行交互，以将所述目标消息推送到手机终端的通知栏。

S1204，如果所述目标消息为私信消息，可以根据所述目标用户的用户ID，将所述目标消息发送到登录所述用户ID的音乐APP中。

在前述歌手新专辑推送场景中，第一，过将用户集合的确定和存储过程与目标消息的发送过程进行解耦，可以预先完成用户集合的确定与存储，不仅可以降低确定与存储用户集合的频次，从而降低对应用程序功能的影响，而且可以提升目标用户集合的获取效率，降低延迟，达到近乎实时发送消息的效果。

第二，可以利用数据副本确定用户集合，不仅降低了数据查询量，提升用户数据查询效率，降低延迟，而且可以将确定用户集合依赖的数据源，与应用程序运行过程依赖的数据源隔离开，降低对应用程序运行产生的影响。

第三，可以以咆哮位图形式对用户集合进行压缩存储，不仅可以降低数据所需存储空间，而且可以提升数据安全性。

示例性装置

在介绍了本申请示例性实施例的方法之后，接下来，参考图13对本申请示例性公开的发送消息的装置进行说明。该发送消息的装置可以应用于发送消息系统，用于实现前述任一实施例示出的发送消息的方法。

请参见图13，图13为本申请实施例示出的一种发送消息的装置的结构示意图。

如图13所示，发送消息的装置1300可以包括：

获取模块1310，用于从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据；

解压模块1320，用户解压所述目标用户集合压缩数据，得到目标用户集合；

发送模块1330，用于向所述目标用户集合内的用户发送所述目标消息；

存储模块1340，用于存储所述用户集合压缩数据；所述存储模块1340包括：

选取模块1341，用于从源数据表对应的副表中，选取与确定用户集合相关的预设副表；所述源数据表包含应用程序在运行过程中依赖的用户数据，所述副表由所述源数据表存储的至少部分用户数据离线同步生成；

筛选模块1342，用于根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户以生成用户集合；

压缩存储模块1343，用于对所述用户集合进行压缩存储。

在一些实施例中，所述副表包括存储在缓存中的第一副表与存储在非缓存的第二副表，所述第一副表用于存储发送所述目标消息依赖的预设类型数据，所述第二副表用于存储非预设类型数据。

在一些实施例中，所述装置1300还包括生成模块，用于离线同步生成副表；所述生成模块具体用于：

响应于源数据表存储增量数据，将包含所述增量数据的日志信息同步至消息队列；

从所述消息队列中读取所述日志信息并进行解析；

在所述日志信息包含的增量数据包含所述预设类型数据的情形下，将所述增量数据转发至所述第一副表进行存储；

在所述日志信息包含的增量数据不包含所述预设类型数据的情形下，将所述增量数据转发至所述第二副表进行存储。

在一些实施例中，所述生成模块具体用于：

通过预设的第一节点将所述增量数据写入日志信息；所述第一节点与第二节点建立通信连接；

通过所述第二节点获取所述日志信息，并将所述日志信息发送至消息队列。

在一些实施例中，所述筛选模块1342，具体用于：

响应于当前时刻与上一次筛选出所述目标用户的时刻之间的时长达到预设时长，查询所述预设副表存储的用户数据，得到满足预设用户筛选条件的用户以生成用户集合。

在一些实施例中，所述预设副表包括第一预设副表，第二预设副表与第三预设副表；其中，所述第一预设副表用于存储关注预设类型对象的第一用户数据；所述第二预设副表用于存储购买过所述预设类型对象关联产品的第二用户数据；所述第三预设副表用于存储关闭和打开消息发送功能的第三用户数据；

所述预设用户筛选条件包括关注所述预设类型对象或购买过所述预设类型对象关联产品，并且打开消息发送功能；

所述筛选模块1342，具体用于：

针对所述预设类型对象中的每一对象：

查询所述第一预设副表中的所述第一用户数据，得到关注所述对象的第一用户集合；

查询所述第二预设副表中的所述第二用户数据，得到购买过所述对象关联产品的第二用户集合；

将所述第一用户集合与所述第二用户集合进行合并得到第四用户集合；

查询所述第三预设副表中的所述第三用户数据，得到关闭消息发送功能的第三用户集合；

在所述第四用户集合中删除所述第三用户集合包含的用户，得到与所述对象对应的最终用户集合。

在一些实施例中，所述压缩存储模块1343，具体用于：

针对每一所述对象，利用预设压缩算法对所述对象对应的最终用户集合进行压缩处理，得到用户集合压缩数据，以及，

将所述用户集合压缩数据与所述对象关联存储。

在一些实施例中，所述压缩存储模块1343，具体用于：

针对所述最终用户集合内的每一最终用户执行以下步骤：

获取所述最终用户对应的用户标识；

将所述用户标识转换为预设进制数；

根据所述预设进制数包括的前N位数字，在为所述对象预先分配的多个数据桶中，确定所述最终用户对应的目标数据桶；

将所述预设进制数的剩余数字存储至所述目标数据桶。

在一些实施例中，所述压缩存储模块1343，具体用于以下至少一种方式：

响应于所述最终用户集合内包含的最终用户数量未达到预设阈值，将所述预设进制数的剩余数字以数组格式存储至所述目标数据桶；所述目标数据桶的类型默认为数组类型；

响应于所述最终用户集合内包含的最终用户数量达到预设阈值，将所述目标数据桶的类型转换为位图类型，将所述剩余数字组成的数值转换为十进制数，将所述位图中与所述十进制数对应的位置设置为预设值。

在一些实施例中，所述装置1300还包括验证数据获取模块，用于在将所述用户集合压缩数据与所述对象关联存储之前，获取验证所述预设压缩算法所需的验证数据；所述验证数据包含以下至少一项：采样数据对，所述采样数据对包括从用户集合获取的采样用户的采样标识，以及对利用所述预设压缩算法对所述采样标识进行压缩得到的压缩数据；所述用户集合包含的用户数量；

所述压缩存储模块1343，具体用于：

将所述用户集合压缩数据和所述验证数据，与所述对象关联存储。

在一些实施例中，所述装置1300还包括：

明文存储模块，用于将所述最终用户集合以明文形式存储至离线数据库以进行数据追踪。

在一些实施例中，所述装置1300还包括消息生成模块，用户在从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据之前，响应于消息生成请求，生成消息；将所述消息发送至缓存队列与非缓存任务表中分别进行存储。

在一些实施例中，所述装置1300该包括确定模块，用于确定目标消息；所述确定模块具体用于：

响应于缓存队列中包括消息，将所述缓存队列中包括的消息确定为目标消息；

响应于缓存队列中不包括消息，将非缓存任务表中未执行过的消息确定为目标消息。

在一些实施例中，所述非缓存任务表中包括了消息的执行状态；

所述消息生成模块，具体用于：

将所述消息发送至所述缓存队列的队尾进行存储，以及，

将所述消息发送非缓存任务表中，并将所述消息的执行状态调整为未执行状态；

所述确定模块具体用于：

响应于缓存队列中包括消息，从所述缓存队列的头部读取消息，将读取的消息确定为目标消息；

响应于缓存队列中不包括消息，将所述非缓存任务表中处于未执行状态的消息确定为目标消息。

在一些实施例中，所述用户集合压缩数据与预设类型对象中的每一对象关联存储；所述目标消息对应于所述预设类型对象中的目标对象；

所述获取模块1310，具体用于：

从与每一所述对象关联存储的用户集合压缩数据中，获取与所述目标对象关联存储的目标用户集合压缩数据。

在一些实施例中，所述发送模块1330，具体用于：

响应于所述目标消息的类型为私信，根据所述目标用户集合内的用户的用户标识，向与所述用户标识关联的账户发送所述目标消息；

响应于所述目标消息的类型为PUSH消息，根据所述目标用户集合内的用户的用户标识，从缓存的第一副表中获取所述用户对应的预设类型数据，向与所述预设类型数据指示的终端设备发送所述目标消息；所述第一副表存储了用户标识与预设类型数据的对应关系。

在一些实施例中，所述目标消息存储于非缓存任务表；所述非缓存任务表包括所述目标消息的执行状态；所述装置1300还包括更新模块，用于在向所述目标用户集合内的用户发送所述目标消息之后，将所述目标消息对应的执行状态更新为已执行状态。

在前述记载的技术方案中，第一，通过将用户集合的确定和存储过程与目标消息的发送过程进行解耦，可以预先完成用户集合的确定与存储，与相关技术相比，不仅可以降低确定与存储用户集合的频次，从而降低对应用程序功能的影响，而且可以提升目标用户集合的获取效率，降低延迟，达到近乎实时发送消息的效果；

第二，可以利用源数据表包含的至少部分数据离线同步生成副表，然后在从副表中选取与确定用户集合相关的预设副表，并根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户，形成用户集合，与相关技术相比，不仅不需要查询存储完整数据的源数据表，降低了数据查询量，从而提升用户数据查询效率，降低延迟，而且可以将确定用户集合依赖的数据源，与应用程序运行过程依赖的数据源隔离开，降低对应用程序运行产生的影响。

第三，对确定的用户集合进行压缩存储，与相关技术相比，不仅可以降低数据所需存储空间，而且可以提升数据安全性。

示例性介质

在介绍了本申请示例性实施例的方法和装置之后，接下来，参考图14对本申请示例性公开的一种可读存储介质进行说明。所述存储介质存储有计算机程序，所述计算机程序用于使处理器执行如前述任一实施例示出发送消息的方法。

请参见图14，图14为本申请实施例示出的一种应用于发送消息的方法的程序产品1400。

在示出的一些实施例中，可以通过程序产品实现前述发送消息的方法，如可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在设备，例如个人电脑上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

该程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者前述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或前述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RE等等，或者前述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如C语言或类似的程序设计语言。程序代码可以完全地在用户电子设备上执行、部分在用户电子设备上部分在远程电子设备上执行、或者完全在远程电子设备或服务器上执行。在涉及远程电子设备的情形中，远程电子设备可以通过任意种类的模型，包括局域网(LAN)或广域网(WAN)，连接到用户电子设备，或者，可以连接到外部电子设备(例如利用因特网服务提供商来通过因特网连接)。

示例性电子设备

在介绍了本申请示例性实施例的方法、装置和介质之后，接下来，参考图15对本申请示例性公开的一种电子设备进行说明。所述设备包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器通过运行所述可执行指令以实现如前述任一实施例示出的发送消息的方法。

请参见图15，图15为本申请实施例示出的一种电子设备的结构示意图。

图15显示的电子设备1500仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图15所示，电子设备1500以通用电子设备的形式表现。电子设备1500的组件可以包括但不限于：前述至少一个处理器1501、前述至少一个存储处理器1502，连接不同系统组件(包括处理器1501和存储处理器1502)的总线1503。

总线1503包括数据总线、控制总线和地址总线。

存储处理器1502可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)15021和/或高速缓存存储器15022，可以进一步包括非易失性存储器形式的可读介质，例如只读存储器(ROM)15023。

存储处理器1502还可以包括具有一组(至少一个)程序模块15024的程序/实用工具15025，这样的程序模块15024包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括模型环境的实现。

电子设备1500也可以与一个或多个外部设备1504(例如键盘、指向设备等)通信。

这种通信可以通过输入/输出(I/O)接口1505进行。并且，电子设备1500还可以通过模型适配器1506与一个或者多个模型(例如局域网(LAN)，广域网(WAN)和/或公共模型，例如因特网)通信。如图15所示，模型适配器1506通过总线1503与电子设备1500的其它模块通信。应当理解，尽管图中未示出，可以结合电子设备1500使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

应当注意，尽管在上文详细描述中提及了发送消息的装置的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施例，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施例描述了本申请的精神和原理，但是应该理解，本申请并不限于所公开的具体实施例，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本申请旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (10)

1.一种发送消息的方法，其特征在于，所述方法包括：

从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据；

解压所述目标用户集合压缩数据，得到目标用户集合；

向所述目标用户集合内的用户发送所述目标消息；

所述用户集合压缩数据的存储方法包括：

从源数据表对应的副表中，选取与确定用户集合相关的预设副表；所述源数据表包含应用程序在运行过程中依赖的用户数据，所述副表由所述源数据表存储的至少部分用户数据离线同步生成；

根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户以生成用户集合；

对所述用户集合进行压缩存储。

2.根据权利要求1所述方法，其特征在于，所述副表包括存储在缓存中的第一副表与存储在非缓存的第二副表，所述第一副表用于存储发送所述目标消息依赖的预设类型数据，所述第二副表用于存储非预设类型数据。

3.根据权利要求1所述方法，其特征在于，所述根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户以生成用户集合，包括：

响应于当前时刻与上一次筛选出所述目标用户的时刻之间的时长达到预设时长，查询所述预设副表存储的用户数据，得到满足预设用户筛选条件的用户以生成用户集合。

4.根据权利要求1所述的方法，其特征在于，所述预设副表包括第一预设副表，第二预设副表与第三预设副表；其中，所述第一预设副表用于存储关注预设类型对象的第一用户数据；所述第二预设副表用于存储购买过所述预设类型对象关联产品的第二用户数据；所述第三预设副表用于存储关闭和打开消息发送功能的第三用户数据；

所述预设用户筛选条件包括关注所述预设类型对象或购买过所述预设类型对象关联产品，并且打开消息发送功能；

所述根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户以生成用户集合，包括：

针对所述预设类型对象中的每一对象：

查询所述第一预设副表中的所述第一用户数据，得到关注所述对象的第一用户集合；

查询所述第二预设副表中的所述第二用户数据，得到购买过所述对象关联产品的第二用户集合；

将所述第一用户集合与所述第二用户集合进行合并得到第四用户集合；

查询所述第三预设副表中的所述第三用户数据，得到关闭消息发送功能的第三用户集合；

在所述第四用户集合中删除所述第三用户集合包含的用户，得到与所述对象对应的最终用户集合。

5.根据权利要求1所述方法，其特征在于，所述用户集合压缩数据与预设类型对象中的每一对象关联存储；所述目标消息对应于所述预设类型对象中的目标对象；

所述从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据，包括：

从与每一所述对象关联存储的用户集合压缩数据中，获取与所述目标对象关联存储的目标用户集合压缩数据。

6.根据权利要求1所述方法，其特征在于，所述向所述目标用户集合内的用户发送所述目标消息，包括：

响应于所述目标消息的类型为私信，根据所述目标用户集合内的用户的用户标识，向与所述用户标识关联的账户发送所述目标消息；

响应于所述目标消息的类型为PUSH消息，根据所述目标用户集合内的用户的用户标识，从缓存的第一副表中获取所述用户对应的预设类型数据，向与所述预设类型数据指示的终端设备发送所述目标消息；所述第一副表存储了用户标识与预设类型数据的对应关系。

7.根据权利要求1所述方法，其特征在于，所述目标消息存储于非缓存任务表；所述非缓存任务表包括所述目标消息的执行状态；在向所述目标用户集合内的用户发送所述目标消息之后，还包括：

将所述目标消息对应的执行状态更新为已执行状态。

8.一种发送消息的装置，其特征在于，所述装置包括：

获取模块，用于从存储的用户集合压缩数据中，获取与待发送的目标消息对应的目标用户集合压缩数据；

解压模块，用户解压所述目标用户集合压缩数据，得到目标用户集合；

发送模块，用于向所述目标用户集合内的用户发送所述目标消息；

存储模块，用于存储所述用户集合压缩数据；所述存储模块包括：

选取模块，用于从源数据表对应的副表中，选取与确定用户集合相关的预设副表；所述源数据表包含应用程序在运行过程中依赖的用户数据，所述副表由所述源数据表存储的至少部分用户数据离线同步生成；

筛选模块，用于根据所述预设副表存储的用户数据，筛选出满足预设用户筛选条件的用户以生成用户集合；

压缩存储模块，用于对所述用户集合进行压缩存储。

9.一种电子设备，其特征在于，所述设备包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现如权利要求1-7任一所述的发送消息的方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序用于使处理器执行如权利要求1-7任一所述的发送消息的方法。

Images