CN106941509B - 用户信息流的请求方法及装置 - Google Patents

Abstract

本申请提供一种用户信息流的请求方法及装置，其中的方法包括：接收客户端发送的用户成功登录的通知消息；所述通知消息用于触发启动信息流更新进程；当接收到客户端发送的用户成功登录的通知消息后，启动所述信息流更新进程针对所述用户的信息流进行更新；当接收到所述客户端发送的信息流访问请求后，将更新完成的信息流推送至所述客户端。本申请可以在用户主动访问信息流时，迅速的得到响应。

Description

用户信息流的请求方法及装置

技术领域

本申请涉及通信领域，尤其涉及一种用户信息流的请求方法及装置。

背景技术

在社交应用中，用户通过查看社交应用中显示的信息流(Feeds信息流)，可以帮助用户实时的了解到所关注好友的最近动向。其中，Feeds信息流，通常包括用户所关注好友发送的文字、图片以及视频等社交信息流；例如，在微博等社交平台中，Feeds信息流通常包括用户关注的其他用户所发送的文字、图片以及视频等社交信息。然而，随着用户所关注的好友数量的增多，用户在访问Feeds信息流时，由于数据更新量大，可能需要服务端耗费大量时间在多路数据查询和合并上，从而造成用户在请求Feeds信息流时，无法得到及时响应的，从而影响用户体验。

发明内容

本申请提出一种用户信息流的请求方法，该方法包括：

接收客户端发送的用户成功登录的通知消息；所述通知消息用于触发启动信息流更新进程；

当接收到客户端发送的用户成功登录的通知消息后，启动所述信息流更新进程针对所述用户的信息流进行更新；

当接收到所述客户端发送的信息流访问请求后，将更新完成的信息流推送至所述客户端。

可选的，所述方法还包括：

当所述用户的信息流更新完成后，结束所述信息流更新进程。

可选的，所述信息流访问请求用于触发启动所述信息流更新进程；

所述当接收到所述客户端发送的信息流访问请求后，将更新完成的信息流推送至所述客户端包括：

当接收到所述客户端发送的信息流访问请求时，判断所述用户的信息流是否更新完成；

如果所述用户的信息流已更新完成，启动所述信息流更新进程针对所述用户的信息流进行更新，并将已更新完成的信息流推送至所述客户端。

可选的，所述方法还包括：

当启动所述信息流更新进程后，判断所述用户的信息流是否更新完成；

如果所述用户的信息流已更新完成，将本次更新完成的信息流与上一次更新完成的信息流的差值数据发送至所述客户端。

可选的，所述如果所述用户的信息流已更新完成，将本次更新完成的信息流与上一次更新完成的信息流的差值数据推送至所述客户端包括：

如果所述用户的信息流已更新完成，判断本次更新完成的信息流与上一次更新完成的信息流相比是否发生更新；

如果本次更新完成的信息流与上一次更新完成的信息流相比发生了更新，向所述客户端发送所述用户的信息流发生更新的通知消息；

当接收到所述客户端发送的针对所述通知消息的信息流获取请求时，计算本次更新完成的信息流与上一次更新完成的信息流的差值数据，并将计算出的所述差值数据返回至所述客户端。

可选的，所述如果所述用户的信息流已更新完成，将本次更新完成的信息流与上一次更新完成的信息流的差值数据推送至所述客户端包括：

如果所述用户的信息流已更新完成，判断本次更新完成的信息流与上一次更新完成的信息流相比是否发生更新；

如果本次更新完成的信息流与上一次更新完成的信息流相比发生了更新，计算本次更新完成的信息流与上一次更新完成的信息流的差值数据，并将计算出的所述差值数据推送至所述客户端。

本申请还提出一种用户信息流的请求装置，该装置包括：

接收模块，用于接收客户端发送的用户成功登录的通知消息；所述通知消息用于触发启动信息流更新进程；

启动模块，用于在接收到客户端发送的用户成功登录的通知消息后，启动所述信息流更新进程针对所述用户的信息流进行更新；

推送模块，用于在接收到所述客户端发送的信息流访问请求后，将更新完成的信息流推送至所述客户端。

