一种消息推送方法、装置和存储介质与流程

1.本发明涉及社交媒体消息推送领域，尤其涉及一种消息推送方法、装置和存储介质。


背景技术：

2.微博现有消息推送(push)场景主要依托两类计算场景下发：
3.离线推送：由于所有用户的总数量巨大，所以在现有技术中的离线混排系统中，将所有用户分为若干个用户包；以每个固定时间间隔处理一个用户包的方式，按固定时间间隔依次处理每个用户包，针对在该固定时间间隔内接收到的针对该用户包内的用户的所有推送消息，择优选择发送给相应的用户；由于每个用户只能在固定用户包中存在，所以每次全量用户计算需要一定周期即固定时间间隔，造成离线推送即时性较差，但优点是择优下发，推送内容质量相对较高；现有场景主要通过spark完成离线计算并推送，离线任务笨重且消耗资源大，每小时才完成全部用户的覆盖，用户下发时效性低。
4.直发推送：基于场景或用户行为实时计算并下发推送消息，由于不参与算法竞争且实时计算，直发推送下发时效性较好，但缺点是内容质量不易保证。直发推送下发到用户时效性高，但是效果不可控，只能通过一些先验经验判断当前物料质量。
5.在实现本发明过程中，申请人发现现有技术中至少存在如下问题：
6.现有的离线推送时效性差，直发推送内容质量不易保证。


技术实现要素：

