# Twitter

twitter 是社交网络服务之一，用户可以在上面发布、阅读 140 字符长度的消息，即 tweets。系统的主要功能罗列如下：

* 核心功能
  * 用户可以发布新的 tweets
  * 用户可以互相关注
  * 用户可以将它喜欢的 tweets 标记为喜爱（favorites）
  * 用户可以查看其关注的其它用户最近发布的 tweets，称为 timeline
  * 每个 tweets 可以包含图片和视频
  * 用户可以转发 tweet，即 re-tweet
  * 用户可以按关键词检索 tweets
* 扩展功能
  * 回复 tweet
  * 热搜话题
  * tweet push：新消息提示
* 系统要求
  * 服务高可用
  * timeline 服务的延迟 <= 200ms
  * 一致性要求不高，tweet 发布后一段时间内其他用户无法访问可以容忍

## System APIs

tweeter 的 api 总体上可分为 read 和 write，其中 read 可以从以下两个维度来看：

|          | Pull           | Push                                       |
| -------- | -------------- | ------------------------------------------ |
| Targeted | home\_timeline | User/Site Streams, Mobile Push (SMS, etc.) |
| Queried  | search         | track/follow streams                       |

而 write api 只有一个，即

```bash
post_tweet(api_dev_key, tweet_data, tweet_metadata)
```

其中：

* api\_dev\_key 用于控制用户的资源配额
* tweet\_data 用于记录 tweet 数据本身，如文字以及图片、音频、视频的地址
* tweet\_metadata 用于记录 tweet 的元数据，包括发送地点、用户信息等等

## High Level System Design

twitter 服务请求是典型的读多写少型，但即使是少，量级也很大，因此我们需要多个 application servers 来服务这些请求，并通过 load balancer 来分发请求，后端需要高性能的数据库来存储大量 tweets 数据，同时承载更大量集的读压力，此外我们还需要一些文件存储服务来放置用户上传的图片与视频：

![](/files/-L_pvpqZBeFhDSnV14BR)

在设计的时候，需要考虑到峰值请求量，这里使用 auto-scaling，能够在必要时扩容以抗住压力。

考虑到数据库承载的读写量巨大，需要对其进行分片，因此中间需要增加一组 aggregator servers 负责从多个数据库分片中查询并聚合结果，因此可进一步细化为：

![](/files/-L_qIWHQRCj9js9KjXWD)

## Low Level System Design

### Data Model & Database

在 database 中，我们需要存储用户、tweets、关注以及喜欢的关系，因此至少需要 Tweet、User、Follow、Favorite 数据表：

#### Tweet

```
TweetID:        int
UserID:         int
Content:        varchar(140)
TweetLatitude:  int
TweetLongitude: int
UserLatitude:   int
UserLongitude:  int
CreationDate:   datetime
NumFavorites:   int
PK on TweetID
```

#### User

```
UserID:       int
Name:         varchar(30)
Email:        varchar(32)
DateOfBirth:  datetime
CreationDate: datetime
LastLogin:    datetime
PK on UserID
```

#### Follow

```
UserID1: int
UserID2: int
PK on (UserID1, UserID2)
```

#### Favorite

```
TweetID:      int
UserID:       int
CreationDate: datetime
PK on (TweetID, UserID)
```

那么用什么方式来存这些数据就是下一步需要做的决定，是 SQL 还是 NoSQL？RDBMS 在扩展性上，横向扩展技术不算成熟，通常会带来较大的维护成本，由于 twitter 对扩展性、可用性的要求较高，对一致性的要求反而不高（tweet 发布一段时间后，相关的用户看不到是可以接受的），因此这里选择 NoSQL 数据库更加合理。

#### Data Sharding

由于每天都有大量的 tweets 读写，我们需要将数据分布到不同的机器上，这样能够达到更高效地 read/write，如何对数据划分是下一步要确定的问题。在此之前，需要明确 sharding 的目的：提高 timeline 查询的效率，尽量分散读写请求，注意处理热点场景（部分 user 或者 tweet 可能出现大量读写，产生热点）

