参考资料
如何打造千万级Feed流系统
TableStore Timeline：轻松构建千万级IM和Feed流系统
Design the Twitter timeline and search
Feed系统架构资料收集
1. 表结构
1.1. Feed 内容库
内容库用于存储用户发送的消息。
| 列名 | 是否主键 | 说明 |
|---|---|---|
| user_id | yes | 消息发送者的 id |
| message_id | yes | 消息 id，可以用时间戳 |
| content | no | 消息内容 |
| other | no | 其他信息 |
1.2. 同步表
同步方式，常见的方式有三种：
- 推模式（也叫写扩散）：和名字一样，就是一种推的方式，发送者发送了一个消息后，立即将这个消息推送给接收者，但是接收者此时不一定在线，那么就需要有一个地方存储这个数据，这个存储的地方我们称为：同步库。推模式也叫写扩散的原因是，一个消息需要发送个多个粉丝，那么这条消息就会复制多份，写放大，所以也叫写扩散。这种模式下，对同步库的要求就是写入能力极强和稳定。读取的时候因为消息已经发到接收者的收件箱了，只需要读一次自己的收件箱即可，读请求的量极小，所以对读的QPS需求不大。归纳下，推模式中对同步库的要求只有一个：写入能力强。
- 拉模式（也叫读扩散）：这种是一种拉的方式，发送者发送了一条消息后，这条消息不会立即推送给粉丝，而是写入自己的发件箱，当粉丝上线后再去自己关注者的发件箱里面去读取，一条消息的写入只有一次，但是读取最多会和粉丝数一样，读会放大，所以也叫读扩散。拉模式的读写比例刚好和写扩散相反，那么对系统的要求是：读取能力强。另外这里还有一个误区，很多人在最开始设计feed流系统时，首先想到的是拉模式，因为这种和用户的使用体感是一样的，但是在系统设计上这种方式有不少痛点，最大的是每个粉丝需要记录自己上次读到了关注者的哪条消息，如果有1000个关注者，那么这个人需要记录1000个位置信息，这个量和关注量成正比的，远比用户数要大的多，这里要特别注意，虽然在产品前期数据量少的时候这种方式可以应付，但是量大了后就会事倍功半，得不偿失，切记切记。
- 推拉结合模式：推模式在单向关系中，因为存在大V，那么一条消息可能会扩散几百万次，但是这些用户中可能有一半多是僵尸，永远不会上线，那么就存在资源浪费。而拉模式下，在系统架构上会很复杂，同时需要记录的位置信息是天量，不好解决，尤其是用户量多了后会成为第一个故障点。基于此，所以有了推拉结合模式，大部分用户的消息都是写扩散，只有大V是读扩散，这样既控制了资源浪费，又减少了系统设计复杂度。但是整体设计复杂度还是要比推模式复杂。
用图表对比：
| 对比项 | 推模式 | 拉模式 | 推拉结合模式 |
|---|---|---|---|
| 写放大 | 高 | 无 | 中 |
| 读放大 | 无 | 高 | 中 |
| 用户读取延时 | 毫秒 | 秒 | 秒 |
| 读写比例 | 1:99 | 99:1 | ~50:50 |
| 系统要求 | 写能力强 | 读能力强 | 读写都适中 |
| 常见系统 | Tablestore、Bigtable等LSM架构的分布式NoSQL | Redis、memcache等缓存系统或搜索系统(推荐排序场景) | 两者结合 |
| 架构复杂度 | 简单 | 复杂 | 更复杂 |
介绍完同步模式中所有场景和模式后，我们归纳下：
- 如果产品中是双向关系，那么就采用推模式。
- 如果产品中是单向关系，且用户数少于1000万，那么也采用推模式，足够了。
- 如果产品是单向关系，单用户数大于1000万，那么采用推拉结合模式，这时候可以从推模式演进过来，不需要额外重新推翻重做。
- 永远不要只用拉模式。
- 如果是一个初创企业，先用推模式，快速把系统设计出来，然后让产品去验证、迭代，等客户数大幅上涨到1000万后，再考虑升级为推拉集合模式。
- 如果是按推荐排序，那么是另外的考虑了，架构会完全不一样，这个后面专门文章介绍。
同步表的结构如下：
| 列名 | 是否主键 | 说明 |
|---|---|---|
| user_id | yes | 消息接收者用户ID |
| sequence_id | yes | 消息顺序ID，可以使用timestamp + send_user_id，也可以直接使用Tablestore的自增列。 |
| sender_id | no | 消息发送者的用户ID |
| message_id | no | store_table中的message_id列的值，也就是消息ID。通过sender_id和message_id可以到store_table中查询到消息内容 |
| other | no | 其他信息 |