可选的，所述装置还包括：

结束模块，用于在所述用户的信息流更新完成后，结束所述信息流更新进程。

可选的，所述信息流访问请求用于触发启动所述信息流更新进程；

所述推送模块具体用于：

当接收到所述客户端发送的信息流访问请求时，判断所述用户的信息流是否更新完成；

如果所述用户的信息流已更新完成，启动所述信息流更新进程针对所述用户的信息流进行更新，并将已更新完成的信息流推送至所述客户端。

可选的，所述推送模块进一步用于：

当启动所述信息流更新进程后，判断所述用户的信息流是否更新完成；

如果所述用户的信息流已更新完成，将本次更新完成的信息流与上一次更新完成的信息流的差值数据发送至所述客户端。

可选的，所述推送模块进一步用于：

如果所述用户的信息流已更新完成，判断本次更新完成的信息流与上一次更新完成的信息流相比是否发生更新；

如果本次更新完成的信息流与上一次更新完成的信息流相比发生了更新，向所述客户端发送所述用户的信息流发生更新的通知消息；

当接收到所述客户端发送的针对所述通知消息的信息流获取请求时，计算本次更新完成的信息流与上一次更新完成的信息流的差值数据，并将计算出的所述差值数据返回至所述客户端。

可选的，所述推送模块进一步用于：

如果所述用户的信息流已更新完成，判断本次更新完成的信息流与上一次更新完成的信息流相比是否发生更新；

如果本次更新完成的信息流与上一次更新完成的信息流相比发生了更新，

计算本次更新完成的信息流与上一次更新完成的信息流的差值数据，并将计算出的所述差值数据推送至所述客户端。

本申请中，通过接收客户端发送的用户成功登录的通知消息；所述通知消息用于触发启动信息流更新进程；当接收到客户端发送的用户成功登录的通知消息后，启动所述信息流更新进程针对所述用户的信息流进行更新；当接收到所述客户端发送的信息流访问请求后，将更新完成的信息流推送至所述客户端；可以实现在用户成功登陆后，立即针对该用户的信息流进行更新，当用户主动访问信息流时，可以将已更新完成的该用户的信息流推送给该用户，从而使得用户在主动访问信息流时，能够得到迅速的响应，不会由于数据更新量过大而造成数据更新不及时，用户等待时间较长的问题。

附图说明

图1是本申请一实施例提供的一种用户信息流的请求方法的流程图；

图2是本申请一实施例提供的一种用户信息流的请求装置的逻辑框图；

图3是本申请一实施例提供的承载所述一种用户信息流的请求装置的服务端的硬件结构图。

具体实施方式

在相关技术中，用户在访问Feeds信息流时，通常存在拉取模式、推送模式以及拉取模式和推送模式相结合三种不同的Feeds信息流访问模式。在这三种模式下下，响应用户的访问请求的处理方式也各不相同。

在拉取模式下，用户关注的人员的Feeds信息流，都是在用户主动访问时才进行更新。当用户关注的人员产生新的Feeds信息时，服务端并不立即主动更新该用户的Feeds信息流，该用户在未主动访问关注的人员的Feeds信息流时，该用户对于所关注的人员的Feeds信息的变化是毫不知情的，当用户在主动访问关注的人员的Feeds信息流时，服务端对该用户关注的所有人员当前的Feeds信息进行更新，然后对更新的数据进行合并存储后，返回给该用户的客户端。

然而，对于拉取模式，由于用户关注的人员的Feeds信息只有在该用户主动访问的时候才会实时的进行更新，因此当该用户关注的人员数据较大时，大量的数据查询合并需要很长的时间，用户需要等待服务端整个数据更新过程处理完之后，才会得到服务端返回的Feeds信息。可见，在这种情况下，用户在主动访问关注的人员的Feeds信息时，不能得到及时的响应，需要等待一个较长的事件，尤其在弱网的情况下更为明显。

