LZ可能要去新的公司从事Feed流推荐相关的工作，在此之前，打算先对这一块内容做一个简单的介绍，也有利于我自身后续在这一方面的深耕。
在互联网领域，尤其现在的移动互联网时代，Feed流产品是非常常见的，比如我们每天都会用到的朋友圈，微博，就是一种非常典型的Feed流产品，还有图片分享网站Pinterest，花瓣网等又是另一种形式的Feed流产品。除此之外，很多App的都会有一个模块，要么叫动态，要么叫消息广场，这些也是Feed流产品，可以说，Feed流产品是遍布天下所有的App中。
概念
Feed：Feed流中每一条状态或者是消息都是Feed，比如朋友圈中的一个状态就是一个Feed，微博中的一条微博就是Feed。
Feed流：持续更新并呈现给用户内容的信息流。每个人的朋友圈，微博关注页面也都是一个Feed流。
Timeline：Timeline其实是一种Feed流的类型，微博，朋友圈其实都是Timeline类型的Feed流，但是由于Timeline类型出现最早，使用最广泛，最为人熟知，因此也用Timeline来表示Feed流。
关注页Feed流：展示其他人的Feed消息的页面，比如朋友圈、微博首页等。
个人页Feed流：展示自己发送过来的Feed消息的页面，比如微信中的相册、微博个人页等。
特征
Feed流系统有一些典型的特点，比如：
- 多账号内容流：Feed流系统中肯定会存在成千上万的账号，账号之间可以关注，取关，加好友和拉黑等操作。只要满足这一条，那么就可以当做Feed流系统来设计。
- 非稳定的账号关系：由于存在关注，取关等操作，所以系统中的用户之间的关系就会一直在变化，是一种非稳定的状态。
- 读写比例100:1：读写严重不平衡，读多写少，一般读写比例在10：1，甚至100：1以上。
- 消息必达性要求高：比如发送了一条朋友圈后，结果部分朋友看到了，部分朋友没看到，如果偏偏女朋友没看到，那么可能会产生很严重的感情矛盾，后果很严重。
分类
Feed流的分类有好多种，常见的分类有两种：
Timeline：按照时间的顺序排序，先发布的人先看到，后发布的排列在最顶端，类似于微信朋友圈、微博等。如果选择Timeline，就可以认为Feed流中的Feed不多，但每个Feed都很重要，都需要用户看到，目前微信的朋友圈依然采用这种方式实现。
Rank：按照某个非时间的因子排序，一般是按照用户的喜好程度排序，用户最喜欢的排在最前面，次喜欢的排在后面。这种一般假定用户可能看到的Feed非常多，而用户花费在这里的时间有限，那么就为用户选择出用户最想看的Top N结果，场景的应用场景有图片分享、新闻推荐类、商品推荐类等。
上面两种是最常见的分类方式，也有其他的一些分类方式，比如Aggregate、Notice方式，其中：
Aggregate方式表示聚合类型，比如几个朋友看了一部电影，这就可以聚合为一条Feed：A，B，C看了电影《你的名字》，这种聚合功能比较适合在客户端做。一般的Aggregate类型是Timeline类型+客户端聚合。
Notice：通知类型，功能类型，一般用于各种APP中的各种通知、私信等场景，也是Timeline和Aggregate类型等。
实现
设计一个Feed流系统，最关键的两个核心在于存储和推送。
存储
我们先来看存储，Feed流系统中需要存储的内容分为两部分，一个是账号关系（比如关注列表），一种是Feed消息内容。不管是存储哪一种，都有几个问题需要考虑：
- 如何能支持100TB，甚至PB级数据量？
- 数据量大了后成本就很关键，成本如何能更便宜？
- 如何保证账号关系和Feed不丢失？
推送
推送系统需要考虑的功能有两个：一个是发布Feed，另一个是读取Feed。对于推送系统，仍然需要考虑两个问题：
如何能够保证提供千万级的TPS和QPS？
如何保证读写延迟在10ms，甚至2ms以下？
如何保证Feed的必达性？
存储系统选择
存储系统主要有两类：一类是账号关系(例如关注列表)、一类是Feed消息。
存储账号关系
账号关系的存储，有如下特征：
一系列的变长链表，长度可达亿级别
数据量非常大，关系极其简单
性能敏感，直接影响关注，取关的响应速度
最适合存储账号关系的系统应该是NoSQL数据库，数据量极大，关系简单不需要复杂的join，性能要求高。
对内设计实现简单，对外用户体验好。
有序性：有序性不要求具有排序功能，而只需要按照主键排序即可，只要按照主键排序，关注列表和粉丝列表的顺序就是固定的，可预见的。
存储Feed消息
Feed消息有一个最大的特点：
数据量大，而且在Feed流系统里很多时候都会选择扩散(推模式)，这时候数据量会再膨胀几个数量级，所以这里的数据量往往达到100TB，甚至PB级别。
此外，还有一些如下特征：
数据格式简单
数据不能丢失，可靠性要求高
自增主键功能，保证个人发的Feed的消息ID在个人发件箱中都是严格递增的，则读取时只需要一个范围即可。由于个人发布的Feed并发度很低，这里用时间戳也能基本满足需求，但是当应用层队列堵塞，网络延迟变大或时间回退时，用时间戳还是无法保证严格递增。
成本越低越好