回顾 Tweet 数据模型，可能的方案有：

* 根据 TweetID 分库
* 根据 UserID 分库
* 根据 CreationDate 分库

*TweetID*

timeline：

1. application server 将请求发到 aggregator server
2. aggregator server 找到该用户关注的所有其它用户
3. aggregator server 发送相应的查询请求到每个数据库分片上，查询对应用户的按时间倒排的 tweets
4. aggregator server 搜集每个分片查询的结果，聚合后返回给 application server

这个方案解决了热点场景，分散了读写请求，但由于需要查询每个数据库分片，延迟较高，但这方面的延迟可以通过缓存层来缓解。

*UserID*

timeline：

1. application server 将请求发到 aggregator server
2. aggregator server 找到该用户关注的所有其它用户
3. aggregator server 发送相应的查询请求到用户所在的数据库分片上，查询对应用户的按时间倒排的 tweets
4. aggregator server 搜集每个分片查询的结果，聚合后返回给 application server

这个方案使得 aggregator server 不需要去访问每个数据库分片，而是从特定的几个分片上查询，减少查询延迟，但缺点在于无法解决热点场景问题，热点用户所在的数据库分片将承受更大的请求压力。本质问题在于数据并没有平均分散到每个数据库分片，且每个分片的数据增减速度也不一样，尽管可以通过重新分片或一致性哈希缓解问题，但也许有更好的设计存在。

*CreationDate*

按 creationDate 分片从单个查询请求 timeline 的角度来说，能够减少查询的分片个数从而减小延迟，但与之伴随的问题就是，读写都会集中到某些分片上，导致这些分片的读写压力增大，反而有可能增加延迟。

TweetID + CreationDate

将 TweetID 与 CreationDate 结合，获得两种方案的长处：

* 快速找到最近发布的 tweets
* 将读写压力分散到各个数据库分片上

但这需要一点黑科技：将 CreationDate 塞进 TweetID 中！

将 tweetID 看作是二进制整数，分为高位 (significant) 区域和低位区域，高位区域负责记录时间戳，即 UNIX Epoch time，低位区域使用计数器来表示该 tweet 为同一 epoch time 下发送的 tweet 序号。如此一来：

* 不需要使用 creationDate 的二级索引，减少写操作的延迟（更新索引）
* 读取的时候不需要根据 creationDate 过滤数据，因为相关信息已经被塞进 TweetID 中，使用 range query 即可。

### Cache

为了减少 DB 的读写压力，我们可以在 aggregators servers 下层再引入 cache，负责缓存热点 tweets 和 users，这样 aggregator servers 在查询 DB 之前可以先看一下所需的数据是否已经在 cache 中，从而挡住大量读写请求。

* replacement policy：使用 LRU cache，或者做一些更细致的策略
* what data to cache：可以只 cache 最近 N 天的数据

如此一来，架构又进一步更新为：

![](/files/-L_qM1SReXOjrkMspa76)

## Real Time Delivery

本节讨论：如何利用 cache 层使得 twitter 服务能够做到 real-time delivery。

核心思想：写操作的时间换读操作的时间

* 在 cache 中记录当前活跃的所有用户订阅的 tweets，即它们各自的 timeline
* 每当用户 A 发布 tweet 时，aggregator servers 需要
  * 将 tweet 写入 database 中，得到 tweetID
  * 查询所有关注用户 A 的用户
  * 找到所有相关用户 timeline 所在的 cache servers，往它们的 timeline 插入相关 tweetID

整个过程如下图所示：

![](/files/-L_qOs5a_FO71TJHnIen)

该方案能将用户查询 timeline 的时间大大缩小，使得 real time 变成现实。

为了缓存更多用户的 timeline 数据，在 cache 中仅存储必要数据的 ID，如下图所示：

![](/files/-L_qPMRsgJ-UKT33cXSZ)

其中，多余的 tweetID 可用来表示转发的 tweet。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://zhenghe.gitbook.io/open-courses/system-design/twitter.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.