CN111083217A - 一种推送Feed流的方法、装置及电子设备 - Google Patents

Abstract

本公开关于一种推送Feed流的方法、装置及电子设备，解决了推拉结合模式下推送的信息流占用大量服务器存储资源的问题。该方法包括：确定推送的信息流的缓存的数据量超出预设值时，根据缓存的信息流的访问量删除部分信息流；若所述删除的部分信息流包括通过推模式的方式推送的信息流，则确定所述推送的信息流对应的账户，停止向所述账户推送信息流；响应所述账户访问Feed列表的信息流拉取请求消息，将所述请求消息对应的信息流发送到所述账户的Feed列表。

Description

一种推送Feed流的方法、装置及电子设备

技术领域

本发明涉及移动应用技术领域，尤其涉及一种推送Feed流的方法、装置及电子设备。

背景技术

简易信息聚合(Really Simple Syndication，RSS)搭建了一个信息迅速传播的平台，是一种信息聚合的技术，提供一种更为方便、高效的互联网信息的发布和共享。Feed是RSS中用来接收该信息来源的接口，Feed流是一种持续更新并将RSS中的信息呈现给用户的信息流，由于其同时兼顾了大量信息下的展示与消费，如今Feed流产品越来越被大多数互联网产品所使用。

服务器获取Feed流并推送给用户的方式如下：

推Push模式下，服务器会将信息流推送到各个用户的Feed列表，由于推模式下推送的信息存放在用户的Feed列表中，会占用缓存容量，针对一个被关注者，所有关注者都会在各自的Feed列表中存储同一条内容，造成存储空间的浪费，若需要推送的信息量比较大，则需要占用大量的服务器存储资源；

拉Pull模式下，服务器收到用户主动请求访问自身的Feed列表时，将信息流中该用户请求访问的信息推送给该用户，并且会遍历该用户所有的关注对象更新的信息流，因此该方式推送信息流的计算逻辑都放到了在线，响应时间急剧变慢。

发明内容

本发明提供一种推送Feed流的方法、装置及电子设备，解决了推拉结合模式下推送的信息流占用大量服务器存储资源的问题。

第一方面，本发明提供一种推送Feed流的方法，该方法包括：

确定推送的信息流的缓存的数据量超出预设值时，根据缓存的信息流的访问量删除部分信息流；

若所述删除的部分信息流包括通过推模式的方式推送的信息流，则确定所述推送的信息流对应的账户，停止向所述账户推送信息流；

响应所述账户访问Feed列表的信息流拉取请求消息，将所述请求消息对应的信息流发送到所述账户的Feed列表。

作为一种可能的实施方式，根据缓存的信息流的访问量删除部分信息流，包括：

删除在预设时间段内访问量小于预设阈值的缓存的信息流，直至缓存的信息流的数据量不超出预设值。

作为一种可能的实施方式，删除在预设时间段内访问量小于预设阈值的缓存的信息流，包括：

通过最近最少使用LRU算法，删除在预设时间段内访问量小于预设阈值的缓存的信息流。

作为一种可能的实施方式，根据缓存的信息流的访问量删除部分信息流，包括：

根据缓存的信息流的访问量删除缓存池中的部分信息流，并清空所述部分信息流对应的账户当前的Feed列表。

作为一种可能的实施方式，若所述删除的部分信息流包括通过拉模式的方式获取的信息流，该方法还包括：

确定通过拉模式的方式获取的信息流对应的账户；

若当前向所述账户发送的信息流的数据量小于上一时刻向所述账户发送的信息流的数据量，则从缓存的信息流中读取预设大小的信息流发送给所述账户。

第二方面，本发明提供一种推送Feed流的装置，该装置包括删除信息流模块、确定推送账户模块、拉取信息流模块，其中：

删除信息流模块，被配置为执行确定推送的信息流的缓存的数据量超出预设值时，根据缓存的信息流的访问量删除部分信息流；

确定推送账户模块，被配置为执行若所述删除的部分信息流包括通过推模式的方式推送的信息流，则确定所述推送的信息流对应的账户，停止向所述账户推送信息流；

拉取信息流模块，被配置为执行响应所述账户访问Feed列表的信息流拉取请求消息，将所述请求消息对应的信息流发送到所述账户的Feed列表。

作为一种可能的实施方式，所述删除信息流模块具体被配置为执行：

