CN116155852A - Feed流实现方法、装置、终端及存储介质 - Google Patents

Abstract

本申请公开了一种Feed流实现方法、装置、终端及存储介质，方法包括：接收第一Feed流信息；基于推拉策略，判断是否推送第一Feed流信息；若推送Feed流信息，利用目标推拉结合模式实时推送第一Feed流信息，以及拉取第二Feed流信息。本发明通过推拉结合模式适用于高并发Feed流业务场景下的Feed流实现，降低了存储成本，提高了消息推送的及时性。此外，本发明还通过设置多维推拉模式，以适应不同业务场景，业务扩展性强。

Description

Feed流实现方法、装置、终端及存储介质

技术领域

本申请涉及计算机领域，具体而言，涉及一种Feed流实现方法、装置、终端及存储介质。

背景技术

社交网络软件系统一般通过Feed流进行消息推送。其中，Feed流是将发布者的信息单元通过社交关系传送给接收者，而信息单元可为一条朋友圈状态、一条微博、一条咨询或一条短视频等。

目前，针对社交网络软件系统中的Feed流的实现，一般采用推模式或拉模式。

但是，在高并发Feed流业务场景下，上述方法并不适用。

发明内容

本申请的主要目的在于提供一种Feed流实现方法、装置、终端及存储介质，以解决高并发Feed流业务场景下的Feed流实现的问题。

为了实现上述目的，第一方面，本申请提供了一种Feed流实现方法，包括：

接收第一Feed流信息；

基于推拉策略，判断是否推送第一Feed流信息，其中，推拉策略包括多维推拉结合模式；

若推送Feed流信息，利用目标推拉结合模式实时推送第一Feed流信息，以及拉取第二Feed流信息，其中，目标推拉结合模式为多维推拉结合模式中的一种。

在一种可能的实现方式中，利用目标推拉结合模式实时推送第一Feed流信息，包括：

通过消息队列方式将第一Feed流信息推送至目标群体，其中，目标群体与目标推拉结合模式相对应。

在一种可能的实现方式中，通过消息队列方式将第一Feed流信息推送至目标群体，包括：

将第一Feed流信息发送至初始消息队列；

基于第一Feed流信息、初始消息队列和目标群体，生成目标消息队列；

将目标消息队列中的所有第一Feed流信息推送至目标群体。

在一种可能的实现方式中，基于第一Feed流信息、初始消息队列和目标群体，生成目标消息队列，包括：

获取目标群体中所包含的第一用户的数目和用户ID，其中，目标群体中的任意两个用户ID不同；

在初始消息队列中，基于第一用户的数目和用户ID，对第一Feed流信息进行处理，得到目标消息队列。

在一种可能的实现方式中，在初始消息队列中，基于第一用户的数目和用户ID，对第一Feed流信息进行处理，得到目标消息队列，包括：

对第一Feed流信息进行复制，生成与第一用户的数目相同数目的第一Feed流信息，得到第一预设数目的第一Feed流信息；

为第一预设数目的第一Feed流信息中的每个第一Feed流信息配置用户ID，并依据用户ID对第一预设数目的第一Feed流信息进行排序，得到目标消息队列。

在一种可能的实现方式中，将目标消息队列中的所有第一Feed流信息推送至目标群体，包括：

针对所有第一Feed流信息中的每个第一Feed流信息，获取每个第一Feed流信息的用户ID；

依据用户ID将每个第一Feed流信息推送至对应的第一用户。

在一种可能的实现方式中，利用目标推拉结合模式实时拉取第二Feed流信息，包括：

接收第一用户的查询请求；

基于查询请求，通过滑动窗口拉取第二Feed流信息。

在一种可能的实现方式中，基于查询请求，通过滑动窗口拉取第二Feed流信息，包括：

基于查询请求，从第一用户的收件箱中获取第一Feed流信息以及与第一用户所关注的所有用户的发件箱中获取第三Feed流信息；

将第一Feed流信息和第三Feed流信息分别按照预设时间轴进行排序，得到第一时间轴信息和第二时间轴信息；

将第一时间轴信息和第二时间轴信息对齐，得到对齐后的时间轴信息；