7.本发明实施例提供一种消息推送方法、装置和存储介质，解决现有的离线推送时效性差，直发推送内容质量不易保证的问题。
8.为达上述目的，第一方面，本发明实施例提供一种消息推送方法，包括：
9.在接收到发送给目标用户的待推送消息时，判断所述目标用户是否存在推送时间窗口；
10.在判定所述目标用户不存在推送时间窗口的情况下，以接收到所述待推送消息的时间点为起点创建所述目标用户对应的推送时间窗口；
11.将在所述推送时间窗口内接收到的、发送给所述目标用户的所有待推送消息添加到所述推送时间窗口对应的推送消息集合中；
12.当所述推送时间窗口结束时，从所述推送消息集合中选择符合预设条件的待推送消息作为目标推送消息，并将所述目标推送消息发送给所述目标用户。
13.进一步地，所述待推送消息由业务方发送给所述目标用户，所述业务方包括多个；所述待推送消息包括由业务方发送给目标用户的慢速推送消息和/或直发推送消息，其中，所述慢速推送消息通过配置的慢速消息通道接收，所述直发推送消息通过配置的直发消息通道接收。
14.进一步地，所述从所述推送消息集合中选择符合预设条件的待推送消息作为目标
推送消息，包括：
15.根据所述推送消息集合中每个待推送消息对应的预测点击率，将所述预测点击率大于或等于预设点击率阈值的待推送消息作为目标推送消息；或者，将所述预测点击率最大的设定条数的待推送消息作为目标推送消息。
16.进一步地，所述将所述目标推送消息发送给所述目标用户，包括：
17.根据周期性更新的全量日活用户列表判断所述目标用户是否为日活用户；其中，所述日活用户是指当日存在活动操作的用户；
18.在判定所述目标用户是日活用户的情况下，将所述目标推送消息进行混排后通过第一推送通道发送给所述目标用户；
19.在判定所述目标用户不是日活用户的情况下，将所述目标推送消息进行混排后通过第二推送通道发送给所述目标用户；
20.其中，所述第二推送通道的消息触达率大于所述第一推送通道的消息触达率。
21.进一步地，所述根据周期性更新的全量日活用户列表判断所述目标用户是否为日活用户，包括：
22.使用布隆过滤器检索所述目标用户是否记录于所述全量日活用户列表；
23.在检索出所述目标用户记录于所述全量日活用户列表的情况下，判定所述目标用户为日活用户；
24.在检索出所述目标用户没有记录于所述全量日活用户列表的情况下，判定所述目标用户不是日活用户。
25.进一步地，所述将所述目标推送消息发送给所述目标用户，包括：
26.通过flink文件流的方式读取存储在hdfs中的所述目标用户的用户相关信息；其中，各用户的用户相关信息预先以parquet格式存储在所述hdfs中；
27.将所述目标推送消息发送给与读取到的所述用户相关信息相对应的所述目标用户。
28.第二方面，本发明实施例提供一种消息推送装置，包括：
29.消息接收单元，用于在接收到发送给目标用户的待推送消息时，判断所述目标用户是否存在推送时间窗口；
30.时间窗口创建单元，用于在判定所述目标用户不存在推送时间窗口的情况下，以接收到所述待推送消息的时间点为起点创建所述目标用户对应的推送时间窗口；
31.推送消息收集单元，用于将在所述推送时间窗口内接收到的、发送给所述目标用户的所有待推送消息添加到所述推送时间窗口对应的推送消息集合中；
32.推送消息发送单元，用于当所述推送时间窗口结束时，从所述推送消息集合中选择符合预设条件的待推送消息作为目标推送消息，并将所述目标推送消息发送给所述目标用户。
33.进一步地，所述待推送消息由业务方发送给所述目标用户，所述业务方包括多个；所述待推送消息包括由业务方发送给目标用户的慢速推送消息和/或直发推送消息，其中，所述慢速推送消息通过配置的慢速消息通道接收，所述直发推送消息通过配置的直发消息通道接收。
34.进一步地，所述推送消息发送单元，包括：
35.第一目标推送消息优选模块，用于根据所述推送消息集合中每个待推送消息对应的预测点击率，将所述预测点击率大于或等于预设点击率阈值的待推送消息作为目标推送消息；或者，将所述预测点击率最大的设定条数的待推送消息作为目标推送消息。
36.进一步地，所述推送消息发送单元，包括：
37.第一日活用户判断模块，用于根据周期性更新的全量日活用户列表判断所述目标用户是否为日活用户；其中，所述日活用户是指当日存在活动操作的用户；
38.第一发送模块，用于在判定所述目标用户是日活用户的情况下，将所述目标推送消息进行混排后通过第一推送通道发送给所述目标用户；
39.第二发送模块，用于在判定所述目标用户不是日活用户的情况下，将所述目标推送消息进行混排后通过第二推送通道发送给所述目标用户；
40.其中，所述第二推送通道的消息触达率大于所述第一推送通道的消息触达率。
41.进一步地，所述第一日活用户判断模块，包括：
42.检索模块，用于使用布隆过滤器检索所述目标用户是否记录于所述全量日活用户列表；
43.第二日活用户判断模块，用于在检索出所述目标用户记录于所述全量日活用户列表的情况下，判定所述目标用户为日活用户；在检索出所述目标用户没有记录于所述全量日活用户列表的情况下，判定所述目标用户不是日活用户。
44.进一步地，所述推送消息发送单元，包括：
45.用户信息获取模块，用于通过flink文件流的方式读取存储在hdfs中的所述目标用户的用户相关信息；其中，各用户的用户相关信息预先以parquet格式存储在所述hdfs中；
46.推送消息发送模块，用于将所述目标推送消息发送给与读取到的所述用户相关信息相对应的所述目标用户。
47.第三方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面中任一项所述的方法。
48.上述技术方案具有如下有益效果：通过为用户开启推送时间窗口，收集在推送时间窗口内收到的针对该用户的推送消息，并在推送时间窗口结束时从收集的推送消息中择优发送给该用户，相对于离线推送提高了实时性，相对于直发推送提高了推送消息的内容质量，从而在时效性方面和内容质量两个方面相互平衡提高用户体验。
附图说明
49.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
50.图1是本发明实施例之一的一种消息推送方法的流程图；
51.图2是本发明实施例之一的一种消息推送装置的架构图；
52.图3是现有技术下的基于socket的io吞吐统计示意图；
53.图4是本发明实施例之一的flink文件流代替socket后的io吞吐统计示意图。
具体实施方式
54.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
55.第一方面，如图1所示，本发明实施例提供一种消息推送方法，包括：
56.步骤s10，在接收到发送给目标用户待推送消息时，判断所述目标用户是否存在推送时间窗口；
57.步骤s11，在判定所述目标用户不存在推送时间窗口的情况下，以接收到所述待推送消息的时间点为起点创建所述目标用户对应的推送时间窗口；
58.步骤s12，将在所述推送时间窗口内接收到的、发送给所述目标用户的所有待推送消息添加到所述推送时间窗口对应的推送消息集合中；
59.步骤s13，当所述推送时间窗口结束时，从所述推送消息集合中选择符合预设条件的待推送消息作为目标推送消息，并将所述目标推送消息发送给所述目标用户。
60.在一些实施例中，提供了一种消息推送方法，该方法由消息推送装置采用，推送时间窗口的时间长度可以根据针对消息推送的实时性的具体需求确定，例如可以包括但不限于10分钟；考虑到现有技术中的离线混排按10分钟处理一批用户，全部用户共被分为6批，全部用户处理完需要一小时；本实施例针对每个用户创建了用户对应的推送时间窗口，各用户在自己的推送时间窗口内相互并行处理，所以本实施例显著提高了每个用户的消息推送的实时性。在同一个用户的推送时间窗口内可以接收到同一个业务方的一条或多条待推送消息也可以接收到多个不同业务方的待推送消息。预设条件根据具体需求合理设置，例如包括但不限于根据待推送消息的时效性、待推送消息的内容类别与用户行为特征的匹配程度、用户的兴趣范围等优选出一条或多条待推送消息作为目标推送消息，目标推送消息的数量可以根据具体需求限制设定，例如在某些需求下，为了保护用户体验，限定每个用户每天只能接收到10条推送消息，则可以将符合预设条件的目标推送消息的数量限定为1条，以选择推送时间窗口中最优的待推送消息发送给用户。
61.进一步地，所述待推送消息由业务方发送给所述目标用户，所述业务方包括多个；所述待推送消息包括由业务方发送给目标用户的慢速推送消息和/或直发推送消息；，其中，所述慢速推送消息通过配置的慢速消息通道接收，所述直发推送消息通过配置的直发消息通道接收。
62.在一些实施例中，慢速推送消息和直发推送消息按照在具体实施中对推送消息的时效要求定义，对于时效要求高，希望能尽快展示给用户的推送消息按直发推送消息处理，当推送消息时效要求低，可以延迟到达用户则按慢速推送消息处理。为了与已经部署运行的具有慢速推送消息和直发推送消息区分的系统进行对接，从而将业务方原来发送给离线混排系统处理的慢速消息转由本实施例实现的消息推送装置处理，本实施例通过慢速消息通道接收业务方原来向现有技术中的离线混排系统发送的慢速推送消息，通过直发消息通道接收业务方的直发推送消息。本实施例通过慢速消息通道接收来自各业务方的向目标用
户发送的慢速推送消息，慢速消息通道可以由消息队列实现，消息队列包括但不限于kafka；通过kafka实现消息队列接收慢速推送消息，适应慢速推送消息计算用户量大的问题，采用kafka实现高吞吐。通过直发消息通道接收来自各业务方的向目标用户发送的直发推送消息，直发消息通道可以由redis等实现，通过redis队列接收来自各业务方的向目标用户发送的直发推送消息，并由flink程序负责消费；通过提供基于消息队列的方式接收慢速推送消息，方便与以消息队列传递慢速推送消息的系统之间进行对接，代替现有技术中通过对用户包进行轮询处理慢速推送消息的方法，提高相关系统的慢速推送消息处理的实时性。通过基于redis接收直发推送消息，方便与基于redis的直发推送消息的系统对接，从而在预设条件的约束下提高直发推送消息的内容质量。当系统中存在来自业务方的慢速推送消息和直发推送消息时，通过本实施例可以将发送给同一用户的慢速推送消息和直发推送消息收集到一个推送时间窗口中，根据预设条件进行择优选择，从而对于慢速推送消息提高了处理的实时性，对于直发推送消息通过择优选择提高了目标推送消息的质量，从整体上改善了用户体验。优选地，由于直发推送消息下发效率快，占用用户每日下发额度，但质量不可控，业务方可以通过选择使用直发消息通道或旧有通道对直发推送消息进行分类处理，高优先级物料例如全量热点等直发业务，不进入实时混排仍然走旧有通道，对于效果相对不稳定的直发业务交由消息推送装置处理，在损失一定时效性的情况下，保证下发质量，同时避免用户下发额度快速占满，即减少了用户打开也提升了用户体验，减少了用户关闭开关的比例。相比与离线混排系统处理的慢速推送消息，本实施例通过合理设置推送时间窗口的时间长度，可以保证慢速推送消息及时按预设条件择优下发，例如，通过flinktimewindow实现uid粒度的10min窗口(相当于用户对应的推送时间窗口)，可以保证用户聚合10min内的uid-mid对并择优下发，相比于现有技术中的离线混排的小时级延迟，可以大大提高物料到达用户的时效性，而很多时效性高且高质量的微博也实现了获得更快到达用户侧的目的，提升了用户整体打开规模。经测试，单业务下发pv(即page view，页面浏览量)增加39.67％，点击pv增加57.08％，点击率提升12.46％，可以看到时效性的提升对优质物料的打开规模与点击率都有很明显的影响。其中，flinktimewindow是flink框架下的一个功能组件。
63.进一步地，所述从所述推送消息集合中选择符合预设条件的待推送消息作为目标推送消息，包括：
64.根据所述推送消息集合中每个待推送消息对应的预测点击率，将所述预测点击率大于或等于预设点击率阈值的待推送消息作为目标推送消息；或者，将所述预测点击率最大的设定条数的待推送消息作为目标推送消息。
65.在一些实施例中，预设条件可以基于点击率(即ctr，click-through-rate)进行定义，优选地，该点击率可以为预测点击率，即针对该待推送消息的预测的用户点击率。预测点击率可以通过多种方式获得，例如消息推送装置根据待推送消息的内容对收到的待推送消息进行预测分析得到预测点击率；再例如业务方推送uid-mid(其中，uid为用户id，mid为消息id)待推送消息到消息推送装置时，还推送了该待推送消息对应的预测点击率，即除了接收来自各业务方的向目标用户发送的待推送消息外，还接收与所述待推送消息对应的预测点击率；预设条件可以定义为当待推送消息对应的点击率大于或等于预设点击率阈值时将该待推送消息作为目标推送消息推送给用户，否则禁止将该待推送消息推送给用户，此
时目标推送消息可能包含一个或多个待推送消息。例如点击率的取值区间可以为[0,1],而预设点击率阈值为0.005，那么对于预测点击率《0.005的待推送消息会被系统过滤，即过滤一部分低质量推送，禁止对用户下发，保证用户接收到的目标推送消息的具有较高质量。预设条件还可以定义为选择预测点击率最大的待推送消息作为目标推送消息，此时目标推送消息只包含一条待推送消息。在具体实施中，上述两种预设条件可以同时实施或只实施其中一种，当同时实施时，可以通过动态配置或配置文件的方式选定当前具体使用的预设条件。其中，uid表示用户唯一标识，mid表示消息唯一标识，uid-mid表示待推送消息与用户之间的对应关系。当目标推送消息为多条时，可以根据各目标推送消息的预测点击率对目标推送消息进行排序，并按预测点击率从高到低的顺序发送目标推送消息。
[0066]
进一步地，所述将所述目标推送消息发送给所述目标用户，包括：
[0067]
根据周期性更新的全量日活用户列表判断所述目标用户是否为日活用户；其中，所述日活用户是指当日存在用户操作的用户；
[0068]
在判定所述目标用户是日活用户的情况下，将所述目标推送消息进行混排后通过第一推送通道发送给所述目标用户；优选地，在判定所述目标用户是日活用户的情况下，将所述目标推送消息通过第一推送通道按所述目标推送消息对应的预测点击率从高到低的顺序发送给所述目标用户；
[0069]
在判定所述目标用户不是日活用户的情况下，将所述目标推送消息进行混排后通过第二推送通道发送给所述目标用户；优选地，在判定所述目标用户不是日活用户的情况下，将所述目标推送消息通过第二推送通道按所述目标推送消息对应的预测点击率从高到低的顺序发送给所述目标用户；
[0070]
其中，所述第二推送通道的消息触达率大于所述第一推送通道的消息触达率。
[0071]
在一些实施例中，日活用户就是当前日中存在点击、浏览等活动操作的用户，代表了用户的活跃程度。获取用户dau(即dailyactiveuser)状态，根据用户当日不同状态进行决策并将目标推送消息传递给下游，下游可以是与用户对接的后台服务，也可以是用户，若用户是日活用户，则主要提高下发阈值，向用户下发高质量的目标推送消息，优化用户体验；若用户不是日活用户，则主要优化下发通道，选择触达率高的下发通道，提升触达效率，争取将用户转变为日活用户。预设条件根据具体需求合理设置，例如包括但不限于根据待推送消息的时效性、待推送消息的内容类别与用户行为特征的匹配程度、用户的兴趣范围等优选出一条或多条待推送消息作为目标推送消息，目标推送消息的数量可以根据具体需求限制设定，例如在某些需求下，为了保护用户体验，限定每个用户每天只能接收到10条推送消息，则可以将符合预设条件的目标推送消息的数量限定为1条，以选择推送时间窗口中最优的待推送消息发送给用户；优选地，预设条件可以基于点击率(即ctr，click-through-rate)进行定义，业务方推送uid-mid(其中，uid为用户id，mid为消息id)待推送消息到消息推送装置时，还推送了该待推送消息对应的用户预测点击率，即除了接收来自各业务方的向目标用户发送的待推送消息外，还接收与所述待推送消息对应的点击率，优选地，该点击率可以为用户预测点击率，即针对该待推送消息的预测的用户点击率。预设条件可以定义为当待推送消息对应的点击率大于或等于预设点击率阈值时将该待推送消息作为目标推送消息推送给用户，否则禁止将该待推送消息推送给用户，此时目标推送消息可能包含一个或多个待推送消息。例如点击率的取值区间可以为[0,1],而预设点击率阈值为0.005，那
么对于点击率《0.005的待推送消息会被系统过滤，即过滤一部分低质量推送，禁止对用户下发，保证用户接收到的目标推送消息的具有较高质量。预设条件还可以定义为选择点击率最大的待推送消息作为目标推送消息，此时目标推送消息只包含一条待推送消息。其中，uid表示用户唯一标识，mid表示消息唯一标识，uid-mid表示待推送消息与用户之间的对应关系；进一步地，对于日活用户的目标推送消息可以使用第一推送通道作为下发通道；对于非日活用户的目标推送消息可以使用第二推送通道作为下发通道。第二推送通道的消息触达率大于第一推送通道；触达率是推送消息成功发送至用户设备的成功率；对于日活用户，会通过第一推送通道下发目标推送消息，结合基于预设条件优选高质量推送消息发送，提高用户体验；对于非日活用户，由于希望尽可能使每个用户都成为日活用户，所以会尝试高触达率的第二推送通道，以尝试提高用户推送到达率，争取用户在当日点击推送消息成为日活用户。优选地，第一推送通道可以是自建渠道，第二推送通道可以是厂商渠道；自建渠道即应用提供商自行开发的推送消息下发通道；厂商渠道即用户所使用的设备的厂商提供的推送消息下发通道；自建渠道和厂商渠道二者都是待推送消息写入用户设备的渠道，两者区别主要在于触达率，即待推送消息成功发送至用户设备的成功率。由于用户设备的厂商通常会限制运行在用户设备上的其他客户端应用的活跃度以及限制基于客户端应用自建的自建渠道的推送消息的触达率，以避免用户持续收到推送影响用户体验，所以自建渠道只能在客户端应用活跃的时候才能触达，而厂商渠道不受客户端应用活跃度限制，自建渠道推送消息条数限制宽松可多发但触达率低，厂商渠道推送消息条数限制严格但触达率高。在发送目标推送消息时，首先获取所述目标用户的用户相关信息；在根据所述用户相关信息将所述待推送消息发送给所述目标用户，为了将目标推送消息发送给目标用户，需要获取目标用户的用户相关信息，用户相关信息包括但不限于使用的设备信息、操作系统、活跃时间范围、操作频次、性别、版本信息等；目标推送消息可以由消息推送装置根据用户相关信息发送给目标用户，也可以是消息推送装置将目标推送消息发送给下游模块，下游模块可以根据用户相关信息将目标推送消息发送给目标用户，此时可以将用户相关信息附加到目标推送消息中，将附加了用户相关信息的目标推送消息发送给负责最终发送目标推送消息给目标用户的下游模块，负责最终发出目标推送消息的下游模块根据用户相关信息以适合用户设备的方式和时间发出目标推送消息。其中，获取所述目标用户的用户相关信息，具体地，可以预先以parquet格式将所述目标用户的用户相关信息存储在hdfs中；通过flink文件流的方式读取存储在hdfs中的所述目标用户的用户相关信息；以提高获取用户相关信息的效率。传统数据库redis、hbase高峰期读取用户特征存在io瓶颈，影响程序下发效率甚至导致程序异常退出，将用户特征存储由数据库迁移至hdfsparquet，通过flinkreadfile+fileprocess-process_continuously读取为flinkdatastream，readfile将parquet文件读取为dataset实现了用户特征的快速读取与缓存，而fileprocess-process_continuously模式将读取的dataset转换为datastream，保证了流程序的一体性，使得程序可以正确存储checkpoint，实现故障下的快速恢复。其中，混排指的是对于用户对应的推送时间窗口中收集到的来自各业务方的各种待推送消息混合放在一起，不区分来源，而是根据预设条件择优选择一条或多条待推送消息作为目标推送消息进行发送或者按照一定的顺序发送。
[0072]
进一步地，所述根据周期性更新的全量日活用户列表判断所述目标用户是否为日
活用户，包括：
[0073]
使用布隆过滤器检索所述目标用户是否记录于所述全量日活用户列表；
[0074]
在检索出所述目标用户记录于所述全量日活用户列表的情况下，判定所述目标用户为日活用户；
[0075]
在检索出所述目标用户没有记录于所述全量日活用户列表的情况下，判定所述目标用户不是日活用户。
[0076]
在一些实施例中，由于系统中存在巨量的用户，从巨量的用户中检索目标用户会消耗非常大计算时间，为了提高效率，使用布隆过滤器处理全量日活用户列表并检索目标用户可以显著缩小全量日活用户列表占用的存储空间以及显著提高检索效率。
[0077]
进一步地，所述将所述目标推送消息发送给所述目标用户，包括：
[0078]
通过flink文件流的方式读取存储在hdfs中的所述目标用户的用户相关信息；其中，各用户的用户相关信息预先以parquet格式存储在所述hdfs中；
[0079]
将所述目标推送消息发送给与读取到的所述用户相关信息相对应的所述目标用户。
[0080]
在一些实施例中，在发送目标推送消息时，首先获取所述目标用户的用户相关信息；在根据所述用户相关信息将所述待推送消息发送给所述目标用户，为了将目标推送消息发送给目标用户，需要获取目标用户的用户相关信息，用户相关信息包括但不限于使用的设备信息、操作系统、活跃时间范围、操作频次、性别、版本信息等；目标推送消息可以由消息推送装置根据用户相关信息发送给目标用户，也可以是消息推送装置将目标推送消息发送给下游模块，下游模块可以根据用户相关信息将目标推送消息发送给目标用户，此时可以将用户相关信息附加到目标推送消息中，将附加了用户相关信息的目标推送消息发送给负责最终发送目标推送消息给目标用户的下游模块，负责最终发出目标推送消息的下游模块根据用户相关信息以适合用户设备的方式和时间发出目标推送消息。获取所述目标用户的用户相关信息，具体地，可以预先以parquet格式将所述目标用户的用户相关信息存储在hdfs中；通过flink文件流的方式读取存储在hdfs中的所述用户相关信息；以提高获取用户相关信息的效率。传统数据库redis、hbase高峰期读取用户特征(相当于用户相关信息)存在io瓶颈，影响程序下发效率甚至导致程序异常退出，将用户特征存储由数据库迁移到hdfsparquet，通过flinkreadfile+fileprocess-process_continuously读取为flinkdatastream，readfile将parquet文件读取为dataset实现了用户特征的快速读取与缓存，而fileprocess-process_continuously模式将读取的dataset转换为datastream，保证了流程序的一体性，使得程序可以正确存储checkpoint，实现故障下的快速恢复。
[0081]
第二方面，如图2所示，本发明实施例提供一种消息推送装置，包括：
[0082]
消息接收单元20，用于在接收到发送给目标用户的待推送消息时，判断所述目标用户是否存在推送时间窗口；
[0083]
时间窗口创建单元21，用于在判定所述目标用户不存在推送时间窗口的情况下，以接收到所述待推送消息的时间点为起点创建所述目标用户对应的推送时间窗口；
[0084]
推送消息收集单元22，用于将在所述推送时间窗口内接收到的、发送给所述目标用户的所有待推送消息添加到所述推送时间窗口对应的推送消息集合中；
[0085]
推送消息发送单元23，用于当所述推送时间窗口结束时，从所述推送消息集合中
选择符合预设条件的待推送消息作为目标推送消息，并将所述目标推送消息发送给所述目标用户。
[0086]
进一步地，所述待推送消息由业务方发送给所述目标用户，所述业务方包括多个；所述待推送消息包括由业务方发送给目标用户的慢速推送消息和/或直发推送消息，其中，所述慢速推送消息通过配置的慢速消息通道接收，所述直发推送消息通过配置的直发消息通道接收。
[0087]
进一步地，所述推送消息发送单元23，包括：
[0088]
第一目标推送消息优选模块，用于根据所述推送消息集合中每个待推送消息对应的预测点击率，将所述预测点击率大于或等于预设点击率阈值的待推送消息作为目标推送消息；或者，将所述预测点击率最大的设定条数的待推送消息作为目标推送消息。
[0089]
进一步地，所述推送消息发送单元23，包括：
[0090]
第一日活用户判断模块，用于根据周期性更新的全量日活用户列表判断所述目标用户是否为日活用户；其中，所述日活用户是指当日存在活动操作的用户；
[0091]
第一发送模块，用于在判定所述目标用户是日活用户的情况下，将所述目标推送消息进行混排后通过第一推送通道发送给所述目标用户；
[0092]
第二发送模块，用于在判定所述目标用户不是日活用户的情况下，将所述目标推送消息进行混排后通过第二推送通道发送给所述目标用户；
[0093]
其中，所述第二推送通道的消息触达率大于所述第一推送通道的消息触达率。
[0094]
进一步地，所述第一日活用户判断模块，包括：
[0095]
检索模块，用于使用布隆过滤器检索所述目标用户是否记录于所述全量日活用户列表；
[0096]
第二日活用户判断模块，用于在检索出所述目标用户记录于所述全量日活用户列表的情况下，判定所述目标用户为日活用户；在检索出所述目标用户没有记录于所述全量日活用户列表的情况下，判定所述目标用户不是日活用户。
[0097]
进一步地，所述推送消息发送单元23，包括：
[0098]
用户信息获取模块，用于通过flink文件流的方式读取存储在hdfs中的所述目标用户的用户相关信息；其中，各用户的用户相关信息预先以parquet格式存储在所述hdfs中；
[0099]
推送消息发送模块，用于将所述目标推送消息发送给与读取到的所述用户相关信息相对应的所述目标用户。
[0100]
本发明实施例提供的消息推送装置是前述的消息推送方法对应的产品类实施例，可根据前述的消息推送方法的实施例理解本发明实施例，在此不再赘述。
[0101]
本发明实施例具有如下技术效果：通过为用户开启推送时间窗口，收集在推送时间窗口内收到的针对该用户的推送消息，并在推送时间窗口结束时从收集的推送消息中择优发送给该用户，相对于离线推送提高了实时性，相对于直发推送提高了推送消息的内容质量，从而在时效性方面和内容质量两个方面相互平衡提高用户体验。
[0102]
第三方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面中任一项所述的方法。
[0103]
本发明实施例提供的可读存储介质用于存储实现如第一方面所述的任一项方法对应的程序代码，可根据前述的消息推送方法的实施例理解本发明实施例，在此不再赘述。
[0104]
本发明实施例具有如下技术效果：通过为用户开启推送时间窗口，收集在推送时间窗口内收到的针对该用户的推送消息，并在推送时间窗口结束时从收集的推送消息中择优发送给该用户，相对于离线推送提高了实时性，相对于直发推送提高了推送消息的内容质量，从而在时效性方面和内容质量两个方面相互平衡提高用户体验。
[0105]
下面结合具体的应用实例对本发明实施例上述技术方案进行详细说明，实施过程中没有介绍到的技术细节，可以参考前文的相关描述。
[0106]
spark是一种快速、通用、可扩展的大数据分析引擎；
[0107]
push即消息推送；
[0108]
flink即apacheflink是由apache软件基金会开发的开源流处理框架,其核心是用java和scala编写的分布式流数据流引擎。
[0109]
uid-mid在本发明技术方案中表示一对用户id(即uid)和消息id(即mid)；
[0110]
dau即dailyactiveuser表示日活跃用户；
[0111]
qps即queries-per-second每秒查询率；
[0112]
parquet：将大批量用户特征存储在常用大数据hdfs集群下；
[0113]
readfile：读取文件为dataset，使得用户特征的读取避免了实时访问数据库，减少io等待；
[0114]
fileprocess-process_continuously：将dataset转换为datastream，只有在datastrem的状态下，程序才能正常存储checkpoint，保证程序在故障是可以快速恢复。
[0115]
现有技术中的场景主要通过spark完成离线计算并推送push，离线任务笨重且消耗资源大，每小时才完成全部用户的覆盖，用户下发时效性低；直发push下发到用户时效性高，但是效果不可控，只能通过一些先验经验判断当前物料质量；发明人发现此时需要一类新的push形式，既能保证一定的时效性同时可以保证下发的效果，对二者进行一定程度的扩展和补充。
[0116]
离线sparkpush(相当于离线混排)通过算法包匹配用户物料，每小时计算全部用户，效果精准但时效性不足，直发push通过简易规则直接下发圈定用户，时效高但效果不可控，结合两类push的优缺点，实时混排将上述spark批处理方式切换为flink流处理，将离线push(相当于慢速推送消息)与直发push(相当于直发推送消息)的uid-mid统一写入实时混排(相当于本技术的消息推送装置)，当一个用户接受到第一条业务方送来的uid-mid时，为当前用户开启一个10min(分钟)的计时窗口(即推送时间窗口)，后续10min内其他业务方为该uid送来的uid-mid都会收集在同一个10min计时窗口内，当10min时间到期后，针对10min内单个用户收到的全部uid-mid进行择优下发。10min窗口的实现保证了用户下发周期由1h缩短至10min，时效性大大提高，同时通过对10min内收集到的多条uid-mid对择优下发，避免了直发push快速下发但物料质量不可控制的问题。
[0117]
a：上下文获取：由于用户dau等辅助决策变量实时更新，所以需要一个上下文数据流定时更新全量用户dau状态，dau通过集群redis实时记录点击push的dau用户，这里5min从redis读取最新一次的全量dau用户，由于push用户量级为千万级，这里采用bloomfilter布隆过滤器代替全量用户集合，节省内存十倍之多，通过轻量级的dau布隆过滤器，下游也
可以通过用户的dau状态实时调整push下发策略与通道，优化不同类型用户的触达率与触达内容。
[0118]
b：文件流：即readfile+fileprocess-process_continuously读取用户数据作为flink数据流。用户下发需要获取用户设备版本，用户渠道等多种用户信息，通过hbase或者redis读取效率低，影响程序运行，这里创新的采用文件流的方式，将离线缓存用户特征加入实时程序，实现快速加载全量用户特征的目的。文件流实现了flink的批转流，即将静态parquet文件数据转换为flink流式处理所需的datastream数据流。原有hbase、redis访问数据库获取用户特征的方式在push下发高峰期网络io压力严重，push业务高峰期瞬时qps最高可达百万级别，高并发的数据访问会造成数据库短时的缓慢响应，影响push下发时效性，严重时会导致程序运行失败，影响线上业务稳定运行，通过将大批量用户数据缓存在离线parquet文件中，并在程序第一次启动时一次性读出即可快速缓存用户特征(2min内缓存完毕)，彻底摆脱用户数据对数据库的依赖，保障任务在push高峰期间不受网络io影响，大大提高了程序的时效性与稳定性，同时为了保证任务的checkpoint正常存储，这里为文件读取增加了fileprocess-process_continuously参数，使得程序故障恢复模块运行正常，做到了高并发高可用。
[0119]
如图3所示，可以看到使用redis+hbase的数据库方案受到网络io影响，高峰期吞吐存在瓶颈，输出数据接近平行，而如图4所示，修改为文件流后输出数据呈驼峰状态，较之前节约一半时间，大大提升下发效率，提升了物料的点击时效性与点击量。
[0120]
c：kafkasource，即kafka数据源，接收离线push即sparkpush的用户uid-mid对，离线push计算用户量大，采用kafka实现高吞吐。
[0121]
d：redissource，即redis数据源，接收直发push的用户uid-mid对，由于透传push下发主要基于规则与圈定用户，多为热点类物料，所以公用内容较多，所以通过mid-uids[最大1000个]的一对多形式写入redis队列，并由flink程序负责消费。
[0122]
e：合并流，这里同时接受a,b,c,d四路数据源，并基于uid粒度为每一个uid实现一个10min窗口，通过a流判断用户状态，通过b流读取用户下发所需特征，通过c流读取用户离线pushuid-mid对，通过d流读取mid-uids对并将mid分别处理之不同uid的10min窗口内。这样就实现了用户下发的准备，即10min窗口内接受多业务方的uid-mid对，且保存用户下发信息。
[0123]
f：下发流，基于e流中每个用户的10min窗口，当窗口10min到期后，将多业务方的uid-mid对择优选择去top1，并结合用户信息与状态直至下发。
[0124]
通过[a+b+c+d]-》e-》f的多段流程，实现了用户实时混排的全部流程。
[0125]
[a+b+c+d]为全部信息源，e为用户窗口聚合阶段择优阶段，f为用户下发阶段。
[0126]
本发明技术方案具有如下技术效果：
[0127]
1.时效性：通过flinktimewindow实现了uid粒度的10min窗口，可以保证用户聚合10min内的uid-mid对并择优下发，相比于离线push的小时级延迟，可以大大提高物料到达用户的时效性，而很多时效性高且高质量的微博也实现了获得更快到达用户侧的目的，提升了用户整体打开规模。以10000752特别关注为例，单业务下发pv增加39.67％，点击pv增加57.08％，点击率提升12.46％，可以看到时效性的提升对优质物料的打开规模与点击率都有很明显的影响。
[0128]
2.效果保障与用户体验：直发push下发效率快，占用用户每日下发额度，但质量不可控，通过对直发push进行分类处理，高优先级物料例如全量热点等直发业务，不进入实时混排仍然走直发push，对于效果相对不稳定(主要参考历史点击率)的直发业务纳入实时混排，在损失一定时效性的情况下，保证下发质量，同时避免用户下发额度快速占满，即减少了用户打开也提升了用户体验，减少了用户关闭开关的比例。
[0129]
3.轻量级、高吞吐与高可用：通过flink代替spark框架，达到了轻量级应用，实现了高吞吐，同时由于flinkcheckpoint的引入提高了任务的鲁棒性，使得任务高效、稳定、有效。
[0130]
4.实时混排机制：介于传统离线push与直发push，结合二者优点，引入10min实时混排机制，在提高push时效性的基础上保证了更高的push物料质量。
[0131]
5.文件流代替socket读取用户特征：传统数据库redis、hbase高峰期读取用户特征存在io瓶颈，影响程序下发效率甚至导致程序异常退出，将用户特征存储由数据库迁移至hdfsparquet，通过flinkreadfile+fileprocess-process_continuously读取为flinkdatastream，readfile将parquet文件读取为dataset实现了用户特征的快速读取与缓存，而fileprocess-process_continuously模式将读取的dataset转换为datastream，保证了流程序的一体性，使得程序可以正确存储checkpoint，实现故障下的快速恢复。
[0132]
应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。
[0133]
在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要比清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。
[0134]
为使本领域内的任何技术人员能够实现或者使用本发明，上面对所公开实施例进行了描述。对于本领域技术人员来说；这些实施例的各种修改方式都是显而易见的，并且本文定义的一般原理也可以在不脱离本公开的精神和保护范围的基础上适用于其它实施例。因此，本公开并不限于本文给出的实施例，而是与本技术公开的原理和新颖性特征的最广范围相一致。
[0135]
上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。
[0136]
以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含
在本发明的保护范围之内。