删除在预设时间段内访问量小于预设阈值的缓存的信息流，直至缓存的信息流的数据量不超出预设值。

作为一种可能的实施方式，所述删除信息流模块具体被配置为执行：

通过最近最少使用LRU算法，删除在预设时间段内访问量小于预设阈值的缓存的信息流。

作为一种可能的实施方式，所述删除信息流模块具体被配置为执行：

根据缓存的信息流的访问量删除缓存池中的部分信息流，并清空所述部分信息流对应的账户当前的Feed列表。

作为一种可能的实施方式，所述确定推送账户模块，具体还被配置为执行：

确定通过拉模式的方式获取的信息流对应的账户；

若当前向所述账户发送的信息流的数据量小于上一时刻向所述账户发送的信息流的数据量，则从缓存的信息流中读取预设大小的信息流发送给所述账户。

第三方面，本发明提供一种推送Feed流的电子设备，包括：

处理器；

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

其中，所述处理器被配置为执行所述指令，以实现如下步骤：

确定推送的信息流的缓存的数据量超出预设值时，根据缓存的信息流的访问量删除部分信息流；

若所述删除的部分信息流包括通过推模式的方式推送的信息流，则确定所述推送的信息流对应的账户，停止向所述账户推送信息流；

响应所述账户访问Feed列表的信息流拉取请求消息，将所述请求消息对应的信息流发送到所述账户的Feed列表。

作为一种可能的实施方式，所述处理器具体被配置为执行：

删除在预设时间段内访问量小于预设阈值的缓存的信息流，直至缓存的信息流的数据量不超出预设值。

作为一种可能的实施方式，所述处理器具体被配置为执行：

通过最近最少使用LRU算法，删除在预设时间段内访问量小于预设阈值的缓存的信息流。

作为一种可能的实施方式，所述处理器具体被配置为执行：

根据缓存的信息流的访问量删除缓存池中的部分信息流，并清空所述部分信息流对应的账户当前的Feed列表。

作为一种可能的实施方式，若所述删除的部分信息流包括通过拉模式的方式获取的信息流，所述处理器具体还被配置为执行：

确定通过拉模式的方式获取的信息流对应的账户；

若当前向所述账户发送的信息流的数据量小于上一时刻向所述账户发送的信息流的数据量，则从缓存的信息流中读取预设大小的信息流发送给所述账户。

第四方面，本发明提供一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述第一方面所述方法的步骤。

本发明提供的一种推送Feed流的方法、装置及电子设备，具有以下有益效果：

解决了推拉结合模式下推送的信息流占用大量服务器存储资源的问题，通过控制服务器缓存池中信息流的数据量，将删除的部分信息流对应的推模式的用户的推送方式更改为拉模式，节省部分用户占用的存储资源，能够有效平衡用户体验和存储成本，在保证大部分用户体验的条件下，有效节省存储成本。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1A为本发明实施例提供的一种推模式下Feed流的推送示意图；

图1B为本发明实施例提供的一种推模式下Feed流的推送流程图；

图2A为本发明实施例提供的一种拉模式下Feed流的推送示意图；

图2B为本发明实施例提供的一种拉模式下Feed流的推送流程图；

图3为本发明实施例提供的一种推送Feed流的方法流程图；

图4为本发明实施例提供的一种LRU算法示意图；

图5为本发明实施例提供的一种将推模式更改为拉模式的流程图；

图6为本发明实施例提供的一种推送Feed流的方法详细流程图；

图7为本发明实施例提供的另一种推送Feed流的方法详细流程图；

图8为本发明实施例提供的一种推送Feed流的装置示意图；

图9为本发明实施例提供的一种推送Feed流的设备示意图。

具体实施方式

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

下面对文中出现的一些词语进行解释：

1、本发明实施例中的“Feed”可以是将用户主动订阅的若干消息源组合在一起形成内容聚合器，帮助用户持续地获取最新的订阅源内容，Feed是简易信息聚合(ReallySimple Syndication，RSS)中用来接收该信息来源的接口。

2、本发明实施例中的Feed流是一种持续更新的信息流，可以将RSS中的信息推送给用户。

Feed流的展现形式有很多种，包括但不限于：基于时间线的展现形式timeline、基于智能排序的展现形式rank，其中：

