微博feed系统的推模式和拉模式的架构是怎样的

微博feed系统的推模式架构：1、发布服务；2、推送服务；3、数据发布中心；4、移动终端。拉模式架构：1、消息查询服务；2、推送服务；3、移动终端。发布服务是指将消息推送到数据发布中心。

一、微博feed系统的推模式架构

1、发布服务

负责生成用户的消息，将消息推送到数据发布中心。

2、推送服务

在接收到新消息后，根据消息的类型和内容信息进行用户匹配，向用户推送个性化的消息流。

3、数据发布中心

接收发布服务推送的消息，将消息进行转换、去重和分级处理，同时创建索引，为后续的消息处理提供支持。

4、移动终端

接收用户推送的消息流。

二、微博feed系统的拉模式架构

1、消息查询服务

提供消息查询接口，支持按时间线查询消息。

2、推送服务

维护用户的消息流，当有新的消息到达或旧的消息需要更新时，会将更新后的消息推送到用户的消息流中。

3、移动终端

根据用户请求，向消息查询服务发送查询请求，通过推送服务获取需要展示的消息。

三、Feed系统介绍

1、简介

当互联网开始进入移动互联网时代，具代表性的产品就是微博、微信，以及后来的今日头条、快手等。这些移动互联网时代的新产品在过去几年间借着智能手机的风高速成长。这些产品都是Feed流类型产品，由于Feed流一般是按照时间“从上往下流动”，非常适合在移动设备端浏览，最终这一类应用就脱颖而出，迅速抢占了上一代产品的市场空间。

Feed流是Feed+流，Feed的本意是饲料，Feed流的本意就是有人一直在往一个地方投递新鲜的饲料，如果需要饲料，只需要盯着投递点就可以了，这样就能源源不断获取到新鲜的饲料。在信息学里面，Feed其实是一个信息单元，比如一条朋友圈状态、一条微博、一条咨询或一条短视频等，所以Feed流就是不停更新的信息单元，只要关注某些发布者就能获取到源源不断的新鲜信息，我们的用户也就可以在移动设备上逐条去浏览这些信息单元。

当前最流行的Feed流产品有微博、微信朋友圈、头条的资讯推荐、快手抖音的视频推荐等，还有一些变种，比如私信、通知等，这些系统都是Feed流系统，接下来我们会介绍如何设计一个Feed流系统架构。

2、Feed流系统特点

Feed流本质上是一个数据流，是将 “N个发布者的信息单元” 通过 “关注关系” 传送给 “M个接收者”。

3、Feed流系统的数据

Feed流系统是一个数据流系统，所以我们核心要看数据。从数据层面看，数据分为三类，分别是：

• 发布者的数据：发布者产生数据，然后数据需要按照发布者组织，需要根据发布者查到所有数据，比如微博的个人页面、朋友圈的个人相册等。
• 关注关系：系统中个体间的关系，微博中是关注，是单向流，朋友圈是好友，是双向流。不管是单向还是双向，当发布者发布一条信息时，该条信息的流动永远是单向的。
• 接收者的数据：从不同发布者那里获取到的数据，然后通过某种顺序（一般为时间）组织在一起，比如微博的首页、朋友圈首页等。这些数据具有时间热度属性，越新的数据越有价值，越新的数据就要排在最前面。

针对这三类数据，我们可以有如下定义：

• 存储库：存储发布者的数据，永久保存。
• 关注表：用户关系表，永久保存。
• 同步库：存储接收者的时间热度数据，只需要保留最近一段时间的数据即可。

4、排序

目前的Feed流系统中的排序方式有两种，一种是时间，一种是分数。我们常用的微博、朋友圈、私信这些都是时间线类型的，因为这些产品定义中，需要我们主动关注某些人后才会看到这些人发表的内容，这个时候，最重要的是实时性，而不是发布质量，就算关注人发布了一条垃圾信息，我们也会被动看到。这种类型的产品适用于按照时间线排序。这一篇我们介绍的架构都是基于时间类型的。

另外一种是不需要关注任何人，我们能看到的都是系统希望我们看到的，系统在后台会分析我们的每个人的爱好，然后给每个人推送差异化的、各自喜欢的内容，这一种的架构和基于时间的完全不一样，我们在后续的推荐类型中专门介绍。

延伸阅读1：如何删除Feed内容

在Feed流应用中有一个问题，就是如果用户删除了之前发表的内容，系统该如何处理？因为系统里面有写扩散，那么删除的时候是不是也要写扩散一遍？这样的话，删除就不及时了，很难应对法律法规要求的快速删除。针对这个问题，我们在之前设计的时候，同步表中只有消息ID，没有消息内容，在用户读取的时候需要到存储库中去读消息内容，那么我们可以直接删除存储库中的这一条消息，这样用户读取的时候使用消息ID是读不到数据的，也就相当于删除的内容，而且删除速度会很快。除了直接删除外，另外一种办法是逻辑删除，对于删除的feed内容，只做标记，当查询到带有标记的数据时就认为删除了。