将滑动窗口从对齐后的时间轴信息的起点开始滑动，并将滑动窗口每滑动一次所获取的数据作为第二Feed流信息，其中，滑动窗口的右边框所对应的预设时间轴上的时间点作为滑动窗口下次滑动的起点。

在一种可能的实现方式中，将滑动窗口从对齐后的时间轴信息的起点开始滑动，并将滑动窗口每滑动一次所获取的数据作为第二Feed流信息之后，还包括：

将第二Feed流信息中的信息进行状态筛选、用户特征数据组合，得到目标Feed流信息。

在一种可能的实现方式中，接收第一Feed流信息之后，还包括：

将第一Feed流信息存储至多个存储介质中。

第二方面，本发明实施例提供了一种Feed流实现装置，包括：

接收模块，用于接收第一Feed流信息；

判断模块，用于基于推拉策略，判断是否推送第一Feed流信息，其中，推拉策略包括多维推拉结合模式；

Feed流实现模块，用于若推送Feed流信息，利用目标推拉结合模式实时推送第一Feed流信息，以及拉取第二Feed流信息，其中，目标推拉结合模式为多维推拉结合模式中的一种。

第三方面，本发明实施例提供了一种终端，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上任一种Feed流实现方法的步骤。

第四方面，本发明实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现如上任一种Feed流实现方法的步骤。

本发明实施例提供了一种Feed流实现方法、装置、终端及存储介质，包括：接收第一Feed流信息，然后基于推拉策略，判断是否推送第一Feed流信息，其中，推拉策略包括多维推拉结合模式，若推送Feed流信息，利用目标推拉结合模式实时推送第一Feed流信息，以及拉取第二Feed流信息。本发明通过推拉结合模式适用于高并发Feed流业务场景下的Feed流实现，降低了存储成本，提高了消息推送的及时性。此外，本发明还通过设置多维推拉模式，以适应不同业务场景，业务扩展性强。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是本发明实施例提供的一种基于推模式的Feed流实现方法的流程示意图；

图2是本发明实施例提供的一种基于拉模式的Feed流实现方法的流程示意图；

图3是本发明实施例提供的一种Feed流实现方法的应用场景的示意图；

图4是本发明实施例提供的一种Feed流实现方法的流程示意图；

图5是本发明实施例提供的一种推送第一Feed流信息方法的流程示意图；

图6是本发明实施例提供的一种拉取第二Feed流信息方法的流程示意图；

图7是本发明实施例提供的一种信息设置界面示意图；

图8是本发明实施例提供的一种Feed流实现装置的结构示意图；

图9是本发明实施例提供的终端的示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。

应当理解，在本发明的各种实施例中，各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

应当理解，在本发明中，“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应当理解，在本发明中，“多个”是指两个或两个以上。“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。“包含A、B和C”、“包含A、B、C”是指A、B、C三者都包含，“包含A、B或C”是指包含A、B、C三者之一，“包含A、B和/或C”是指包含A、B、C三者中任1个或任2个或3个。

应当理解，在本发明中，“与A对应的B”、“与A相对应的B”、“A与B相对应”或者“B与A相对应”，表示B与A相关联，根据A可以确定B。根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其他信息确定B。A与B的匹配，是A与B的相似度大于或等于预设的阈值。

取决于语境，如在此所使用的“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。

本公开所涉及的数据可以为经用户授权或者经过各方充分授权的数据，对数据的采集、传播、使用等，均符合国家相关法律法规要求，本公开实施方式/实施例可以互相组合。

下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图通过具体实施例来进行说明。

首先对本申请实施例所涉及的若干个名词解释进行简介：

Feed：是一个信息单元，比如一条朋友圈状态、一条微博、一条咨询或一条短视频等。

Feed流：是将“N个发布者的信息单元”通过“关注关系”传送给“M个接收者”。

关注：用户接收到关注人的动态。

被关注：用户的动态会推送给被关注的人。

关注关系：系统中个体间的关系，其中，微博中是关注，是单向流。

官V：官方号，默认被所有用户关注，或跟所有用户绑定。

大V：被多人关注的用户，例如被1000人以上关注的用户。

大V缓冲池：存储大V用户发布的所有Feed信息。

收件箱：用来存储Feed流数据。

好友动态：用户关注的所有用户，按照一定的规则，例如创建时间、内容得分，排序后展示的列表。