timeline是最典型的feed流展示方式，按照Feed流内容更新的时间先后顺序，将内容展示给用户，早期的微博、朋友圈都是典型的timeline；rank是按照某些因素计算Feed流内容的权重，从而决定Feed流内容展示的先后顺序，例如当前的微博主页信息流算法便采用最新的智能排序。

3、本发明实施例中的“Feed列表”可以是一列可以不断向下滑动不断加载的信息列表。Feed列表可以与用户对应，每个用户都有一个属于自己的Feed列表。

Feed列表使用简单、信息量大且兼容性好，每个Feed条目都是一个独立的信息，对Feed列表的操作包括但不限于点击、向下滑动加载，Feed列表中可以展示文字、图片、视频、甚至是可操作的卡片等。

目前服务器获取Feed流并推送给用户的方式主要存在如下缺点：

推Push模式下，若某个用户更新了动态信息，服务器会向关注该用户的每个关注者进行该动态信息的推送，将推送的信息存放在服务器的缓存池中并推送到每个关注者的Feed列表，占用缓存资源，若需要推送的信息量比较大，则需要占用大量的服务器缓存资源；

推Push模式下虽然逻辑简单、实现容易、响应时间快，但是随着用户量的增加，推送方式资源占用多的劣势随之显现出来，针对一个被关注者，所有关注者都会存储同一条内容，造成存储空间的浪费，例如，在某平台存在关注关系，如果用户关注的人发布了新内容，那么直接将新内容存放到用户的feed列表，用户读取自己的关注内容时直接读取自己的feed列表；

拉Pull模式下，服务器根据用户的主动请求，确定用户请求访问自身的Feed列表时，会将信息流中该用户请求访问的信息推送给该用户并缓存到服务器的缓存池中，但该推送方式的缺陷是，会实时计算该用户请求访问的信息并将该信息推送给该用户，使得Feed流推送的计算逻辑都放到了在线，响应时间急剧变慢；

拉Pull模式下虽然节省了大量资源占用，但用户在访问自己的关注内容时要先进行feed拉取操作，使得用户可能需要等待一段时间，影响用户体验。例如，在某平台存在关注关系，如果用户关注的人发布了新内容时，不进行任何操作。当用户读取自己关注的内容时遍历所有关注对象，获取关注对象过去一段时间发布的作品生成feed列表，再展现给用户。

对于目前的推拉结合模式下，服务器基于用户的关注操作确定用户的活跃度，对于活跃用户使用推模式向用户推送信息流，对于不活跃的用户使用拉模式向用户推送信息流，该方式虽然可以在一定程度上减少响应时间，但对于活跃度比较高的应用APP来说，仍会存在由于需要占用大量的服务器资源导致服务器存储成本及推送速度满的问题。

为了解决上述技术问题，本发明实施例提出一种推送Feed流的方法，基于删除的部分信息流来修改对应的用户的推送方式，节省部分用户占用的存储资源，从而解决了推拉结合模式下推送的信息流占用大量服务器存储资源的问题。

本实施例中的推送Feed流的方法可以针对某个应用APP，例如针对某APP中注册的所有用户，通过本实施例中推送Feed流的方法为该APP中的所有用户推送信息流，能够保证该APP用户的使用体验的同时很好的控制服务器设备侧存储成本。

需要说明的是，本实施例推送Feed流的方法可应用于服务器设备，本实施例的服务器设备包括具有固定的IP地址，为网络用户提供服务的节点，用于实现资源共享。

本实施例推送Feed流的方法也可应用于其他与服务器具有相同功能的智能设备，本实施例对上述推送Feed流的方法的应用场景及应用设备不作过多限定。

需要说明的是，本实施例中的推送Feed流的方法可以应用于所有账户的信息流的推送方式，通常一个账户的推送方式都是预先设定好的，一种是推模式，另一种是拉模式。一种可能的实施方式是，可以获取向各账户推送的信息流并缓存，将缓存的信息流按照各账户对应的推送方式进行推送，所述推送方式包括推模式和拉模式。

本实施例的推送Feed流的方法可针对某个APP应用，面向该APP应用注册的所有用户，可以预先记录各用户对Feed流的访问情况，可将访问情况大于预设阈值的用户定义为活跃用户，将访问情况不大于预设阈值的用户定义为非活跃用户，本实施例对如何定义用户的活跃或非活跃不作过多限定。

