system-design-primer/solutions/system_design/pastebin
根号三 301b9d88e4
zh-cn: Sync with upstream to keep it up-to-date (#374)
2020-03-09 21:34:18 -04:00
..
README-zh-Hans.md zh-Hans: Translate Pastebin solution (#273) 2019-06-16 20:21:21 +05:00
README.md zh-cn: Sync with upstream to keep it up-to-date (#374) 2020-03-09 21:34:18 -04:00
__init__.py Add Pastebin solution 2017-03-04 21:05:53 -08:00
pastebin.graffle Add pastebin OmniGraffle diagrams 2017-04-02 08:25:28 -04:00
pastebin.png Add Pastebin solution 2017-03-04 21:05:53 -08:00
pastebin.py Fix coding errors (#149) 2018-04-25 18:19:04 -07:00
pastebin_basic.graffle Add pastebin OmniGraffle diagrams 2017-04-02 08:25:28 -04:00
pastebin_basic.png Add Pastebin solution 2017-03-04 21:05:53 -08:00

README.md

设计 Pastebin.com或 Bit.ly

注意:这个文档中的链接会直接指向系统设计主题索引中的有关部分,以避免重复的内容。你可以参考链接的相关内容,来了解其总的要点、方案的权衡取舍以及可选的替代方案。

除了粘贴板需要存储的是完整的内容而不是短链接之外,设计 Bit.ly是与本文类似的一个问题。

第一步:简述用例与约束条件

搜集需求与问题的范围。 提出问题来明确用例与约束条件。 讨论假设。

我们将在没有面试官明确说明问题的情况下,自己定义一些用例以及限制条件。

用例

我们将把问题限定在仅处理以下用例的范围中

  • 用户输入一些文本,然后得到一个随机生成的链接
    • 过期时间
      • 默认为永不过期
      • 可选设置为一定时间过期
  • 用户输入粘贴板中的 url查看内容
  • 用户是匿名访问的
  • 服务需要能够对页面进行跟踪分析
    • 月访问量统计
  • 服务将过期的内容删除
  • 服务有着高可用性

不在用例范围内的有

  • 用户注册了账号
    • 用户通过了邮箱验证
  • 用户登录已注册的账号
    • 用户编辑他们的文档
  • 用户能设置他们的内容是否可见
  • 用户是否能自行设置短链接

限制条件与假设

提出假设

  • 网络流量不是均匀分布的
  • 生成短链接的速度必须要快
  • 只允许粘贴文本
  • 不需要对页面预览做实时分析
  • 1000 万用户
  • 每个月 1000 万次粘贴
  • 每个月 1 亿次读取请求
  • 10:1 的读写比例

计算用量

如果你需要进行粗略的用量计算,请向你的面试官说明。

  • 每次粘贴的用量
    • 1 KB 的内容
    • shortlink - 7 字节
    • expiration_length_in_minutes - 4 字节
    • created_at - 5 字节
    • paste_path - 255 字节
    • 总计:大约 1.27 KB
  • 每个月的粘贴造作将会产生 12.7 GB 的记录
    • 每次粘贴 1.27 KB * 1000 万次粘贴
    • 3年内大约产生了 450 GB 的新内容记录
    • 3年内生成了 36000 万个短链接
    • 假设大多数的粘贴操作都是新的粘贴而不是更新以前的粘贴内容
  • 平均每秒 4 次读取粘贴
  • 平均每秒 40 次读取粘贴请求

便利换算指南:

  • 每个月有 250 万秒
  • 每秒一个请求 = 每个月 250 万次请求
  • 每秒 40 个请求 = 每个月 1 亿次请求
  • 每秒 400 个请求 = 每个月 10 亿次请求

第二步:概要设计

列出所有重要组件以规划概要设计。

Imgur

第三步:设计核心组件

深入每个核心组件的细节。

用例:用户输入一些文本,然后得到一个随机生成的链接

我们将使用关系型数据库,将其作为一个超大哈希表,将生成的 url 和文件服务器上对应文件的路径一一对应。

我们可以使用诸如 Amazon S3 之类的对象存储服务或者NoSQL来代替自建文件服务器。

除了使用关系型数据库来作为一个超大哈希表之外,我们也可以使用NoSQL来代替它。究竟是用 SQL 还是用 NoSQL。不过在下面的讨论中,我们默认选择了使用关系型数据库的方案。

  • 客户端向向运行反向代理Web 服务器发送一个粘贴请求
  • Web 服务器 将请求转发给Write API 服务
  • Write API服务将会:
    • 生成一个独一无二的 url
      • 通过在 SQL 数据库中查重来确认这个 url 是否的确独一无二
      • 如果这个 url 已经存在了,重新生成一个 url
      • 如果支持自定义 url我们也可以使用用户提供的 url也需要进行查重
    • 将 url 存入 SQL 数据库pastes 表中
    • 将粘贴的数据存入对象存储系统中
    • 返回 url

向你的面试官告知你准备写多少代码

pastes 表的数据结构如下:

shortlink char(7) NOT NULL
expiration_length_in_minutes int NOT NULL
created_at datetime NOT NULL
paste_path varchar(255) NOT NULL
PRIMARY KEY(shortlink)

我们会以shortlinkcreated_at 创建一个 索引以加快查询速度(只需要使用读取日志的时间,不再需要每次都扫描整个数据表)并让数据常驻内存。从内存读取 1 MB 连续数据大约要花 250 微秒,而从 SSD 读取同样大小的数据要花费 4 倍的时间,从机械硬盘读取需要花费 80 倍以上的时间。1

为了生成独一无二的 url我们需要

  • 对用户的 IP 地址 + 时间戳进行 MD5 哈希编码
    • MD5 是一种非常常用的哈希化函数,它能生成 128 字节的哈希值
    • MD5 是均匀分布的
    • 另外,我们可以使用 MD5 哈希算法来生成随机数据
  • 对 MD5 哈希值进行 Base 62 编码
    • Base 62 编码后的值由 [a-zA-Z0-9] 组成,它们可以直接作为 url 的字符,不需要再次转义
    • 在这儿仅仅只对原始输入进行过一次哈希处理Base 62 编码步骤是确定性的(不涉及随机性)
    • Base 64 是另一种很流行的编码形式,但是它生成的字符串作为 url 存在一些问题Base 64m字符串内包含 +/ 符号
    • 下面的 Base 62 pseudocode 算法时间复杂度为 O(k),本例中取 num =7即 k 值为 7
def base_encode(num, base=62):
    digits = []
    while num > 0
      remainder = modulo(num, base)
      digits.push(remainder)
      num = divide(num, base)
    digits = digits.reverse
  • 输出前 7 个字符,其结果将有 62^7 种可能的值,作为短链接来说足够了。因为我们限制了 3 年内最多产生 36000 万个短链接:
url = base_encode(md5(ip_address+timestamp))[:URL_LENGTH]

我们可以调用一个公共的 REST API

$ curl -X POST --data '{ "expiration_length_in_minutes": "60", \
    "paste_contents": "Hello World!" }' https://pastebin.com/api/v1/paste

返回:

{
    "shortlink": "foobar"
}

而对于服务器内部的通信,我们可以使用 RPC

用例:用户输入了一个之前粘贴得到的 url希望浏览其存储的内容

  • 客户端Web 服务器发起读取内容请求
  • Web 服务器将请求转发给Read API服务
  • Read API服务将会:
    • SQL 数据库中检查生成的 url
      • 如果查询的 url 存在于 SQL 数据库中,从对象存储服务将对应的粘贴内容取出
      • 否则,给用户返回报错

REST API:

$ curl https://pastebin.com/api/v1/paste?shortlink=foobar

返回:

{
    "paste_contents": "Hello World"
    "created_at": "YYYY-MM-DD HH:MM:SS"
    "expiration_length_in_minutes": "60"
}

用例:对页面进行跟踪分析

由于不需要进行实时分析,因此我们可以简单地对 Web 服务产生的日志用 MapReduce 来统计 hit 计数(命中数)。

向你的面试官告知你准备写多少代码

class HitCounts(MRJob):

    def extract_url(self, line):
        """从 log 中取出生成的 url。"""
        ...

    def extract_year_month(self, line):
        """返回时间戳中表示年份与月份的一部分"""
        ...

    def mapper(self, _, line):
        """解析日志的每一行,提取并转换相关行,

        将键值对设定为如下形式:

        (2016-01, url0), 1
        (2016-01, url0), 1
        (2016-01, url1), 1
        """
        url = self.extract_url(line)
        period = self.extract_year_month(line)
        yield (period, url), 1

    def reducer(self, key, value):
        """将所有的 key 加起来

        (2016-01, url0), 2
        (2016-01, url1), 1
        """
        yield key, sum(values)

用例:服务删除过期的粘贴内容

我们可以通过扫描 SQL 数据库,查找出那些过期时间戳小于当前时间戳的条目,然后在表中删除(或者将其标记为过期)这些过期的粘贴内容。

第四步:架构扩展

根据限制条件,找到并解决瓶颈。

Imgur

重要提示:不要从最初设计直接跳到最终设计中!

现在你要 1) 基准测试、负载测试。2) 分析、描述性能瓶颈。3) 在解决瓶颈问题的同时评估替代方案、权衡利弊。4) 重复以上步骤。请阅读「设计一个系统,并将其扩大到为数以百万计的 AWS 用户服务」 来了解如何逐步扩大初始设计。