技术特征：
1.一种消息推送方法，其特征在于，包括：在接收到发送给目标用户的待推送消息时，判断所述目标用户是否存在推送时间窗口；在判定所述目标用户不存在推送时间窗口的情况下，以接收到所述待推送消息的时间点为起点创建所述目标用户对应的推送时间窗口；将在所述推送时间窗口内接收到的、发送给所述目标用户的所有待推送消息添加到所述推送时间窗口对应的推送消息集合中；当所述推送时间窗口结束时，从所述推送消息集合中选择符合预设条件的待推送消息作为目标推送消息，并将所述目标推送消息发送给所述目标用户。2.如权利要求1所述的消息推送方法，其特征在于，所述待推送消息由业务方发送给所述目标用户，所述业务方包括多个；所述待推送消息包括由业务方发送给目标用户的慢速推送消息和/或直发推送消息，其中，所述慢速推送消息通过配置的慢速消息通道接收，所述直发推送消息通过配置的直发消息通道接收。3.如权利要求1所述的消息推送方法，其特征在于，所述从所述推送消息集合中选择符合预设条件的待推送消息作为目标推送消息，包括：根据所述推送消息集合中每个待推送消息对应的预测点击率，将所述预测点击率大于或等于预设点击率阈值的待推送消息作为目标推送消息；或者，将所述预测点击率最大的设定条数的待推送消息作为目标推送消息。4.如权利要求1至3任一所述的消息推送方法，其特征在于，所述将所述目标推送消息发送给所述目标用户，包括：根据周期性更新的全量日活用户列表判断所述目标用户是否为日活用户；其中，所述日活用户是指当日存在活动操作的用户；在判定所述目标用户是日活用户的情况下，将所述目标推送消息进行混排后通过第一推送通道发送给所述目标用户；在判定所述目标用户不是日活用户的情况下，将所述目标推送消息进行混排后通过第二推送通道发送给所述目标用户；其中，所述第二推送通道的消息触达率大于所述第一推送通道的消息触达率。5.如权利要求4所述的消息推送方法，其特征在于，所述根据周期性更新的全量日活用户列表判断所述目标用户是否为日活用户，包括：使用布隆过滤器检索所述目标用户是否记录于所述全量日活用户列表；在检索出所述目标用户记录于所述全量日活用户列表的情况下，判定所述目标用户为日活用户；在检索出所述目标用户没有记录于所述全量日活用户列表的情况下，判定所述目标用户不是日活用户。6.如权利要求1所述的消息推送方法，其特征在于，所述将所述目标推送消息发送给所述目标用户，包括：通过flink文件流的方式读取存储在hdfs中的所述目标用户的用户相关信息；其中，各用户的用户相关信息预先以parquet格式存储在所述hdfs中；将所述目标推送消息发送给与读取到的所述用户相关信息相对应的所述目标用户。
7.一种消息推送装置，其特征在于，包括：消息接收单元，用于在接收到发送给目标用户的待推送消息时，判断所述目标用户是否存在推送时间窗口；时间窗口创建单元，用于在判定所述目标用户不存在推送时间窗口的情况下，以接收到所述待推送消息的时间点为起点创建所述目标用户对应的推送时间窗口；推送消息收集单元，用于将在所述推送时间窗口内接收到的、发送给所述目标用户的所有待推送消息添加到所述推送时间窗口对应的推送消息集合中；推送消息发送单元，用于当所述推送时间窗口结束时，从所述推送消息集合中选择符合预设条件的待推送消息作为目标推送消息，并将所述目标推送消息发送给所述目标用户。8.如权利要求7所述的消息推送装置，其特征在于，所述待推送消息由业务方发送给所述目标用户，所述业务方包括多个；所述待推送消息包括由业务方发送给目标用户的慢速推送消息和/或直发推送消息，其中，所述慢速推送消息通过配置的慢速消息通道接收，所述直发推送消息通过配置的直发消息通道接收。9.如权利要求7所述的消息推送装置，其特征在于，所述推送消息发送单元，包括：第一目标推送消息优选模块，用于根据所述推送消息集合中每个待推送消息对应的预测点击率，将所述预测点击率大于或等于预设点击率阈值的待推送消息作为目标推送消息；或者，将所述预测点击率最大的设定条数的待推送消息作为目标推送消息。10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1-6中任一项所述的方法。

技术总结
本发明实施例提供一种消息推送方法、装置和存储介质，所述方法包括：在接收到发送给目标用户的待推送消息时，判断所述目标用户是否存在推送时间窗口；在判定所述目标用户不存在推送时间窗口的情况下，以接收到所述待推送消息的时间点为起点创建所述目标用户对应的推送时间窗口；将在所述推送时间窗口内接收到的、发送给所述目标用户的所有待推送消息添加到所述推送时间窗口对应的推送消息集合中；当所述推送时间窗口结束时，从所述推送消息集合中选择符合预设条件的待推送消息作为目标推送消息，并将所述目标推送消息发送给所述目标用户。用户。用户。


技术研发人员：张旭东 李霄野 周虹君
受保护的技术使用者：微梦创科网络科技（中国）有限公司
技术研发日：2023.02.28
技术公布日：2023/8/5