例如针对某APP应用，可以预先记录下各注册用户对各自关注列表(即Feed列表)的访问情况，如果每天至少访问1次的即可定义为活跃用户，每3天访问1次的可定义为非活跃用户。

针对活跃用户，确定所述活跃用户对应的推送方式为推模式；

针对非活跃用户，确定所述活跃用户对应的推送方式为拉模式。

确定各用户的推送方式后，对于推模式的用户，服务器将获取的Feed流缓存到服务器的缓存池中，将缓存的信息流推送到该用户的Feed列表；对于拉模式的用户，服务器并不会提前获取Feed流缓存到服务器的缓存池中，而是通过实时计算推送的信息流，将该信息流推送到用户的Feed列表并缓存到服务器中，即对于拉模式的用户，在该用户访问Feed列表时，将获取的信息流拉取到该用户的Feed列表并缓存到服务器中。

如图1A所示，在推模式下Feed流的推送流程包括从生成信息流的用户端(生产用户端)到接收该信息流的用户端(消费用户端)，由于消费用户端有n个，则需要将获取的信息流复制n份缓存在服务器的缓存池中，如图中缓存1、缓存2、缓存3……缓存n所示，然后推送给各用户端。

具体的，如图1B所示，推模式下Feed流的推送流程如下：

步骤100、服务器获取同一生产用户端的信息流；

步骤101、将获取的信息流缓存并复制N份推送到该信息流对应的N个消费用户端的Feed列表；

其中，缓存并复制的N份信息流与N个消费用户端的Feed列表一一对应。

步骤102、消费用户端通过网络访问服务器，从缓存中直接读取Feed列表。

该方式下，服务器主动将缓存的信息流推送到该消费用户的Feed列表，不管该消费用户是否访问自身的Feed列表，只要该消费用户关注的生产用户发布新信息时，服务器便获取该新信息缓存到缓存池中，并将缓存池中的该新信息推送到该消费用户的Feed列表，这样消费用户在访问自身的Feed列表时，可以直接读取Feed列表中的信息。

对于拉模式的用户，在该用户访问Feed列表时，将缓存的信息流拉取到该用户的Feed列表；

如图2A所示，在拉模式下Feed的推送与推模式相反，生成信息流的用户端(生产用户端)会将生成的信息流存储到自身的作者作品列表中，关注该用户的用户端(消费用户端)在访问自身的Feed列表时，服务器才会将所述生成的信息流推送到该消费用户端的Feed列表中，其中生产用户端为n个，消费用户端1关注了生产用户端1、生产用户端2，当消费用户端访问自身的Feed列表时，服务器会获取生产用户端1、生产用户端2在一段时间内发布的新信息推送到消费用户端的Feed列表。

具体的，如图2B所示，拉模式下Feed流的推送流程如下：

步骤200、用户访问自身的Feed列表；

步骤201、触发服务器获取信息流，从该用户对应关注的信息生产用户端获取一段时间内发布的新信息；

步骤202、将获取的发布的新信息拉取到该用户的Feed列表。

该方式下，服务器需要收到该用户访问Feed列表的触发，才会获取新信息缓存到缓存池，并从缓存池中将该新信息推送到该用户的Feed列表，即使该用户关注的用户发布了新信息，只要用户未触发访问Feed列表，则服务器不会产生任何操作，当用户访问Feed列表时，触发服务器遍历该用户关注的所有对象，获取该关注的对象过去一段时间发布的信息生成该用户的Feed列表。

上述推拉模式的确定，可能只基于预先记录的各注册用户的访问情况确定的，但各注册用户在使用APP的过程中，并不能保证预先定义的活跃用户一直处于活跃状态，活跃用户也可能在几天内才访问1次，因此预先定义的活跃用户虽然对应推模式的推送方式，但在该用户不活跃的情况下，服务器仍会将该用户对应的信息流存储到缓存池，并按推模式进行信息流的推送，因此在这种情况下，容易造成服务器的存储资源的浪费。

由于所述服务器的缓存池的存储资源有限，为了更好的控制存储成本，本发明实施例提供了一种推送Feed流的方法，如图3所示，实施流程如下：

步骤300、确定推送的信息流的缓存的数据量超出预设值时，根据缓存的信息流的访问量删除部分信息流；