讨论初始设计可能遇到的瓶颈及相关解决方案是很重要的。例如加上一个配置多台 Web 服务器负载均衡器是否能够解决问题?CDN呢?主从复制呢?它们各自的替代方案和需要权衡的利弊又有什么呢?

我们将会介绍一些组件来完成设计,并解决架构扩张问题。内置的负载均衡器将不做讨论以节省篇幅。

为了避免重复讨论,请参考系统设计主题索引相关部分来了解其要点、方案的权衡取舍以及可选的替代方案。

分析数据库 可以用现成的数据仓储系统,例如使用 Amazon Redshift 或者 Google BigQuery 的解决方案。

Amazon S3 的对象存储系统可以很方便地设置每个月限制只允许新增 12.7 GB 的存储内容。

平均每秒 40 次的读取请求(峰值将会更高), 可以通过扩展 内存缓存 来处理热点内容的读取流量,这对于处理不均匀分布的流量和流量峰值也很有用。只要 SQL 副本不陷入复制-写入困境中,SQL Read 副本 基本能够处理缓存命中问题。

平均每秒 4 次的粘贴写入操作(峰值将会更高)对于单个SQL 写主-从 模式来说是可行的。不过,我们也需要考虑其它的 SQL 性能拓展技术:

我们也可以考虑将一些数据移至 NoSQL 数据库

其它要点

是否深入这些额外的主题,取决于你的问题范围和剩下的时间。

NoSQL

缓存

异步与微服务

通信

安全性

请参阅「安全」一章。

延迟数值

请参阅「每个程序员都应该知道的延迟数」

持续探讨

  • 持续进行基准测试并监控你的系统,以解决他们提出的瓶颈问题。
  • 架构拓展是一个迭代的过程。