动态：用户发布的消息、内容、状态、心情等，与Feed概念类似。

目前，Feed流的实现主要包括推模式和拉模式两种模式，也就是说，可通过采用推模式和拉模式中的任一种实现Feed流。

在一实施例中，推模式是指把关注人所发的Feed流主动推送给粉丝。请参阅图1，图1为本申请实施例提供的一种基于推模式的Feed流实现方法的流程示意图。如图1所示，推模式相当于有一个收件箱，当关注人(当前用户)发送Feed流时，会给所有粉丝(如粉丝1、粉丝2...粉丝N)的收件箱推送此Feed流。如此，无论某个粉丝关注了多少人，此粉丝所关注的人所发送的Feed流都会主动推送到此粉丝的收件箱中，此粉丝只需要访问自己的收件箱，就可以获取到其所有关注的人发送的所有Feeds流。

在一实施例中，拉模式是指从关注人的发件箱拉取所发的Feed流。请参阅图2，图2为本申请实施例提供的一种基于拉模式的Feed流实现方法的流程示意图。如图2所示，当前用户的所有关注人(如主播1、主播2...主播N)均有一个发件箱，当关注人发送Feed流时，会把所发送的Feed流存储至其发件箱中其中，发件箱中设置列表用于存储已发送的Feed流。当前用户若想要获取所有关注人的Feed流，则需要遍历所有关注人的发件箱中的列表，以取出所有关注人的发件箱中的列表中的Feed流，再将取出的所有Feed流按照时间顺序聚合即实现Feed流。

无论采取推模式还是拉模式，均无法适用于高并发Feed流业务场景下的Feed流实现。

基于此，本申请提供一种Feed流实现方法，可适用于高并发Feed流业务场景。

请参阅图3，图3为本申请实施例提供的一种Feed流实现方法的应用场景的示意图。如图3所示，客户端302与服务器304进行通信，服务器304接收客户端302发送的第一Feed流信息，然后基于推拉策略，判断是否推送第一Feed流信息，其中，推拉策略包括多维推拉结合模式，若推送Feed流信息，利用目标推拉结合模式实时推送第一Feed流信息，以及拉取第二Feed流信息，其中，目标推拉结合模式为多维推拉结合模式中的一种。

其中，客户端302与服务器304可以通过任意通信方式进行通信，包括但不限于网络通信，且上述网络可以包括但不限于：有线网络、无线网络，其中，该有线网络包括：局域网、城域网和广域网，该无线网络包括：蓝牙、WIFI、及其他实现无线通信的网络。其中，客户端302包括但不限于以下至少之一：手机(如Android手机、iOS手机等)，笔记本电脑、平板电脑、掌上电脑、MID(Mobile Internet Devices，移动互联网设备)、PAD、台式电脑、智能电视等。其中，服务器304可为现场服务器或者远程服务器，其中，现场服务器与远程服务器均可为独立的服务器或者是多个服务器组成的服务集群来实现。上述仅是一种示例，本实施例中对此不作任何限定。

请参阅图4，图4为本申请实施例提供的一种Feed流实现方法的流程示意图。如图4所示，该方法应用于图3所示的服务器304，包括以下步骤：

步骤S401：接收第一Feed流信息。

结合图5，本申请设置有推拉策略，当服务器304接收到第一Feed流信息后，会根据推拉策略执行后续操作。其中，第一Feed流信息用于表征当前用户通过操作所发布的Feed流，其中，操作主要指对第一Feed流信息的状态进行变更的操作，至少包括内容发布、内容审核、用户删除等。

步骤S402：基于推拉策略，判断是否推送第一Feed流信息。

当服务器304接收到当前用户发布的第一Feed流信息后，会基于推拉策略来判断是否推送第一Feed流信息。若判断推送第一Feed流信息，则执行候选操作，以实现本申请目的；若判断不推送第一Feed流信息，则结束操作。

其中，推拉策略包括多维推拉结合模式。其中，多维推拉结合模式可为具体设定的业务场景的推拉模式和自定义推拉模式。