在推送模式下，数据更新方式与拉取模式相反，当用户关注的人员产生新的Feeds信息时，服务端会立刻通知该用户，从而可以保证客户端本地保存的用户的Feeds信息流均为最新的数据。当用户从客户端发起Feeds信息流访问请求时，客户端不需要做任何的计算逻辑，直接查询本地保存的Feeds信息流向用户显示即可。

然而，对于推送模式，当用户关注的人数达到一定的数量时，比如数十万计，此时服务端一次Feeds信息流的推送，需要将更新后的Feeds信息流拷贝成数十万份进行推送。可见，通过这种方式，会大大增加服务端的计算压力。

在拉取模式和推送模式相结合的模式下，对于“粉丝”数量小于阈值的用户采用推送模式，而对于“粉丝”数量大于阈值的用户，采用拉取模式，即该用户在产生新的Feeds信息时，并不向其“粉丝”推送数据更新，而是在其粉丝产生访问请求时，再把该用户更新的数据合并到该粉丝的Feeds信息流中，此时和拉取模式一样，服务端仍然会有更新以及合并存储的过程，处理完成之后，再将更新后的数据返回给发起请求的客户端。可见，通过这种方式，仍然会存在拉取模式下，用户在访问Feeds信息流时，不能得到及时的响应的问题。

有鉴于此，本申请提出一种用户信息流的请求方法，通过接收客户端发送的用户成功登录的通知消息；所述通知消息用于触发启动信息流更新进程；当接收到客户端发送的用户成功登录的通知消息后，启动所述信息流更新进程针对所述用户的信息流进行更新；当接收到所述客户端发送的信息流访问请求后，将更新完成的信息流推送至所述客户端，可以实现在用户成功登陆后，立即针对该用户的信息流进行更新，当用户主动访问信息流时，可以将已更新完成的该用户的信息流推送给该用户，从而使得用户在主动访问信息流时，能够得到迅速的响应，不会由于数据更新量过大而造成数据更新不及时，用户等待时间较长的问题。

下面通过具体实施例并结合具体的应用场景对本申请进行描述。

请参考图1，图1是本申请一实施例提供的一种用户信息流的请求方法，应用于服务端，所述方法执行以下步骤：

步骤101，接收客户端发送的用户成功登录的通知消息；所述通知消息用于触发启动信息流更新进程；

步骤102，当接收到客户端发送的用户成功登录的通知消息后，启动所述信息流更新进程针对所述用户的信息流进行更新；

步骤103，当接收到所述客户端发送的信息流访问请求后，将更新完成的信息流推送至所述客户端。

上述客户端可以包括具有社交功能的客户端软件；例如，上述客户端可以包括社交类APP；比如微博、微信等；上述客户端也可以包括具有社交功能的非社交类APP；比如，该客户端可以是具有“好友圈”功能的理财APP。

上述服务端可以包括面向上述客户端提供服务，向为使用上述客户端的用户更新Feeds信息流，以及向上述客户端推送更新后的Feeds信息流的服务器、服务器集群或者基于服务器集群构建的云平台。

其中，承载上述客户端的硬件环境，在本申请中不进行特别限定；例如，可以是用户的移动智能终端或者PC终端。即在本申请中，上述客户端可以承载在用户的触屏智能终端上的APP应用，也可以是承载在PC终端的web应用。

在本例中，服务端可以通过在后台启动预设的信息流更新进程，针对使用上述客户端的用户的Feeds信息流进行更新。

其中，该信息流更新进程为后台进程，服务端可以对预先对该更新进程进行加锁处理，以保证在对用户的Feeds信息流进行更新时，服务端只通过该唯一的信息流更新进程对该用户的Feeds信息流进行更新。

例如，当上述服务端为分布式的服务器集群时，服务端可以对上述信息流更新进程添加分布式锁，以确保在对用户的Feeds信息流进行更新时，服务器集群中所有的物理服务器上，只能通过唯一的信息流更新进程对该用户的Feeds信息流进行更新，即当服务器集群中任一物理服务器通过启动上述信息流更新进程对该用户的Feeds信息流进行更新时，在该物理服务器更新完成结束该信息流更新进程以前，该服务器集群中的其它物理服务器将无法重复启动上述信息流更新进程对该用户的Feeds信息流进行更新。通过这种方式，可以避免服务器集群并发的针对该用户的Feeds信息流进行更新，从而造成用户的Feeds信息流的重复更新

