feed服务项目设计思考

项目背景

当初出于留存的考虑，产品同事在app内设计了相似微博的feed功能。从功能上看，咱们的feed服务更像是微博和微信朋友圈的结合体。既有微博热门的场景，也有微信朋友圈的影子。

功能列表

• feed资料页

相似微信朋友圈的相册功能，能够看到用户曾经发布的feed动态。

• feed新鲜事页

相似微信朋友圈功能，能够看到本身及好友（关注的人）发布的feed动态。

• feed广场页

相似微博的推荐或热门功能，为用户作个性化的推荐。

基本思路

项目思考

1. 数据存储

在feed动态主要存储两种信息，一是动态内容，二是不一样维度的动态索引。

feed数据结构

feed信息除了基本的内容外还须要存储额外的信息，而且额外信息可能还会面临扩展的状况。因此feed数据结构基本定义以下。在数据库里面存储的是FeedInfo信息序列化后的数据，这样后续能够支持扩展，而不须要修改数据库字段。

message FeedItem {
    string feed_id = 1; //动态id
    int64 create_time = 2; //发布时间
    User from_user = 3; //发布者
    int32 feed_type = 4; //对应FeedType
    bytes attachment = 5; //附件信息
   ...
}

message FeedInfo {
    FeedItem feed_item = 1;
    bool deleted = 2; //是否删除
    AuditType audit_type = 3; // 审核类型
    VisibleStatus visible_status = 4; // 动态可见性
    ...
}
复制代码

内容存储

feedId => feed内容

动态内容能够抽象成KV形式的键值存储，几乎全部的场景都是根据动态ID来获取动态内容，而后进行后续处理。所以选用了HBase做为优先的内容存储服务，再以Mysql和Redis为辅，做为降级方案。毕竟是首次将HBase应用到在线服务。以最终的性能数据来看，HBase的性能仍是不错的。

索引数据存储

其它维度的索引关系仍是使用Mysql存储，毕竟可能会涉及到复杂的查询。

• 资料页feed

相似微信朋友圈相册功能，须要存储用户所发布的全部动态，按用户维度进行分表。基本信息以下：

属性	备注
user_id	发布者ID
feed_id	动态ID
feed_create_time	动态建立时间
visible_status	动态可见性

• 新鲜事feed

相似微信朋友圈功能，须要存储全部关注人及本身的动态，按用户维度分表。基本信息以下：

属性	备注
user_id	用户ID
feed_id	动态ID
from_user_id	发布者ID
feed_create_time	动态建立时间

• 广场推荐feed

相似微博的热门推荐功能，须要根据时间线存储全部用户发布的feed。所以广场feed根据日期进行分表。1个月有31天，这里一共分红31个表，不一样日期的feed存储到不一样表。基本信息和新鲜事feed基本一致，只是存储的数据及数据维度有所不一样。

属性	备注
user_id	用户ID
feed_id	动态ID
from_user_id	发布者ID
feed_create_time	动态建立时间

这里按天分表有如下考虑：按当前预估发布量，31个分表应该足够，不须要再细分。按天分表基本能保证数据的连续性，比较符合查询习惯。

2. 数据扩散

• 扩散方式

数据扩散有写扩散和读扩散两种方式。 读扩散是在读取的时候再进行扩散，这样一次读请求可能会涉及好几个地方的读取，读取耗时不可控。写扩散通常是存储多份数据，虽然冗余存储了不少数据信息，可是读取的效率能够提升很多，在当下磁盘等硬件资源并不紧缺的状况下写扩散应该是更为合适的处理方式。

• 数据流向

在feed服务里面用户发布的feed会先在本人的资料页及新鲜事页可见，优先保证发布者的体验。而后发布的feed才会扩散到其粉丝好友和广场页进行曝光。后面的流程用户基本对延迟不感知的，所以这里经过消息队列进行异步化的写扩散处理。基本处理流程以下：

3.审核机制

用户发布动态须要通过审核，为了不违规的内容推送给用户。审核机制通常有先审后发和先发后审两种。

• 先审后发

用户发布的feed必须先经过审核后才能够扩散给其余用户。所以能够在feed写入发布者资料页和新鲜事页以后，写入消息队列进行扩散以前进行拦截。只有当feed审核经过后才写入消息队列进行写扩散，这样发布者和其余用户也不会有明显的感知。不过对于发布者来讲，可能会感受到互动的延迟。

• 先发后审

用户发布的feed能够先进行扩散曝光，当feed审核不经过时才进行删除操做。这种状况下用户的体验会更好，不过会增长平台的一些风险。

4.点赞设计

• 用户维度点赞列表

用户点赞数据会存储在数据库和redis缓存。因为用户点赞行为不肯定，部分用户可能会频繁点赞。所以使用redis的zset结构缓存用户部分点赞数据，field为feedId，score也是feedId，根据feedId倒序排列，只保留最新的N条feed点赞数据。

用户点赞列表为何不以点赞时间排序？由于用户点赞时间是不肯定的，用户颇有可能点赞了好久以前的feed。这样就意味着当缓存里没找到feed点赞数据时，没法肯定是缓存缺失仍是用户没点赞，最后都得在数据库再次查询作确认。

用户点赞列表按feedId排序的状况下，若feedId不在列表中，且feedId大于点赞缓存中最小的feedId，就能肯定用户的确没有点赞，不须要再从数据库进行查询。

• feed维度点赞计数

在咱们的场景里，feed维度点赞计数是重要的数据。一开始设计的时候，使用redis的count来同步计数，但是会存在漏计数或者重复计数的问题，没办法保证数据的准确性。后来考虑到点赞的频率不会很高，调整成从数据库获取count计数，将计数再同步到redis缓存。

• 拆分点赞流程

在设计里面优先保证用户端体验，所以在存储用户维度的数据后会快速返回，将本次点赞请求写入消息队列。而后再处理feed维度点赞数据的维护，包括调整feed点赞计数和给feed发布者发送点赞消息等。根据重要程度拆分流程，优先保证用户的体验。

5.trade off策略

• 广场推荐页保底策略

广场推荐feed通常是推荐服务根据用户特征返回其更感兴趣的feed列表。当推荐服务不可用时，须要有个保底策略以确保用户能正常拉取到feed信息，避免影响用户体验。这里就实现了个保底策略，利用redis的zset结构维护全部用户发布的最新的N条feed。当推荐服务不可用时直接返回该列表的信息。

• 被关注者最新的N条feed

当用户新关注其余用户时，被关注者的feed应当出如今用户的新鲜事页面。考虑到信息的实时性，咱们只选择被关注者最新的N条feed插入到用户的新鲜事，而不是被关注者全部的feed列表。这样处理基本也不影响用户体验，处理上相对简单一点。

结语

这是第一次思考feed服务的设计并加以实现，基本涵盖了主要的场景。在这过程当中也不断地进行了一些小优化，也有不小的收获，其中还有不少能够再优化的地方。