具体设定的业务场景的推拉模式包括大粉丝场景的推拉模式、活跃用户场景的推拉模式、在线用户场景的推拉模式以及亲密度场景的推拉模式，其中，大粉丝场景的推拉模式主要按照用户关注者(粉丝)数量做区分，分发推拉策略；活跃用户场景的推拉模式按照用户之间粘性，关联度做区分，粘性判断维度可为用户之间互动行为，包括并不限制为评论、点赞、转发等；在线用户场景的推拉模式按照用户在线状态，去推拉分发，在线用户走推模型链路，离线用户走拉模型链路，提升用户Feed流在高并发下的实时性；亲密度场景的推拉模式按照用户之间亲密度值做链路分发，亲密度值按业务规则累计。

自定义推拉模式可根据用户需求进行配置，可选地，按照用户ID是否命中配置信息进行区分，配置信息可存储在配置中心、或持久化到Mysql中。

本申请中的多维推拉结合模式支持多种推拉模式，赋予业务场景更多灵活度，且可动态切换推拉链路，此外，自定义推拉模式通过用户根据个人需求配置，支持业务定制扩展，提高了实现Feed流的灵活度。

步骤S403：若推送Feed流信息，利用目标推拉结合模式实时推送第一Feed流信息，以及拉取第二Feed流信息。

其中，目标推拉结合模式为多维推拉结合模式中的一种，也就是说，可以采用上述多维推拉结合模式中的任一一种推拉模式，且所有推拉结合模式执行推送第一Feed流信息，以及拉取第二Feed流信息的方式均相同。

请参阅图5，图5为本申请实施例提供的一种推送第一Feed流信息方法的流程示意图。如图5所示，该方法应用于图3所示的服务器304，包括以下步骤：

本实施例主要利用目标推拉结合模式实时推送第一Feed流信息，即当前用户通过推拉策略决策判断推送(图5所示的Y，Yes)第一Feed流信息时，会对第一Feed流信息进行策略性地拆分，以实现流量削峰，达到平滑缓冲的目的。相反地，当前用户通过推拉策略决策判断不推送(图5所示的N，No)第一Feed流信息时，则立即结束，不再执行后续步骤。

针对第一Feed流信息进行策略性地拆分主要通过消息队列方式将第一Feed流信息推送至目标群体，其中，目标群体与目标推拉结合模式相对应。例如，目标推拉结合模式为活跃用户场景的推拉模式的情况下，那么其目标群体则需要按照用户之间粘性，关联度做区分，可选地，目标群体可为与当前用户进行评论互动的群体。

其中，通过消息队列方式将第一Feed流信息推送至目标群体，需要先将第一Feed流信息发送至初始消息队列，然后基于第一Feed流信息、初始消息队列和目标群体，生成目标消息队列，再将目标消息队列中的所有第一Feed流信息推送至目标群体。

针对基于第一Feed流信息、初始消息队列和目标群体，生成目标消息队列，需先获取目标群体中所包含的第一用户的数目和用户ID，其中，目标群体中的任意两个用户ID不同，然后在初始消息队列中，基于第一用户的数目和用户ID，对第一Feed流信息进行处理，得到目标消息队列。可选地，在初始消息队列中，基于第一用户的数目和用户ID，对第一Feed流信息进行处理，得到目标消息队列，需对第一Feed流信息进行复制，生成与第一用户的数目相同数目的第一Feed流信息，得到第一预设数目的第一Feed流信息，然后为第一预设数目的第一Feed流信息中的每个第一Feed流信息配置用户ID，并依据用户ID对第一预设数目的第一Feed流信息进行排序，得到目标消息队列。

可选地，将目标消息队列中的所有第一Feed流信息推送至目标群体，需针对所有第一Feed流信息中的每个第一Feed流信息，获取每个第一Feed流信息的用户ID，然后依据用户ID将每个第一Feed流信息推送至对应的第一用户。

示例性地，以目标推拉结合模式为活跃用户场景的推拉模式，目标群体可为与当前用户进行评论互动的群体，即粉丝1、粉丝2...粉丝N(一个粉丝代表一个第一用户)，实现第一Feed流信息的推送。具体的，当前用户通过推拉策略决策判断推送第一Feed流信息时，先将第一Feed流信息发送至初始消息队列中，初始消息队列会以及目标群体中粉丝的数目来对第一Feed流信息进行复制，生成与粉丝数目相同数目的第一Feed流信息，即生成N个第一Feed流信息，对生成的N个第一Feed流信息进行排列，得到目标消息队列。由于每个粉丝均有各自的ID，那么只需要将目标消息队列中的所有第一Feed流信息按照粉丝各自的ID发送至粉丝1、粉丝2...粉丝N，当粉丝接收到第一Feed流信息后会将第一Feed流信息存储至对应的收件箱。其中，N个第一Feed流信息、N个ID以及N个粉丝一一对应。