在本例中，上述信息流更新进程，可以由用户成功登陆上述客户端的事件触发启动，也可以由用户针对Feeds信息流的访问事件触发启动。

例如，在一种情况下，当用户成功登陆客户端，服务端在接收到该用户成功登陆的通知消息后，可以启动该信息流更新进程对该用户的Feeds信息流进行更新；在另一种情况下，当用户成功登陆客户端后，服务端接收到用户通过客户端发起的针对Feeds信息流的访问请求时，也可以启动该信息流更新进程对用户的Feeds信息流进行更新。

以下结合以上两种情况对服务端启动上述信息流更新进程对用户的Feeds信息流进行更新的过程进行详细描述。

在本例中，用户在登录上述客户端时，仍然可以通过在客户端提供的登录界面中输入用户名和密码来实现。当用户在上述客户端中输入了用户名和密码后，客户端可以将用户输入的用户名和密码提交至对应的登录服务器进行登录验证，当验证通过后，完成正常的登录过程。

当用户登录成功后，客户端或者上述登录服务器可以将该用户成功登录的事件通过通知消息发送给上述服务端。上述服务端在接收到该用户成功登陆的通知消息后，可以立即启动上述信息流更新进程，针对该用户的信息流进行更新。当更新完成后，服务端可以结束该信息流更新进程。

在本例中，用户成功登陆后，在执行正常的操作主动向服务端请求访问最新的Feeds信息流之前，上述服务端可以默认不向上述客户端发送数据更新通知。在这种情况下，用户成功登陆后，在执行正常的操作主动向服务端请求访问最新的Feeds信息流之前，即使该用户的Feeds信息流发生更新(即该用户关注的人员发送了新的Feeds信息)，此时上述服务端也可以不向客户端发送数据更新通知，来通知用户当前的Feeds信息流已发生更新。

当用户在进行正常的操作后，此时用户可以通过针对客户端提供的Feeds信息显示界面执行特定的操作，触发客户端向上述服务端发送Feeds信息流的访问请求，来对当前的Feeds信息流进行刷新，以访问最新的Feeds信息流。

其中，上述特定的操作在本实施例中不进行特别限定；例如，在实现时，上述特定的操作可以包括针对Feeds信息显示界面的点击操作、向下拖动操作等，当用户针对Feeds信息显示界面上的预设位置执行点击操作，或者用户针对Feeds信息显示界面执行向下拖动操作时，可以触发客户端向上述服务端发送Feeds信息流的访问请求。

当服务端接收到上述客户端发送的Feeds信息流的访问请求时，由于Feeds信息流的访问请求也可以触发服务端启动上述信息流更新进程，因此在这种情况下，服务端可以判断该用户的信息流是否已经更新完成，来确定是否再次启动上述信息流更新进程。

一方面，如果该用户的信息流已经更新完成，此时由上述用户成功登陆的通知消息触发启动的上述信息流更新进程已经运行结束，服务端则可以再次启动该信息流更新进程，对该用户的Feeds信息流进行更新。与此同时，服务端可以查询已经更新完成的该用户的Feeds信息流，然后将已经更新完成的该用户的Feeds信息流主动推送至客户端。当客户端接收到服务端推送的已经更新完成的该用户的Feeds信息流后，可以立即在Feeds信息显示界面中加载接收到的Feeds信息流，向用户进行显示。

在这种情况下，由于用户在主动向服务端请求访问最新的Feeds信息流时，Feeds信息流已经更新完成，用户不需要等待服务端对Feeds信息流进行更新完成，因此用户可以得到迅速的响应。

另一方面，如果该用户的信息流未更新完成，此时由上述用户成功登陆的通知消息触发启动的上述信息流更新进程尚未运行结束，由于服务端预先为该信息流更新进程进行了加锁处理，因此在这种情况下，当服务端接收到客户端发送的Feeds信息流的访问请求时，可以不针对该访问请求进行响应，以避免服务端并发启动多个信息流更新进程，对该用户的Feeds信息流进行重复更新。

