数据人看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过大可能形成热点问题还须要第三层本地缓存。缓存层的优化主要包括两个方向：第一提升缓存命中率，经常使用的方式是对数据进行编码压缩，第二保障缓存的可用性，这里涉及到对缓存的冗余。

![图7 基于关系传递的推拉混合模式
](https://upload-images.jianshu... "_7")

基于推荐的传递

图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

原文连接

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