此外，当前用户还会对个人所要推送的第一Feed流信息进行存储，即将推送的第一Feed流信息存储至个人发件箱(当前用户的发件箱)。

进一步的，当前用户的发件箱中的第一Feed流信息可采用多介质存储，也就是说，将第一Feed流信息存储至多个存储介质中。多个存储介质包括但不限于Mysql、Nsearch、Hive。

针对存储介质为Mysql、Nsearch、Hive时，其存储方法主要为，先初始化存储介质Mysql、Nsearch、Hive对应的Mysql、Nsearch、Hive表的结构，所要推送的第一Feed流信息主写Mysql，写成功业务即成功并返回，然后通过Mysql数据变更binLog日志，并将binLog日志组建转换成消息，进入消息队列。当消息队列被不同平台消费，例如消费平台为BCP(实时核对平台)和云村数据平台(基于spake框架实现的大数据平台)，云村数据平台消费第一Feed流信息，经过数据清洗、数据转换、数据组装后输出到其他存储介质nsearch，BCP延迟消费第一Feed流信息，触发查询nsearch中对应数据的情况，保障多方数据最终一致性。至此数据介质Mysql、nsearch均可对外提供搜索服务，以满足不同业务需求。

请参阅图6，图6为本申请实施例提供的一种拉取第二Feed流信息方法的流程示意图。如图6所示，该方法应用于图3所示的服务器304，服务器304执行图6中的当前用户的操作步骤，包括以下步骤：

本申请实施例主要利用目标推拉结合模式实时拉取第二Feed流信息，需先接收第一用户的查询请求，然后基于查询请求，通过滑动窗口拉取第二Feed流信息。其中，第二Feed流信息用于表征从当前用户所关注的人以及当前用户的收件箱所拉取的Feed流。

本申请将多维度Feed流设置于预设时间轴上，并通过滑动窗口沿着预设时间轴的方向拉取Feed流。其中，滑动窗口是基于时间的窗口，即基于时间戳偏移量T设置固定窗口，其中，时间戳偏移量T用于表征滑动窗口的窗口宽度相对于预设时间轴的时间段。此固定窗口可拉取固定数量的Feed流，此处固定数量根据具体需求设定，此处不作具体限定。

可选地，基于查询请求，通过滑动窗口拉取第二Feed流信息，需要基于查询请求，从第一用户的收件箱中获取第一Feed流信息以及与第一用户所关注的所有用户的发件箱中获取第三Feed流信息，然后将第一Feed流信息和第三Feed流信息分别按照预设时间轴进行排序，得到第一时间轴信息和第二时间轴信息，再将第一时间轴信息和第二时间轴信息对齐，得到对齐后的时间轴信息，最后将滑动窗口从对齐后的时间轴信息的起点开始滑动，并将滑动窗口每滑动一次所获取的数据作为第二Feed流信息，其中，滑动窗口的右边框所对应的预设时间轴上的时间点作为滑动窗口下次滑动的起点。

示例性地，当前用户需要从个人收件箱以及所关注的人(被关注者)的收件箱分别获取不同的Feed流，包括从个人收件箱获取的第一Feed流信息和从被关注者的收件箱获取的第三Feed流信息。

具体的，针对从个人收件箱获取的第一Feed流信息，主要是当前用户查询个人收件箱中的收件记录所获取的。此收件箱中的Feed流主要来源为当前用户推送的第一Feed流信息，第一Feed流信息的主要存储介质为mysql，通过数据库引擎能力对第一Feed流信息按创建时间倒序后，返回收件记录的数据流。