在本例中，当服务端接收到上述客户端发送的Feeds信息流的访问请求，再次启动上述信息流更新进程后，服务端可以通过修改配置参数，开始向客户端发送数据更新通知。

在这种情况下，当用户的Feeds信息流更新完成，此时由上述用户访问请求触发启动的上述信息流更新进程运行结束，服务端可以判断本次更新完成的Feeds信息流与上一次更新完成的Feeds信息流相比是否发生更新，来确定是否需要向客户端发送数据更新通知。

在本例中，如果本次更新完成的信息流与上一次更新完成的信息流相比是否发生了更新，此时服务端可以向客户端发送该用户的Feeds信息流已发生更新的通知消息。

在实现时，该通知消息可以是服务端基于sync技术向客户端发送一条sync通知消息，在该sync通知消息中可以携带本次Feeds信息更新的时间，以及发生更新的Feeds信息的条数，当客户端收到该sync通知消息后，可以处理该sync通知消息，可以将该sync通知消息中携带的Feeds信息更新的时间与本地已经加载的Feeds信息流的更新时间进行比较，如果该sync通知消息中携带的Feeds信息更新的时间比本地已经加载的Feeds信息流的更新时间更新，表明该用户的Feeds信息流已经发生更新，客户端可以从该sync通知消息中读取发生更新的Feeds信息的条数，然后生成一条对应的提示消息，在Feeds信息显示界面的预设位置(比如界面的最上方)进行显示。例如，该提示消息可以是一条“您有XX条消息未查看”的提示消息。

当客户端在Feeds信息显示界面的预设位置显示上述提示消息后，此时用户可以针对该提示消息执行特定的操作，来触发客户端向服务端发送对应的信息流获取请求，来获取已经发生更新的Feeds信息流，将已经发生更新的Feeds信息流从服务端“拉取”至本地。

例如，该特定的操作可以是触摸操作或者点击操作，当用户触摸或者点击客户端的Feeds信息显示界面中显示的上述通知消息后，可以触发客户端向服务端发送对应的信息流获取请求。

当服务端接收到客户端发送的上述信息流获取请求后，可以计算本次更新完成的Feeds信息流与上一次更新完成的Feeds信息流的差值数据(即本次更新完成的Feeds信息流中新增的Feeds信息)，并将计算出的上述差值数据返回至所述客户端。当客户端在收到服务端返回的上述差值数据后，可以在Feeds信息显示界面中加载接收到的上述差值数据，以向用户进行显示。

当然，如果本次更新完成的信息流与上一次更新完成的信息流相比未发生更新，此时服务端可以不做处理，当再次接收到客户端发送的Feeds信息流的访问请求，再次触发启动上述信息流更新进程后，再重新进行判断是否向客户端发送数据更新通知。

可见，通过这种方式，一方面，当由客户端发送的用户成功登陆的通知消息触发服务端启动上述信息流更新进程时，服务端可以默认不向客户端发送数据更新通知，当接收到客户端发送的Feeds信息流的访问请求，可以将已更新完成的Feeds信息流推送至客户端，从而用户可以得到快速的响应。

另一方面，当由客户端发送的Feeds信息流的访问请求触发服务端启动上述信息流更新进程时，服务端可以开启向客户端发送数据更新通知，当用户的Feeds信息流更新完成后，服务端可以向客户端发送Feeds信息流已经发生更新的通知消息，以通知客户端将本次更新完成的Feeds信息流与上一次更新完成的Feeds信息流的差值数据“拉取”至客户端，从而可以保证客户端不会请求到重复的Feeds信息流。

另外，需要说明的是，当由客户端发送的Feeds信息流的访问请求触发启动的上述信息流更新进程结束后，服务端也可以不向客户端发送数据更新通知，而是采用静默推送技术，将本次更新完成的Feeds信息流与上一次更新完成的Feeds信息流的差值数据直接静默推送至客户端，即当本次更新完成的Feeds信息流与上一次更新完成的Feeds信息流相比发生更新后，客户端可以不再从服务端上将差值数据主动“拉取”至本地，而是由服务端在后台将上述差值数据静默推送至本地，从而当用户通过客户端再次请求访问最新的Feeds信息流时，客户端可以直接在Feeds信息流的显示界面中加载本地存储的上述差值数据向用户进行显示。

