数据人看Feed流架构实践

背景

Feed 流：可以理解为信息流，解决的是信息生产者与信息消费者之间的信息传递问题。
我们常见的 Feed 流场景有：
1 手淘，微淘提供给消费者的首页商品信息，用户关注店铺的新消息等
2 微信朋友圈，及时获取朋友分享的信息
3 微博，粉丝获取关注明星、大 V 的信息
4 头条，用户获取系统推荐的新闻、评论、八卦

关于 Feed 流的架构设计，包括以上场景中的很多业内专家给出了相应的思考、设计和实践。本人是大数据方向出身的技术人，所在的团队参与了阿里手淘、微淘 Feed 流的存储层相关服务，我们的 HBase/Lindorm 数据存储产品在公有云上也支持着 Soul、趣头条、惠头条等一些受欢迎的新媒体、社交类产品。我们在数据存储产品的功能、性能、可用性上的一些理解，希望对真实落地一个 Feed 流架构可以有一些帮助，以及一起探讨 Feed 流的未来以及数据产品如何帮助 Feed 流进一步迭代。

本文希望可以提供两点价值：

1 Feed 流当前的主流架构以及落地方案
2 一个初创公司如何选择 Feed 流的架构演进路径

业务分析

Feed 流参与者的价值

• 信息生产者

希望信息支持格式丰富（文字、图片、视频），发布流畅（生产信息的可用性），订阅者及时收到消息（时效性），订阅者不漏消息（传递的可靠性）

• 信息消费者

希望及时收到关注的消息（时效性），希望不错过朋友、偶像的消息（传递的可靠性），希望获得有价值的消息（解决信息过载）

• 平台

希望吸引更多的生产者和消费者（PV、UV），用户更长的停留时间，广告、商品更高的转化率

Feed 信息传递方式

一种是基于关系的消息传递，关系通过加好友、关注、订阅等方式建立，可能是双向的也可能是单向的。一种是基于推荐算法的，系统根据用户画像、消息画像利用标签分类或者协同过滤等算法向用户推送消息。微信和微博偏向于基于关系，头条、抖音偏向于基于推荐。

Feed 流的技术难点

互联网场景总是需要一定规模才能体现出技术的瓶颈，下面我们先看两组公开数据：

新浪微博为例，作为移动社交时代的重量级社交分享平台，2017 年初日活跃用户 1.6 亿，月活跃用户近 3.3 亿，每天新增数亿条数据，总数据量达千亿级，核心单个业务的后端数据访问 QPS 高达百万级
（来自 Feed 系统架构与 Feed 缓存模型）

截止 2016 年 12 月底，头条日活跃用户 7800W，月活跃用户 1.75 亿，单用户平均使用时长 76 分钟，用户行为峰值 150w+msg/s，每天训练数据 300T+（压缩后），机器规模万级别
（来自 今日头条推荐系统架构设计实践）

上面还是两大巨头的历史指标，假设一条消息 1KB 那么千亿消息约 93TB 的数据量，日增量在几百 GB 规模且 QPS 高达百万，因此需要一个具备高读写吞吐，扩展性良好的分布式存储系统。用户浏览新消息期望百毫秒响应，希望新消息在秒级或者至少 1 分钟左右可见，对系统的实时性要求很高，这里需要多级的缓存架构。系统必须具备高可用，良好的容错性。最后这个系统最好不要太贵。

因此我们需要一个高吞吐、易扩展、低延迟、高可用、低成本的 Feed 流架构

主流架构

图 1 是对 Feed 流的最简单抽象，完成一个从生产者向消费者传递消息的过程。

消息和关系

首先，用户在 APP 侧获得的是一个 Feed ID 列表，这个列表不一定包含了所有的新消息，用户也不一定每一个都打开浏览，如果传递整个消息非常浪费资源，因此产生出来的消息首先生成主体和索引两个部分，其中索引包含了消息 ID 和元数据。其次一个应用总是存在关系，基于关系的传递是必不可少的，也因此一定有一个关系的存储和查询服务。

消息本身应该算是一种半结构化数据（包含文字，图片，短视频，音频，元数据等）。其读写吞吐量要求高，读写比例需要看具体场景。总的存储空间大，需要很好的扩展性来支撑业务增长。消息可能会有多次更新，比如内容修改，浏览数，点赞数，转发数（成熟的系统会独立一个 counter 模块来服务这些元数据）以及标记删除。消息一般不会永久保存，可能要在 1 年或者 3 年后删除。

综上，个人推荐使用 HBase 存储

1. HBase 支持结构化和半结构化数据；
2. 具有非常好的写入性能，特别对于 Feed 流场景可以利用批量写接口单机（32 核 64GB）达到几十万的写入效率；
3. HBase 具备非常平滑的水平扩展能力，自动进行 Sharding 和 Balance；
4. HBase 内置的 BlockCache 加上 SSD 盘可以提供 ms 级的高并发读；
5. HBase 的 TTL 特性可以自动的淘汰过期数据；
6. 利用数据复制搭建一个冷热分离系统，新消息存储在拥有 SSD 磁盘和大规格缓存的热库，旧数据存储在冷库。
7. 运用编码压缩有效的控制存储成本，见 HBase 优化之路 - 合理的使用编码压缩