容易理解的是，本发明实施例中的推送的信息流可以针对任一或任多个账户推送的信息流，本发明实施例能够对缓存池中缓存的信息流的数据量进行判断，并基于访问量删除部分信息流，缓存的信息流中包括一个或多个账户的信息流，删除的部分信息流是基于访问量的，删除的部分信息流也包括一个或多个账户的信息流。

本实施例中缓存池的存储资源可以大于等于所有账户的Feed列表中缓存的存储资源，由于各账户Feed列表中缓存的信息流都存储在服务器的缓存池中，一种可能的情况是，所有账户的Feed列表中缓存的存储资源的总大小与缓存池中的存储资源的大小是一致的，本实施例在删除缓存池的部分信息流时，对应的可以删除部分账户Feed列表中缓存的信息流。删除的部分信息流能够保证服务器的缓存的数据量不会持续性增加。

在具体实施中，可以设定缓存池的缓存大小为X，其中X为正整数，缓存单位包括但不限于KB、MB，将缓存池存储的数据设置为可逐出，如果缓存用量超出X，缓存系统会自动删除部分数据，本实施例中缓存可删除或缓存可逐出保证了系统的缓存用量不会持续性增加。

作为一种可能的实施方式，根据缓存的信息流的访问量删除缓存池中的部分信息流，并清空所述部分信息流对应的账户当前的Feed列表。

本实施例中删除部分信息流依据的是缓存的信息流的访问量，容易理解的是，为了更好的控制存储成本，可以删除访问量低于预设值的信息流。

作为一种可能的实施方式，删除在预设时间段内访问量小于预设阈值的缓存的信息流，直至缓存的信息流的数据量不超出预设值。

本实施例还可以通过最近最少使用LRU算法，删除在预设时间段内访问量小于预设阈值的缓存的信息流。其中，最近最少使用(Least recently used，LRU)算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。

如图4所示，LRU算法将最近使用的条目存放到靠近缓存顶部的位置，当一个新条目被访问时，LRU将它放置到缓存的顶部，当缓存达到极限时，较早之前访问的条目将从缓存底部开始被移除。

本实施例还可以通过缓存淘汰算法，删除在预设时间段内访问量小于预设阈值的缓存的信息流，包括但不限于：最不经常使用(Least Frequently Used，LFU)算法、自适应缓存替换(Adaptive Replacement Cache，ARC)算法。

LFU算法根据数据的历史访问频率来淘汰数据，其核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”，这个缓存算法使用一个计数器来记录条目被访问的频率，通过使用LFU缓存算法，最低访问数的条目首先被移除；

ARC算法是一个缓存容量可变的缓存算法，它的容量可以根据系统可用内存的状态进行调整，当系统内存比较充裕的时候，它的容量可以自动增加，当系统内存比较紧张(如其它事情需要内存)的时候，它的容量可以自动减少，这个缓存算法同时跟踪记录LFU和LRU，以及驱逐缓存条目，来获得可用缓存的最佳使用。

本实例中确定缓存的信息流的数据量超出预设值的时机，可以是每隔设定时间确定缓存的信息流的数据量是否超出预设值，也可以是确定缓存的信息流的数据量达到设定值后，每隔设定时间确定缓存的信息流的数据量是否超出预设值，本实例对何时确定缓存的信息流的数据量是否超出预设值不作过多限定。

删除缓存池中的部分信息流能够一定程度上保证缓存池中的信息流的有效推送，由于访问量较少的信息流可能包括推模式的账户的信息流，即该推模式的账户并非活跃账户，服务器却仍使用推模式对该账户进行信息流的推送，虽然暂时能够控制缓存池的存储资源，但长期看来，仍对该非活跃账户采用推模式推送，基于此，本实施例通过如下步骤，对采用推模式的非活跃账户的推送方式进行了更改。

步骤301、若所述删除的部分信息流包括通过推模式的方式推送的信息流，则确定所述推送的信息流对应的账户，停止向所述账户推送信息流；

步骤302、响应所述账户访问Feed列表的信息流拉取请求消息，将所述请求消息对应的信息流发送到所述账户的Feed列表。