在以上实施例中，通过接收客户端发送的用户成功登录的通知消息；所述通知消息用于触发启动信息流更新进程；当接收到客户端发送的用户成功登录的通知消息后，启动所述信息流更新进程针对所述用户的信息流进行更新；当接收到所述客户端发送的信息流访问请求后，将更新完成的信息流推送至所述客户端；可以实现在用户成功登陆后，立即针对该用户的信息流进行更新，当用户主动访问信息流时，可以将已更新完成的该用户的信息流推送给该用户，从而使得用户在主动访问信息流时，能够得到迅速的响应，不会由于数据更新量过大而造成数据更新不及时，用户等待时间较长的问题。

与上述方法实施例相对应，本申请还提供了装置的实施例。

请参见图2，本申请提出一种用户信息流的请求装置20，应用于服务端端；其中，请参见图3，作为承载所述用户信息流的请求装置20的服务端所涉及的硬件架构中，通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等；以软件实现为例，所述用户信息流的请求装置20通常可以理解为加载在内存中的计算机程序，通过CPU运行之后形成的软硬件相结合的逻辑装置，所述装置20包括：

接收模块201，用于接收客户端发送的用户成功登录的通知消息；所述通知消息用于触发启动信息流更新进程；

启动模块202，用于在接收到客户端发送的用户成功登录的通知消息后，启动所述信息流更新进程针对所述用户的信息流进行更新；

推送模块203，用于在接收到所述客户端发送的信息流访问请求后，将更新完成的信息流推送至所述客户端。

在本例中，所述装置20还包括：

结束模块204，用于在所述用户的信息流更新完成后，结束所述信息流更新进程。

在本例中，所述信息流访问请求用于触发启动所述信息流更新进程；

所述推送模块203具体用于：

当接收到所述客户端发送的信息流访问请求时，判断所述用户的信息流是否更新完成；

如果所述用户的信息流已更新完成，启动所述信息流更新进程针对所述用户的信息流进行更新，并将已更新完成的信息流推送至所述客户端。

在本例中，所述推送模块203进一步用于：

当启动所述信息流更新进程后，判断所述用户的信息流是否更新完成；

如果所述用户的信息流已更新完成，将本次更新完成的信息流与上一次更新完成的信息流的差值数据发送至所述客户端。

在本例中，所述推送模块203进一步用于：

如果所述用户的信息流已更新完成，判断本次更新完成的信息流与上一次更新完成的信息流相比是否发生更新；

如果本次更新完成的信息流与上一次更新完成的信息流相比发生了更新，向所述客户端发送所述用户的信息流发生更新的通知消息；

当接收到所述客户端发送的针对所述通知消息的信息流获取请求时，计算本次更新完成的信息流与上一次更新完成的信息流的差值数据，并将计算出的所述差值数据返回至所述客户端。

在本例中，所述推送模块203进一步用于：

如果所述用户的信息流已更新完成，判断本次更新完成的信息流与上一次更新完成的信息流相比是否发生更新；

如果本次更新完成的信息流与上一次更新完成的信息流相比发生了更新，

计算本次更新完成的信息流与上一次更新完成的信息流的差值数据，并将计算出的所述差值数据推送至所述客户端。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种用户信息流的请求方法，其特征在于，该方法包括：

接收客户端发送的用户成功登录的通知消息；所述通知消息用于触发启动信息流更新进程；

当接收到客户端发送的用户成功登录的通知消息后，启动所述信息流更新进程针对所述用户的信息流进行更新；

当接收到所述客户端发送的信息流访问请求后，将更新完成的信息流推送至所述客户端；

其中，所述信息流访问请求用于触发启动所述信息流更新进程；

所述当接收到所述客户端发送的信息流访问请求后，将更新完成的信息流推送至所述客户端包括：

当接收到所述客户端发送的信息流访问请求时，判断所述用户的信息流是否更新完成；