对于关系服务，其写入操作是建立关系和删除关系，读取操作是获取关系列表，逻辑上仅需要一个 KV 系统。如果数据量较少可以使用 RDS，如果数据量较大推荐使用 HBase。如果对关系的 QPS 压力大可以考虑用 Redis 做缓存。

消息传递

讲到 Feed 流一定会有关于推模式和拉模式的讨论，推模式是把消息复制 N 次发送到 N 个用户的收信箱，用户想看消息时从自己的收信箱直接获取。拉模式相反，生产者的消息写入自己的发信箱，用户想看消息时从关注的 M 个发信箱中收集消息。

推模式实现相对简单，时效性也比较好。拉模式要想获得好的性能需要多级的缓存架构。推模式重写，拉模式重读，Feed 流场景下写的聚合效果要优于读，写可以大批量聚合。N 越大，写入造成的数据冗余就越大。M 越大，读消耗的资源越大。

随着业务的增长，推模式资源浪费会越发严重。原因在于两点：第一存在着大量的僵尸账号，以及大比例的非活跃用户几天或者半个月才登陆一次；第二信息过载，信息太多，重复信息太多，垃圾信息太多，用户感觉有用的信息少，消息的阅读比例低。这种情况下推模式相当一部分在做无用功，白白浪费系统资源。

是推？是拉？还是混合？没有最好的架构，只有适合的场景~

基于关系的传递

图 6 是纯推模式的架构，该架构有 3 个关键的部分

1. 异步化。生产者提交消息首先写入一个队列，成功则表示发布成功，Dispatcher 模块会异步的处理消息。这一点非常关键，首先生产者的消息发布体验非常好，不需要等待消息同步到粉丝的收信箱，发布延迟低成功率高；其次 Dispatcher 可以控制队列的处理速度，可以有效的控制大 V 账号造成的脉冲压力。
2. 多级队列。Dispatcher 可以根据消费者的状态，信息的分类等划分不同的处理方式，分配不同的资源。比如对于大 V 账号的消息，当前活跃用户选择直接发送，保障消息的时效性，非活跃用户放入队列延迟发送。比如转发多的消息可以优先处理等。队列里的消息可以采用批量聚合写的方式提高吞吐。
3. 收信箱。假如有两亿用户，每个用户保留最新 2000 条推送消息。即便存储的是索引也是千亿的规模。收信箱一般的表结构为用户 ID+ 消息序列 + 消息 ID + 消息元数据，消息序列是一个递增的 ID，需要存储一个偏移量表示上次读到的消息序列 ID。用户读取最新消息 select * from inbox where 消息序列 > offset。

推荐使用 HBase 实现收信箱

1. HBase 单机批量写能力在几十万并且可以水平扩展。
2. HBase 的高效前缀扫描非常适合读取最新的消息。
3. HBase 的 TTL 功能可以对数据定义生命周期，高效的淘汰过期数据。
4. HBase 的 Filter 过滤器和二级索引可以有效的实现 Inbox 的搜索能力。

消费者收信箱 hbase 表设计如下，其中序列号要保证递增，一般用时间戳即可，特别高频情况下可以用一个 RDS 来制造序列号

Rowkey	消息元数据列	状态列	其它列
MD5(用户 ID)+ 用户 ID+ 序列号	消息 ID、作者、发布时间、关键字等	已读、未读

图 7 是推拉结合的模式

• 增加发信箱，大 V 的发布进入其独立的发信箱。非大 V 的发布直接发送到用户的收信箱。其好处是解决大量的僵尸账号和非活跃账号的问题。用户只有在请求新消息的时候（比如登陆、下拉消息框）才会去消耗系统资源。
• 发信箱的多级缓存架构。一个大 V 可能有百万粉丝，一条热点消息的传播窗口也会非常短，即短时间内会对发信箱中的同一条消息大量重复读取，对系统挑战很大。终态下我们可能会选择两级缓存，收信箱数据还是要持久化的，否则升级或者宕机时数据就丢失了，所以第一层是一个分布式数据存储，这个存储推荐使用 HBase，原因和 Inbox 类似。第二层使用 redis 缓存加速，但是大 V 过大可能造成热点问题还需要第三层本地缓存。缓存层的优化主要包括两个方向：第一提高缓存命中率，常用的方式是对数据进行编码压缩，第二保障缓存的可用性，这里涉及到对缓存的冗余。

基于推荐的传递

图 8 是基于推荐的模型，可以看出它是在推拉结合的模式上融合了推荐系统。

