项目背景

当初出于留存的考虑，产品同事在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服务的设计并加以实现，基本涵盖了主要的场景。在这过程中也不断地进行了一些小优化，也有不小的收获，其中还有很多可以再优化的地方。