而针对从被关注者的收件箱获取的第三Feed流信息，可通过查询被关注者的收件箱，其中，被关注者的收件箱是指基于当前用户与被关注者的关注关系，并基于此关注关系当前用户推送Feed流时所命中所有用户的收件箱。当前用户查询被关注者的收件箱，主要包括热数据查询和冷数据查询。其中，热数据查询是指查询存储于缓存中的数据，冷数据查询是指查询存储于内存中的数据。本申请将热数据查询和冷数据查询所获取的数据在内存混排后的数据流，其混排包括但不限于按创建时间、固定位置、内容得分等情况排序方式。

当获取到第一Feed流信息和第三Feed流信息后，将第一Feed流信息和第三Feed流信息分别按照预设时间轴进行排序，得到第一时间轴信息和第二时间轴信息，其中，预设时间轴可为任意时间段的时间轴，根据需要进行设定，此处不作具体限定。然后将第一时间轴信息和第二时间轴信息对齐，得到对齐后的时间轴信息，可采用将第一时间轴信息和第二时间轴信息基于预设时间轴进行对齐。

之后，将滑动窗口从对齐后的时间轴信息的起点开始滑动以获取第二Feed流信息。设预设时间轴为起始点10:00到终止点24:00的时间轴，滑动窗口的滑动偏移量T为1小时，滑动窗口在预设时间轴上每次以滑动偏移量1小时进行滑动，每滑动一次所获取的数据作为第二Feed流信息。

例如，滑动窗口从起始点10:00向终止点24:00滑动，那么第一次时，滑动窗口左边框设置于预设时间轴的起始点10:00，此次滑动窗口拉取的数据(框在滑动窗口中的数据)为第二Feed流信息，之后将滑动窗口的左边框以滑动偏移量1小时偏移，此时滑动窗口的左边框设置于11:00，此滑动窗口拉取的数据也为第二Feed流信息....以此类推，不再赘述。

滑动窗口每获取一次第二Feed流信息后，需要将每次获取到的第二Feed流信息中的信息进行状态筛选、用户特征数据组合，得到目标Feed流信息，返回给页面展示。其中，状态筛选包括但不限于内容删除状态、内容审核状态、用户拉黑等，用户特征数据包括但并不限于用户头像、用户昵称、用户特权、用户开播状态等。

通过上述方式获取到目标Feed流信息后，可对目标Feed流信息进行投放。以目标Feed流信息中的某个Feed流信息为例，针对此Feed流信息的投放，可根据投放类型设置对应的信息，包括但不限于投放元素、元素属性、投放维度等。设置好对应的信息后，则可对此Feed流信息进行页面展示。

示例性地，以某个Feed流信息进行广告投放为例，可设置此某个Feed流信息对应的信息，其信息设置界面如图7所示，标记星号的信息为必须要设置的信息，未标记星号的信息为选择性设置的信息。

针对广告投放，其所要设置的信息主要包括投放元素、元素属性、投放维度。其中，投放元素可以分为图片、文本、控件等，以及以上多种的组合；元素属性可以包括图片大小、图片分辨率、图片格式等，文本对应的候选元素属性可以包括文本字数，控件对应的候选元素属性可以为跳转控件，包括跳转的文字和对应的跳转链接url；投放维度主要支持人群包的维度，人群包支持离线人群包和在线人群特征聚合，离线人群包通过在人群后台圈选出一部分用户ID作为一个集合，生成一个人群ID作为标识，外围系统通过该标识后续做人群判断，而在线人群特征聚合是指创建一些人群筛选的规则，比如国家、性别、年龄等，人群命中判断时，根据当前目标用户ID、人群ID上的规则判断目标用户是否匹配。

通过完成图7所示的信息设置界面中信息的设置后，直接点击确认按钮，则可在页面展示此Feed流信息对应的广告信息。

本发明实施例提供了一种Feed流实现方法，包括：接收第一Feed流信息，然后基于推拉策略，判断是否推送第一Feed流信息，其中，推拉策略包括多维推拉结合模式，若推送Feed流信息，利用目标推拉结合模式实时推送第一Feed流信息，以及拉取第二Feed流信息。本发明通过推拉结合模式适用于高并发Feed流业务场景下的Feed流实现，降低了存储成本，提高了消息推送的及时性。此外，本发明还通过设置多维推拉模式，以适应不同业务场景，业务扩展性强。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

以下为本发明的装置实施例，对于其中未详尽描述的细节，可以参考上述对应的方法实施例。