如果所述用户的信息流已更新完成，启动所述信息流更新进程针对所述用户的信息流进行更新，并将已更新完成的信息流推送至所述客户端。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

针对由所述通知消息触发启动的信息流更新进程，在所述用户的信息流更新完成后，结束所述信息流更新进程。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当由所述信息流访问请求触发启动所述信息流更新进程后，判断所述用户的信息流是否更新完成；

如果所述用户的信息流已更新完成，将本次更新完成的信息流与上一次更新完成的信息流的差值数据发送至所述客户端。

4.根据权利要求3所述的方法，其特征在于，所述如果所述用户的信息流已更新完成，将本次更新完成的信息流与上一次更新完成的信息流的差值数据推送至所述客户端包括：

如果所述用户的信息流已更新完成，判断本次更新完成的信息流与上一次更新完成的信息流相比是否发生更新；

如果本次更新完成的信息流与上一次更新完成的信息流相比发生了更新，向所述客户端发送所述用户的信息流发生更新的通知消息；

当接收到所述客户端发送的针对所述通知消息的信息流获取请求时，计算本次更新完成的信息流与上一次更新完成的信息流的差值数据，并将计算出的所述差值数据返回至所述客户端。

5.根据权利要求3所述的方法，其特征在于，所述如果所述用户的信息流已更新完成，将本次更新完成的信息流与上一次更新完成的信息流的差值数据推送至所述客户端包括：

如果所述用户的信息流已更新完成，判断本次更新完成的信息流与上一次更新完成的信息流相比是否发生更新；

如果本次更新完成的信息流与上一次更新完成的信息流相比发生了更新，计算本次更新完成的信息流与上一次更新完成的信息流的差值数据，并将计算出的所述差值数据推送至所述客户端。

6.一种用户信息流的请求装置，其特征在于，该装置包括：

接收模块，用于接收客户端发送的用户成功登录的通知消息；所述通知消息用于触发启动信息流更新进程；

启动模块，用于在接收到客户端发送的用户成功登录的通知消息后，启动所述信息流更新进程针对所述用户的信息流进行更新；

推送模块，用于在接收到所述客户端发送的信息流访问请求后，将更新完成的信息流推送至所述客户端；

其中，所述信息流访问请求用于触发启动所述信息流更新进程；

所述推送模块具体用于：

当接收到所述客户端发送的信息流访问请求时，判断所述用户的信息流是否更新完成；

如果所述用户的信息流已更新完成，启动所述信息流更新进程针对所述用户的信息流进行更新，并将已更新完成的信息流推送至所述客户端。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括：

结束模块，用于针对由所述通知消息触发启动的信息流更新进程，在所述用户的信息流更新完成后，结束所述信息流更新进程。

8.根据权利要求6所述的装置，其特征在于，所述推送模块进一步用于：

当由所述信息流访问请求触发启动所述信息流更新进程后，判断所述用户的信息流是否更新完成；

如果所述用户的信息流已更新完成，将本次更新完成的信息流与上一次更新完成的信息流的差值数据发送至所述客户端。

9.根据权利要求8所述的装置，其特征在于，所述推送模块进一步用于：

如果所述用户的信息流已更新完成，判断本次更新完成的信息流与上一次更新完成的信息流相比是否发生更新；

如果本次更新完成的信息流与上一次更新完成的信息流相比发生了更新，向所述客户端发送所述用户的信息流发生更新的通知消息；

当接收到所述客户端发送的针对所述通知消息的信息流获取请求时，计算本次更新完成的信息流与上一次更新完成的信息流的差值数据，并将计算出的所述差值数据返回至所述客户端。

10.根据权利要求8所述的装置，其特征在于，所述推送模块进一步用于：

如果所述用户的信息流已更新完成，判断本次更新完成的信息流与上一次更新完成的信息流相比是否发生更新；

如果本次更新完成的信息流与上一次更新完成的信息流相比发生了更新，

计算本次更新完成的信息流与上一次更新完成的信息流的差值数据，并将计算出的所述差值数据推送至所述客户端。

Images