1. 引入画像系统，保存用户画像、消息画像（简单情况下消息画像可以放在消息元数据中）。画像用于推荐系统算法的输入。
2. 引入了临时收信箱，在信息过载的场景中，非大 V 的消息也是总量很大，其中不免充斥着垃圾、冗余消息，所以直接进入用户收信箱不太合适。
3. 收信箱和发信箱都需要有良好的搜索能力，这是推荐系统高效运行的关键。Outbox 有缓存层，索引可以做到缓存里面；Inbox 一般情况下二级索引可以满足大部分需求，但如果用户希望有全文索引或者任意维度的检索能力，还需要引入搜索系统如 Solr/ES

用户画像使用 HBase 存储

1. 画像一般是稀疏表，画像总维度可能在 200+ 甚至更多，但单个用户的维度可能在几十，并且维度可能随业务不断变化。那么 HBase 的 Schema free 和稀疏表的能力非常适合这个场景，易用且节省大量存储空间。
2. 对画像的访问一般是单行读，hbase 本身单行 Get 的性能就非常好。阿里云 HBase 在这个方向上做了非常多的优化，包括 CCSMAP、SharedBucketCache、MemstoreBloomFilter、Index Encoding 等，可以达到平均 RT=1-2ms，单库 99.9% <100ms。阿里内部利用双集群 Dual Service 可以做到 99.9% < 30ms，这一能力我们也在努力推到公有云。hbase 的读吞吐随机器数量水平扩展。

临时收信箱使用云 HBase

1. HBase 的读写高吞吐、低延迟能力，这里不再重复。
2. HBase 提供 Filter 和全局二级索引，满足不同量级的搜索需求。
3. 阿里云 HBase 融合 HBase 与 Solr 能力，提供低成本的全文索引、多维索引能力。

初创公司的迭代路径

在业务发展的初期，用户量和资源都没有那么多，团队的人力投入也是有限的，不可能一上来就搞一个特别复杂的架构，“够用”就行了，重要的是

1. 可以快速的交付
2. 系统要稳定
3. 未来可以从容的迭代，避免推倒重来

本人水平有限，根据自身的经验向大家推荐一种迭代路径以供参考，如有不同意见欢迎交流

起步架构如图 9，使用云 Kafka+ 云 HBase。如果对 Inbox 有检索需求，建议使用 HBase 的 scan+filter 即可。

1. 消息分为主体和索引
2. 采用纯推的模式
3. 采用异步化

数据量逐渐增大后，对推模式进一步迭代，主要需求是

1. 控制大 V 造成的写入脉冲高峰
2. 控制存储成本
3. 提升读写性能
4. 提升一定的 Inbox 搜索能力

进一步的迭代架构如图 10

1. 消息分为主体和索引
2. 采用纯推的模式
3. 采用异步化
4. 采用多级队列解决大 V 问题
5. 采用冷热分离降低存储成本
6. 此时 Inbox 中的消息也很多，对搜索的需求增强，仅仅 Scan+Filter 不够，可能需要二级索引

业务迅猛发展，消息和用户增长迅速，僵尸账号、非活跃账号较多，信息过载严重

1. 消息分为主体和索引
2. 采用推拉结合模式
3. 采用异步化
4. 引入推荐系统
5. 采用冷热分离降低存储成本
6. Outbox 采用多级缓存提高读取性能
7. Inbox 增加二级索引提升搜索能力

使用云 Kafka+ 云 HBase+ 云 Redis

总结

Feed 信息流是互联网场景中非常普遍的场景，遍布于电商、社交、新媒体等 APP，因此研究 Feed 流是非常有价值的一件事情。本文总结了 Feed 流的业务场景和主流架构，分析了不同场景、体量下技术的难点与瓶颈。对 Dispatcher、Inbox、Outout 几个组件进行了详细的演进介绍，提供了基于云环境的落地方案。本人水平有限，希望可以抛砖引玉，欢迎大家一起探讨。Feed 流的架构演进还在持续，不同业务场景下还有哪些缺陷和痛点？数据产品如何从功能和性能上演进来支撑 Feed 流的持续发展？在这些问题的驱动下，云 HBase 未来将会大力投入到 Feed 流场景的持续优化和赋能！

参考文献

[1] Feed 架构 - 我们做错了什么 https://timyang.net/architecture/feed-data-arch-cons/

[2] Feed 系统架构与 Feed 缓存模型 https://mp.weixin.qq.com/s/RmDLqQmXQAmtQrajoanNuA?utm_medium=hao.caibaojian.com&utm_source=hao.caibaojian.com

[3] 今日头条推荐系统架构设计实践 https://yq.aliyun.com/download/602

[4] 新浪微博架构和 FEED 架构分析 http://blog.sina.com.cn/s/blog_53b95aec0100ujim.html

[5] feed 流个性化推荐架构和算法分享 https://blog.csdn.net/baymax_007/article/details/89853030

---

本文作者：daniel.meng

阅读原文

本文为云栖社区原创内容，未经允许不得转载。