数据人看Feed流-架构实践( 六 )_背景Feed流：可以理解为信息流

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

主流架构

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

图1 Feed流简单抽象

消息和关系

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

图2 Feed流消息、关系的存储

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