图8示出了本发明实施例提供的一种Feed流实现装置的结构示意图，为了便于说明，仅示出了与本发明实施例相关的部分，一种Feed流实现装置包括接收模块801、判断模块802和Feed流实现模块803，具体如下：

接收模块801，用于接收第一Feed流信息；

判断模块802，用于基于推拉策略，判断是否推送第一Feed流信息，其中，推拉策略包括多维推拉结合模式；

Feed流实现模块803，用于若推送Feed流信息，利用目标推拉结合模式实时推送第一Feed流信息，以及拉取第二Feed流信息，其中，目标推拉结合模式为多维推拉结合模式中的一种。

在一种可能的实现方式中，Feed流实现模块803还用于通过消息队列方式将第一Feed流信息推送至目标群体，其中，目标群体与目标推拉结合模式相对应。

在一种可能的实现方式中，Feed流实现模块803还用于将第一Feed流信息发送至初始消息队列；

基于第一Feed流信息、初始消息队列和目标群体，生成目标消息队列；

将目标消息队列中的所有第一Feed流信息推送至目标群体。

在一种可能的实现方式中，Feed流实现模块803还用于获取目标群体中所包含的第一用户的数目和用户ID，其中，目标群体中的任意两个用户ID不同；

在初始消息队列中，基于第一用户的数目和用户ID，对第一Feed流信息进行处理，得到目标消息队列。

在一种可能的实现方式中，Feed流实现模块803还用于对第一Feed流信息进行复制，生成与第一用户的数目相同数目的第一Feed流信息，得到第一预设数目的第一Feed流信息；

为第一预设数目的第一Feed流信息中的每个第一Feed流信息配置用户ID，并依据用户ID对第一预设数目的第一Feed流信息进行排序，得到目标消息队列。

在一种可能的实现方式中，Feed流实现模块803还用于针对所有第一Feed流信息中的每个第一Feed流信息，获取每个第一Feed流信息的用户ID；

依据用户ID将每个第一Feed流信息推送至对应的第一用户。

在一种可能的实现方式中，Feed流实现模块803还用于接收第一用户的查询请求；

基于查询请求，通过滑动窗口拉取第二Feed流信息。

在一种可能的实现方式中，Feed流实现模块803还用于基于查询请求，从第一用户的收件箱中获取第一Feed流信息以及与第一用户所关注的所有用户的发件箱中获取第三Feed流信息；

将第一Feed流信息和第三Feed流信息分别按照预设时间轴进行排序，得到第一时间轴信息和第二时间轴信息；

将第一时间轴信息和第二时间轴信息对齐，得到对齐后的时间轴信息；

将滑动窗口从对齐后的时间轴信息的起点开始滑动，并将滑动窗口每滑动一次所获取的数据作为第二Feed流信息，其中，滑动窗口的右边框所对应的预设时间轴上的时间点作为滑动窗口下次滑动的起点。

在一种可能的实现方式中，Feed流实现模块803之后，还包括信息处理模块，信息处理模块用于将第二Feed流信息中的信息进行状态筛选、用户特征数据组合，得到目标Feed流信息。

在一种可能的实现方式中，接收模块801之后，还包括存储模块，存储模块用于将第一Feed流信息存储至多个存储介质中。

图9是本发明实施例提供的终端的示意图。如图9所示，该实施例的终端9包括：处理器901、存储器902以及存储在存储器902中并可在处理器901上运行的计算机程序903。处理器901执行计算机程序903时实现上述各个Feed流实现方法实施例中的步骤，例如图4所示的步骤401至步骤403。或者，处理器901执行计算机程序903时实现上述各个Feed流实现装置实施例中各模块/单元的功能，例如图8所示模块/单元801至803的功能。

本发明还提供一种可读存储介质，可读存储介质中存储有计算机程序，计算机程序被处理器执行时用于实现上述的各种实施方式提供的Feed流实现方法。

其中，可读存储介质可以是计算机存储介质，也可以是通信介质。通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。计算机存储介质可以是通用或专用计算机能够存取的任何可用介质。例如，可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(ApplicationSpecific Integrated Circuits，简称：ASIC)中。另外，该ASIC可以位于用户设备中。当然，处理器和可读存储介质也可以作为分立组件存在于通信设备中。可读存储介质可以是只读存储器(ROM)、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本发明还提供一种程序产品，该程序产品包括执行指令，该执行指令存储在可读存储介质中。设备的至少一个处理器可以从可读存储介质读取该执行指令，至少一个处理器执行该执行指令使得设备实施上述的各种实施方式提供的Feed流实现方法。