实施中，如果确定删除的部分信息流包括通过推模式的方式推送的信息流，则说明所述推送的信息流对应的账户的推送方式是推模式，但所述账户对应的信息流被服务器删除，说明所述账户可能为不活跃的账户，则需要将所述账户的推送方式更改为拉模式从而节省缓存资源，需要说明的是，所述推送的信息流对应的账户可以为一个，也可以为多个。待确定所述推送的信息流对应的账户，停止向所述账户推送信息流，也就是说，此时不会再通过推模式的方式向所述账户推送信息流，当服务器侧响应所述账户访问Feed列表的信息流拉取请求消息时，才会将所述请求消息对应的信息流发送到所述账户的Feed列表，即通过拉模式的方式将对应的信息流推送给所述账户。

本实施例中如果所述删除的部分信息流包括通过推模式的方式推送的信息流时，一种可能的情况是根据缓存的信息流的访问量删除缓存池中的部分信息流，并清空所述部分信息流对应的账户当前的Feed列表，也就是说删除缓存池中的部分信息流的同时清空所述部分信息流对应的账户当前的Feed列表，即此时推模式的账户当前的Feed列表被清空，那么服务器不再主动将缓存的信息流推送到该账户的Feed列表，也就是说该账户的数据列表保持清空状态；

当该账户请求访问Feed列表时，则触发拉模式，服务器遍历该账户的关注对象，将设定时段内该关注对象发布的信息流缓存到缓存池，并从缓存池中将该设定时段内发布的信息流推送到该账户的Feed列表，该账户重新生成自身的Feed列表，并且可以进行读取。

如图5所示，将推模式更改为拉模式的具体实施步骤如下：

步骤500、确定推送的信息流的缓存的数据量超出预设值时，根据缓存的信息流的访问量删除部分信息流；

步骤501、若所述删除的部分信息流包括通过推模式的方式推送的信息流，清空所述通过推模式的方式推送的信息流对应的账户当前的Feed列表；

步骤502、确定所述推送的信息流对应的账户，停止向所述账户推送信息流；

步骤503、响应所述账户访问Feed列表的信息流拉取请求消息；

步骤504、将所述请求消息对应的信息流发送到所述账户的Feed列表；

步骤505、重新生成所述账户的Feed列表，以便读取Feed列表中的信息。

该方式通过将推模式下不活跃的账户更改为拉模式下的账户，在保证大部分用户体验的情况下，很好的控制存储成本，提供了用户体验和存储成本之间的可调节的平衡点。

为了避免由于允许删除部分信息流，导致拉模式下的账户拉不到数据或者拉取到的数据较少的情况，本实施例还提供一种针对拉模式下的强制拉取方式。

作为一种可能的实施方式，若所述删除的部分信息流包括通过拉模式的方式获取的信息流，该方法还包括：

确定通过拉模式的方式获取的信息流对应的账户；

若当前向所述账户发送的信息流的数据量小于上一时刻向所述账户发送的信息流的数据量，则从缓存的信息流中读取预设大小的信息流发送给所述账户。

若当前通过拉模式的方式获取的信息流对应的账户读取Feed列表时，该Feed列表中缓存的数据量比上一时刻缓存的数据量少时，便进行强制拉取。

本发明实施例能够提供目前对于高活跃用户的推拉模型解决方案，解决使用推拉模型的存储成本问题，能够在用户体验和存储成本之间进行权衡，既能保证绝大部分用户的用户体验，又能比较好的控制存储成本。

下面分别以推模式账户、拉模式账户为例，对本发明实施例提供的一种推送Feed流的方法进行详细说明。

如图6所示，具体实施步骤如下：

步骤600、获取向各账户推送的信息流并缓存；

步骤601、判断推送的信息流的缓存的数据量是否超出预设值，如果是执行步骤602、否则返回步骤600；

步骤602、根据缓存的信息流的访问量删除部分信息流；

具体的，可以是通过最近最少使用LRU算法，删除在预设时间段内访问量小于预设阈值的缓存的信息流。

步骤603、判断所述删除的部分信息流是否包括通过推模式的方式推送的信息流，如果是执行步骤604，否则返回步骤601；

步骤604、确定所述推送的信息流对应的账户，停止向所述账户推送信息流；

步骤605、响应所述账户访问Feed列表的信息流拉取请求消息，将所述请求消息对应的信息流发送到所述账户的Feed列表。

