什么是 Feed 流
Feed 流是社交和资讯类应用中常见的一种形态， 比如微博知乎的关注页、微信的订阅号和朋友圈等。Feed 流源于 RSS 订阅， 用户将自己感兴趣的网站的 RSS 地址登记到 RSS 阅读器中， 在阅读器里聚合成的列表就是 Feed 流。
Feed 流的本质是 M 个用户订阅了 \(N_i\) 个信息源形成的多对多关系， Feed 流系统需要聚合用户订阅的 \(N_i\) 个 信息源产生的信息单元(Feed)， 在按照一定顺序排列后推送给用户。接下来我们以关注页为例来介绍 Feed 流的实现。
Feed 流有两种基本实现模式：
- 推模式：当发布新的 Feed 后(比如某大V发了条微博)，将这条内容插入到所有粉丝的 Feed 流中。
- 拉模式：当用户上线后遍历他的关注关系，实时拉取他关注的人发布的内容并聚合成 Feed 流。
两种实现方式各有优缺：
- 推模式的优点在于用户关注人数较多时， 推模型性能较好。但粉丝数较多的大V发布内容时需要插入的 Feed 流过多，开销很大。
- 拉模式的优点在于粉丝数较多的大V发布内容时系统不需要短时间内执行大量操作。但用户关注人数较多时，构建 Feed 流耗时很长。
推模式的 Feed 流系统在用户发布新的 Feed 后需要执行较多插入操作，通常需要使用 MQ 来异步地进行。
在实际应用中我们通常采取推拉结合的实现方式。
Feed 流的存储
Feed 流系统中需要存储的数据有 3 部分：
- 作者发布的 Feed 列表，比如个人发布的所有微博、某个答主回答的所有问题或者某人发布的朋友圈。这些数据需要可靠的持久化存储，通常采用 MySQL 等关系型数据库即可。因为很可能需要按照发布时间排序， 若要使用 NoSQL 最好使用支持有序存储的数据库。
- 用户和作者之间的关注关系。同样需要可靠的持久化存储，采用 MySQL 等关系型数据库或者 KV 结构的 NoSQL 数据库均可。
- 用户的 Feed 流。Feed 流可以根据 Feed 数据库和关注关系构建，因此可以不做持久化存储。
最轻量的解决方案是使用 Redis 存储 Feed 流。在数据量较大 Redis 内存不够用时，也可以采用一些持久化的存储方案。
有序集合 SortedSet 是非常适合存储 Feed 流的数据结构，一般以 Feed 的 ID 作为 SortedSet 的 member，时间戳或者热度值、推荐值作为 score 进行排序。SortedSet 保证了 Feed 不会重复，且插入过程线程安全，无论是推拉模式实现起来都非常方便。
为了避免 Redis 中缓存的 Feed 流占用过多内存，通常需要给 Feed 流设置 TTL.
Feed 的具体内容存储可以在 MySQL 中，同时在 Redis 中做一层缓存。关注关系可以存储在 MySQL 中，因为有些大V的粉丝数较多所以不推荐做缓存。
持久化存储
一个用户的 Feed 流大小是他所有关注者发布的 Feed 数总和，数据量巨大且增长迅速。在用户量较大的系统中将所有 Feed 流存储在 Redis 中需要消耗巨量的内存。在必要的时候可以利用持久化存储作多级缓存，比如：将当日活跃用户的Feed 流数据存储在 Redis 中， 当月活跃用户的 Feed 流持久化到数据库中，长期未活跃的用户则在他重新登录后使用 MySQL 中存储的关注关系重新构建 Feed 流。
持久化存储 Feed 流的数据库需要有较大的数据容量和吞吐量并且支持排序(Order By 查询)。鉴于这两个原因不建议使用数据容量较小的 MySQL 或者不支持排序的 KV 数据库。
作者推荐使用 Cassandra 来持久化 Feed 流。使用用户的 UID 作为 Partition Key, Feed 时间戳在前 Feed ID 在后， 共同作为 Clustering Key 用于排序和去重。Cassandra 支持 TTL 可以用来自动清除冷数据。Feed 流数据属于只追加不修改，与 Cassandra 使用的 LSM 结构非常契合，可以有效减少 Cassandra 进行 Compaction 的负担。
Feed 流系统优化
在线推 离线拉
一个拥有 10 万粉丝的大V在发布微博时，他的粉丝中可能只有 1 千人在线。因此我们常用的优化策略是：对于在线的粉丝采用推模式，将新的 Feed 直接插入到粉丝的信息流中；对于离线的粉丝采用拉模式，在粉丝登录时遍历他的关注关系重新构建 Feed 流。
在线推的部分需要计算粉丝和在线用户的交集，然后进行插入操作。因为在线用户数和粉丝数都比较大，所以计算交集的过程需要分批进行。比如说每次查询 100 个粉丝，然后去查询这 100 个用户中有多少在线（取交集），直到遍历完粉丝列表。这个过程类似于将两个表做 join, 同样适用小表驱动大表的原则以减少取交集操作的次数, 大多数情况下使用数量较少的粉丝表作为驱动表。（不要问我什么情况下用在线用户表做驱动表