在上述设备的实施例中，应理解，处理器可以是中央处理单元(英文：CentralProcessing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：DigitalSignal Processor，简称：DSP)、专用集成电路(英文：Application Specific IntegratedCircuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种Feed流实现方法，其特征在于，包括：

接收第一Feed流信息；

基于推拉策略，判断是否推送所述第一Feed流信息，其中，所述推拉策略包括多维推拉结合模式；

若推送所述Feed流信息，利用目标推拉结合模式实时推送所述第一Feed流信息，以及拉取第二Feed流信息，其中，所述目标推拉结合模式为所述多维推拉结合模式中的一种。

2.如权利要求1所述Feed流实现方法，其特征在于，所述利用目标推拉结合模式实时推送所述第一Feed流信息，包括：

通过消息队列方式将所述第一Feed流信息推送至目标群体，其中，所述目标群体与所述目标推拉结合模式相对应。

3.如权利要求2所述Feed流实现方法，其特征在于，所述通过消息队列方式将所述第一Feed流信息推送至目标群体，包括：

将所述第一Feed流信息发送至初始消息队列；

基于所述第一Feed流信息、所述初始消息队列和所述目标群体，生成目标消息队列；

将所述目标消息队列中的所有第一Feed流信息推送至所述目标群体。

4.如权利要求3所述Feed流实现方法，其特征在于，所述基于所述第一Feed流信息、所述初始消息队列和所述目标群体，生成目标消息队列，包括：

获取所述目标群体中所包含的第一用户的数目和用户ID，其中，所述目标群体中的任意两个用户ID不同；

在所述初始消息队列中，基于所述第一用户的数目和用户ID，对所述第一Feed流信息进行处理，得到所述目标消息队列。

5.如权利要求4所述Feed流实现方法，其特征在于，所述在所述初始消息队列中，基于所述第一用户的数目和用户ID，对所述第一Feed流信息进行处理，得到所述目标消息队列，包括：

对所述第一Feed流信息进行复制，生成与所述第一用户的数目相同数目的第一Feed流信息，得到第一预设数目的第一Feed流信息；

为所述第一预设数目的第一Feed流信息中的每个第一Feed流信息配置用户ID，并依据所述用户ID对所述第一预设数目的第一Feed流信息进行排序，得到所述目标消息队列。

6.如权利要求3所述Feed流实现方法，其特征在于，所述将所述目标消息队列中的所有第一Feed流信息推送至所述目标群体，包括：

针对所述所有第一Feed流信息中的每个第一Feed流信息，获取所述每个第一Feed流信息的用户ID；

依据所述用户ID将所述每个第一Feed流信息推送至对应的第一用户。

7.如权利要求4-6中任一项所述Feed流实现方法，其特征在于，所述利用目标推拉结合模式实时拉取第二Feed流信息，包括：

接收所述第一用户的查询请求；

基于所述查询请求，通过滑动窗口拉取所述第二Feed流信息。

8.一种Feed流实现装置，其特征在于，包括：

接收模块，用于接收第一Feed流信息；

判断模块，用于基于推拉策略，判断是否推送所述第一Feed流信息，其中，所述推拉策略包括多维推拉结合模式；

Feed流实现模块，用于若推送所述Feed流信息，利用目标推拉结合模式实时推送所述第一Feed流信息，以及拉取第二Feed流信息，其中，所述目标推拉结合模式为所述多维推拉结合模式中的一种。

9.一种终端，其特征在于，包括存储器，以及与所述存储器通信连接的一个或多个处理器；

所述存储器中存储有可被所述一个或多个处理器执行的指令，所述指令被所述一个或多个处理器执行，以使所述一个或多个处理器实现如权利要求1至7中任一项所述Feed流实现方法。

10.一种计算机可读存储介质，其特征在于，包括程序或指令，当所述程序或指令在计算机上运行时，实现权利要求1至7中任一项所述Feed流实现方法。

Images