更进一步的，本实施例还提供一种推送Feed流的方法，一方面可以根据需要修改推模式用户的推送方式，另一方面还可以保证拉模式用户由于允许缓存池的数据删除导致拉不到数据或者拉取到较少数据的情况，保证用户的使用体验，下面对本发明实施例提供的一种推送Feed流的方法进行详细说明。

如图7所示，若所述删除的部分信息流包括通过拉模式的方式获取的信息流，具体实施例步骤如下：

步骤700、获取向各账户推送的信息流并缓存；

步骤701、判断推送的信息流的缓存的数据量是否超出预设值，如果是执行步骤702，否则执行步骤700；

步骤702、根据缓存的信息流的访问量删除部分信息流；

具体的，可以是通过最近最少使用LRU算法，删除在预设时间段内访问量小于预设阈值的缓存的信息流。

步骤703、判断所述删除的部分信息流是否包括通过拉模式的方式获取的信息流，如果是执行步骤704，否则执行步骤707；

步骤704、确定通过拉模式的方式获取的信息流对应的账户；

步骤705、判断当前所述账户发送的信息流的数据量，是否为空或小于上一时刻向所述账户发送的信息流的数据量，如果是，执行步骤706，否则执行步骤701；

步骤706、从缓存的信息流中读取预设大小的信息流发送给所述账户；

步骤707、确定所述推送的信息流对应的账户，停止向所述账户推送信息流，响应所述账户访问Feed列表的信息流拉取请求消息，将所述请求消息对应的信息流发送到所述账户的Feed列表。

基于相同的发明构思，本发明实施例还提供了一种推送Feed流的装置，由于该装置即是本发明实施例中的方法中的装置，并且该装置解决问题的原理与该方法相似，因此该装置的实施可以参见方法的实施，重复之处不再赘述。

如图8所示，该装置包括删除信息流模块800、确定推送账户模块801、拉取信息流模块802，其中：

删除信息流模块800，被配置为执行确定推送的信息流的缓存的数据量超出预设值时，根据缓存的信息流的访问量删除部分信息流；

确定推送账户模块801，被配置为执行若所述删除的部分信息流包括通过推模式的方式推送的信息流，则确定所述推送的信息流对应的账户，停止向所述账户推送信息流；

拉取信息流模块802，被配置为执行响应所述账户访问Feed列表的信息流拉取请求消息，将所述请求消息对应的信息流发送到所述账户的Feed列表。

作为一种可能的实施方式，所述删除信息流模块800具体被配置为执行：

删除在预设时间段内访问量小于预设阈值的缓存的信息流，直至缓存的信息流的数据量不超出预设值。

作为一种可能的实施方式，所述删除信息流模块800具体被配置为执行：

通过最近最少使用LRU算法，删除在预设时间段内访问量小于预设阈值的缓存的信息流。

作为一种可能的实施方式，所述删除信息流模块800具体被配置为执行：

根据缓存的信息流的访问量删除缓存池中的部分信息流，并清空所述部分信息流对应的账户当前的Feed列表。

作为一种可能的实施方式，所述确定推送账户模块801具体还被配置为执行：

确定通过拉模式的方式获取的信息流对应的账户；

若当前向所述账户发送的信息流的数据量小于上一时刻向所述账户发送的信息流的数据量，则从缓存的信息流中读取预设大小的信息流发送给所述账户。

基于相同的发明构思，本发明实施例还提供了一种推送Feed流的电子设备，由于该设备即是本发明实施例中的方法中的设备，并且该设备解决问题的原理与该方法相似，因此该设备的实施可以参见方法的实施，重复之处不再赘述。

如图9所示，该设备包括：

处理器900；

用于存储所述处理器900可执行指令的存储器901；

其中，所述处理器900被配置为执行所述指令，以实现如下步骤：

确定推送的信息流的缓存的数据量超出预设值时，根据缓存的信息流的访问量删除部分信息流；

若所述删除的部分信息流包括通过推模式的方式推送的信息流，则确定所述推送的信息流对应的账户，停止向所述账户推送信息流；

响应所述账户访问Feed列表的信息流拉取请求消息，将所述请求消息对应的信息流发送到所述账户的Feed列表。

作为一种可能的实施方式，所述处理器900具体被配置为执行：

删除在预设时间段内访问量小于预设阈值的缓存的信息流，直至缓存的信息流的数据量不超出预设值。

