open-courses
  • 公开课笔记
  • CMU 15-445/645 Database Systems
    • Relational Data Model
    • Advanced SQL
    • Database Storage
    • Buffer Pools
    • Hash Tables
    • Tree Indexes
    • Index Concurrency Control
    • Query Processing
    • Sorting&Aggregations
    • Join Algorithms
    • Query Optimization
    • Parallel Execution
    • Embedded Database Logic
    • Concurrency Control Theory
    • Two Phase Locking
    • Timestamp Ordering Concurrency Control
    • Multi-Version Concurrency Control
    • Logging Schemes
    • Database Recovery
    • Introduction to Distributed Databases
    • Distributed OLTP Databases
    • Distributed OLAP Databases
  • UCB - CS162
    • OS intro
    • Introduction to the Process
    • Processes, Fork, I/O, Files
    • I/O Continued, Sockets, Networking
    • Concurrency: Processes & Threads
    • Cooperating Threads, Synchronization
    • Semaphores, Condition Variables, Readers/Writers
    • Scheduling
    • Resource Contention & Deadlock
    • Address Translation, Caching
    • File System (18,19,20)
    • Distributed Systems, Networking, TCP/IP, RPC (21,22)
    • Distributed Storage, Key-Value Stores, Security (23)
    • Security & Cloud Computing (24)
    • Topic: Ensuring Data Reaches Disk
  • MIT - 6.006
    • Sequence and Set Interface
    • Data Structure for Dynamic Sequence Interface
    • Computation Complexity
    • Algorithms and Computation
    • Structure Of Computation
    • Graph & Search
    • Tree & Search
    • Weighted Shortest Paths
    • String Matching, Karp-Rabin
    • Priority Queue Interface & Implementation
    • Dictionary Problem & Implementation
    • Sorting
    • Dynamic Programming
    • Backtracking
    • Self-Balancing Tree
  • MIT - 6.824
    • 2PC & 3PC
    • Introduction and MapReduce
    • RPC and Threads
    • Primary/Backup Replication
    • Lab: Primary/Backup Key/Value Service
    • Google File System (GFS)
    • Raft
    • Lab: Raft - Leader Election
    • Lab: Raft - Log Replication
  • Stanford-CS107
    • 原始数据类型及相互转化
    • 指鹿为马
    • 泛型函数
    • 泛型栈
    • 运行时内存结构
    • 从 C 到汇编
    • 函数的活动记录
    • C 与 C++ 代码生成
    • 编译的预处理过程
    • 编译的链接过程
    • 函数的活动记录续、并发
    • 从顺序到并发和并行
    • 信号量与多线程 1
    • 信号量与多线程 2
    • 复杂多线程问题
    • 函数式编程 - Scheme 1
    • 函数式编程 - Scheme 2
    • 函数式编程 - Scheme 3
    • 函数式编程 - Scheme 4
    • 函数式编程 - Scheme 5
    • Python 基础
  • MIT - 6.001 - SICP
    • 什么是程序
    • 程序抽象
    • 替代模型
    • 时间/空间复杂度
    • 数据抽象
    • 高阶函数
    • Symbol
    • 数据驱动编程与防御式编程
    • 数据抽象中的效率与可读性
    • 数据修改
    • 环境模型
    • 面向对象-消息传递
    • 面向对象 - Scheme 实现
    • 构建 Scheme 解释器
    • Eval-Apply Loop
    • Normal Order (Lazy) Evaluation
    • 通用机
    • 寄存器机器
    • 子程序、栈与递归
    • 在寄存器机器中执行
    • 内存管理
  • MIT - 6.046
    • Randomized Algorithms
    • Skip Lists
  • System Design
    • Twitter
    • Cache Consistency & Coherence
  • DDIA 笔记
    • Replication
    • Transactions
    • The Trouble with Distributed Systems
    • Consistency & Consensus
  • Papers We Love
    • Consistent Hashing and Random Trees (1997)
    • Dynamic Hash Tables (1988)
    • LFU Implementation With O(1) Complexity (2010)
    • Time, Clocks, and the Ordering of Events in a Distributed System (1978)
    • Dapper, a Large-Scale Distributed Systems Tracing Infrastructure (2010)
    • Gorilla: A Fast, Scalable, In-Memory Time Series Database (2015)
  • Release It 笔记
    • Anti-patterns & Patterns in Microservice Architecture
  • Database Design
    • Log Structured Merge (LSM) Tree & Usages in KV Stores
    • Prometheus
Powered by GitBook
On this page
  • System APIs
  • High Level System Design
  • Low Level System Design
  • Data Model & Database
  • Cache
  • Real Time Delivery
  1. System Design

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 只有一个,即

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 数据,同时承载更大量集的读压力,此外我们还需要一些文件存储服务来放置用户上传的图片与视频:

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

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

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 天的数据

如此一来,架构又进一步更新为:

Real Time Delivery

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

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

  • 在 cache 中记录当前活跃的所有用户订阅的 tweets,即它们各自的 timeline

  • 每当用户 A 发布 tweet 时,aggregator servers 需要

    • 将 tweet 写入 database 中,得到 tweetID

    • 查询所有关注用户 A 的用户

    • 找到所有相关用户 timeline 所在的 cache servers,往它们的 timeline 插入相关 tweetID

整个过程如下图所示:

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

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

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

PreviousSkip ListsNextCache Consistency & Coherence

Last updated 6 years ago