作为一种可能的实施方式，所述处理器900具体被配置为执行：

通过最近最少使用LRU算法，删除在预设时间段内访问量小于预设阈值的缓存的信息流。

作为一种可能的实施方式，所述处理器900具体被配置为执行：

根据缓存的信息流的访问量删除缓存池中的部分信息流，并清空所述部分信息流对应的账户当前的Feed列表。

作为一种可能的实施方式，若所述删除的部分信息流包括通过拉模式的方式获取的信息流，所述处理器900具体还被配置为执行：

确定通过拉模式的方式获取的信息流对应的账户；

若当前向所述账户发送的信息流的数据量小于上一时刻向所述账户发送的信息流的数据量，则从缓存的信息流中读取预设大小的信息流发送给所述账户。

基于相同的发明构思，本发明实施例还提供一种计算机存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如下步骤：

确定推送的信息流的缓存的数据量超出预设值时，根据缓存的信息流的访问量删除部分信息流；

若所述删除的部分信息流包括通过推模式的方式推送的信息流，则确定所述推送的信息流对应的账户，停止向所述账户推送信息流；

响应所述账户访问Feed列表的信息流拉取请求消息，将所述请求消息对应的信息流发送到所述账户的Feed列表。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的设备。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令设备的制造品，该指令设备实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种推送Feed流的方法，其特征在于，该方法包括：

确定推送的信息流的缓存的数据量超出预设值时，根据缓存的信息流的访问量删除部分信息流；

若所述删除的部分信息流包括通过推模式的方式推送的信息流，则确定所述推送的信息流对应的账户，停止向所述账户推送信息流；

响应所述账户访问Feed列表的信息流拉取请求消息，将所述请求消息对应的信息流发送到所述账户的Feed列表。

2.根据权利要求1所述的方法，其特征在于，根据缓存的信息流的访问量删除部分信息流，包括：

删除在预设时间段内访问量小于预设阈值的缓存的信息流，直至缓存的信息流的数据量不超出预设值。

3.根据权利要求2所述的方法，其特征在于，根据缓存的信息流的访问量删除部分信息流，包括：

根据缓存的信息流的访问量删除缓存池中的部分信息流，并清空所述部分信息流对应的账户当前的Feed列表。

4.根据权利要求1所述的方法，其特征在于，若所述删除的部分信息流包括通过拉模式的方式获取的信息流，该方法还包括：

确定通过拉模式的方式获取的信息流对应的账户；

若当前向所述账户发送的信息流的数据量小于上一时刻向所述账户发送的信息流的数据量，则从缓存的信息流中读取预设大小的信息流发送给所述账户。

5.一种推送Feed流的装置，其特征在于，该装置包括删除信息流模块、确定推送账户模块、拉取信息流模块，其中：

删除信息流模块，被配置为执行确定推送的信息流的缓存的数据量超出预设值时，根据缓存的信息流的访问量删除部分信息流；

确定推送账户模块，被配置为执行若所述删除的部分信息流包括通过推模式的方式推送的信息流，则确定所述推送的信息流对应的账户，停止向所述账户推送信息流；

拉取信息流模块，被配置为执行响应所述账户访问Feed列表的信息流拉取请求消息，将所述请求消息对应的信息流发送到所述账户的Feed列表。

6.根据权利要求5所述的装置，其特征在于，所述删除信息流模块具体被配置为执行：

删除在预设时间段内访问量小于预设阈值的缓存的信息流，直至缓存的信息流的数据量不超出预设值。

7.根据权利要求6所述的装置，其特征在于，所述删除信息流模块具体被配置为执行：

根据缓存的信息流的访问量删除缓存池中的部分信息流，并清空所述部分信息流对应的账户当前的Feed列表。

8.根据权利要求5所述的装置，其特征在于，所述确定推送账户模块，具体还被配置为执行：

确定通过拉模式的方式获取的信息流对应的账户；

若当前向所述账户发送的信息流的数据量小于上一时刻向所述账户发送的信息流的数据量，则从缓存的信息流中读取预设大小的信息流发送给所述账户。

9.一种推送Feed流的电子设备，其特征在于，包括：

处理器；

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

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至4中任一所述的一种推送Feed流的方法。

10.一种计算机存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1～4任一所述的一种推送Feed流的方法。

Images