常见分布式基础设施系统设计图解(七):分布式实时流处理系统

今天这篇是关于实时流处理(real-time stream processing)的,这一类的系统这几年比较多了,但相对而言并没有之前提到的几类基础设施系统常见。为什么说这类系统如今更为常见呢?因为一般说来,或者说曾经有一个普遍的认知,就是 throughput 和 latency 难以兼得的事实:

  • 同步系统适用于响应实时性要求高的请求,处理实时性要求高的数据,速度快,处理过程中关注的数据粒度小,吞吐量也相对受限;
  • 异步系统适用于响应实时性要求低的请求,处理实时性要求低的数据,处理过程中关注的数据粒度大,但是吞吐量往往要大得多。

可是,越来越多的系统需要大量的数据处理,往往需要上面二者 “鱼和

[……]阅读全文

常见分布式应用系统设计图解(十一):数据监控系统

这篇是讲数据监控系统的,常见的包括 Datadog 和 Prometheus 等等。一个比较完整的数据监控系统要包括数据采集和数据展示两个部分。在此基础上,还可以具备告警和其它数据处理的功能。

对于监控的数据, 通常包括两类,一类是操作系统层面的数据,比如 CPU、内存、IO 等等;还有一类是应用相关的数据,这些数据就具备明确的业务意义了。

  • 大体上,图中虚线表示控制流,而实现表示实际的统计数据流向。
  • 用户通过 Web UI 来查看数据、定义规则,这些元信息存储在图中上方的元数据库中。
  • Cluster Manager 和不同集群内的 cluster agent 通信,agent 通过心跳的方式和 mana
[……]阅读全文

常见分布式应用系统设计图解(十):电商秒杀系统

这篇是关于电商平台秒杀系统的。

首先,我觉得 “秒杀” 是一个中国色彩浓重的词,这样的概念在西方电商系统中也有,但只有在中国,本来业务量就已经如此之巨大了,还将其如此发扬开来。因此顶尖的秒杀高并发场景,还真是基本上只有在中国的电商平台系统中,才能见得到。

其次,我觉得对于系统设计的学习,电商秒杀系统这样的极致,即便再精彩,还是应当放在第二位的。扎扎实实地把常规的高并发系统设计做好,才是最重要的。因为无论秒杀系统使用怎样的特殊技巧和手段,高并发分布式系统才是一个秒杀系统工作的根基。

有了以上说明,现在再来谈论电商秒杀系统。电商秒杀系统,它首先是一个电商系统,因此一个大型的电商系统一

[……]阅读全文

常见分布式应用系统设计图解(九):协同编辑系统

这里讲的 “协同编辑”,指的是 “Collaborative Editing”,多个人同时一起编辑同一个文件,比如说 Google Docs,国内的有有道云协作、石墨文档之类的。这样的系统倒不如我们前面提到的那些应用系统那么 “火”,但是,依然具备相当的典型性。

第一印象,这样的一个系统,我们可以简单做出如下归类:

  • 这是一个文件编辑系统,这是最最基础的一个功能性需求,它就好像是 Windows 下的记事本,只不过它是在线的。
  • 这是一个分布式系统,客户端/浏览器可以在不同的地方,通过网络和服务端联结,用户的编辑行为转化为请求发送给服务端。
  • 这是一个异步系统,编辑编辑过程中,事件都是由不同用户的浏览器
[……]阅读全文

常见分布式基础设施系统设计图解(六):分布式 MR 系统

其实对于 MR(Map Reduce)系统来说,可能更重要的是分治和分步处理的思想,因为现在的基于 MR 的数据处理框架或者平台,在实现上数据处理往往已经和最经典的对于 MR 的理解(最早应该是来自 Google 的那篇论文)有了不少区别。当然,我还是按照之前的做法,把一个典型的 MR 系统简单图示画出来了,这个图相对比较简单。

  • 还是老规矩,虚线表示控制流,实线表示数据流。
  • 上半部分用户向 Master 这个 job 管理节点提交一个 job 的请求,这个请求被拆解为若干个 task,下半部分的 slave 节点完成 task 的跟踪和执行。
  • 具体执行逻辑上:
    • 首先的输入文件,可以是多个已经拆分了的小文件,也可以是一个大文件
[……]阅读全文

常见分布式基础设施系统设计图解(五):分布式流控系统

这一篇记录分布式的流量控制系统。

首先,关于流量控制系统,从功能性需求上考虑,它涉及到使用怎样的规则去限制流量,以及,流量超出限制以后的策略是怎样的。

其次,从非功能性需求上考虑,对于单机系统,有一些比较成熟的流量控制算法,比如 Leaky Bucket,或者 Token Bucket,我在专栏文章中曾经介绍过。再来说分布式的系统,除去我们经常考虑的分布式系统的特点以外,还需要强调对于流量控制的精度要求这一方面。

为什么要提这个精度要求,是因为对于精度要求的不同,我们可以把需求分成两大类。而这两类的分布式流控在实现上,会比较不一样。

  • 类型一:用于 “保护系统” 的流量控制。这一
[……]阅读全文

常见分布式基础设施系统设计图解(四):分布式工作流系统

这一篇是记录分布式工作流系统的。我这些年来参与了几个不同的分布式工作流系统的工作(以前从另外的角度写了一些总结放在这里),大部分是基于基础分布式工作流引擎二次开发的,但也有从头开始实现一个的。总的来说,从原理上看可以说它们的实现是大同小异,大致是基于 Amazon 的 SWF 的各种实现变体。

从功能需求上看,一个工作流系统,当然是要完成一个工作流的执行和追踪,因此,它的用户,可以定义工作流的逻辑,启动、停止工作流,并能够查询工作流的当前执行状态。但我觉得有一条需要着重强调——自治(Autonomy)能力。分布式工作流系统通常来说,要比其它常见的分布式基础设施,从用户理解的角度来说,要复杂和困难

[……]阅读全文

常见分布式基础设施系统设计图解(三):分布式消息队列

这篇的内容是关于分布式消息队列的,无论是在实时系统,还是在非实时系统中,它都有广泛的应用。作为一个消息队列,基本的功能需求相对好描述,简单说有两条:

  • 首先,围绕着 pub-sub 这样的机制,允许消息发布者发布的特定主题下的消息,能够投递到若干个订阅者。这条几乎是必选的。
  • 其次,消息的有序性,既然是一个队列,那么消息满足先进先出(FIFO)的规则。这一条,部分实际场景方面并非必选。

非功能需求方面,这里面有几个基本的重要特性可以拿来考量,可以说这些基本都是分布式系统所共有的,但其中有几个是异步系统所更为看重的——比如说:

  • Availability
  • Security
  • Consistenc
[……]阅读全文

常见分布式基础设施系统设计图解(二):分布式数据库

从大致的非功能需求角度来说,作为一般的分布式持久化存储系统,这样三个需求从重要性依次排列:

Durability > Availability > Performance

即最重要的是,数据绝对不能丢失,其次是要一直提供服务,最后才是要保持一定的性能。当然,有了上述基础以后,我们还可以谈论任何分布式存储系统都涉及的重要特性,比如一致性。最后,作为特定的存储系统——“数据库”,我们还常常谈论一些特定的特性,比如权限管理和事务控制等等。

下面拿的是 Bigtable 来举例的,它建立在 GFS 这样的分布式文件系统上面,有一定代表性。

  • 图中展示的是一个简单的写数
[……]阅读全文

常见分布式基础设施系统设计图解(一):分布式文件系统

继续分布式系统的设计图解,下半部分是基础设施,此篇是分布式文件系统。这里面典型就是 GFS,对应开源的版本就是 HDFS。

既然谈到分布式文件系统,我觉得需要从需求层面做一个简单的说明:

  • 这里的文件,通常以 “大” 文件为主,越大效率越高,而不会是小文件。小文件的存储,不一定要选择这里说的分布式文件系统——功能上当然行得通,但容易造成效率低下(比如因为元数据占比高,或者是单一 chunk 容易成为请求的热点),通常它们可以存放到某一种 NoSQL 的数据库中去,并辅以其它优化。小文件如果就是要使用分布式文件系统,在存储上需要做一定的额外优化,比如在 GFS 上实现的 Bigtable(多个小文件可以共
[……]阅读全文

常见分布式系统设计图解(汇总)

这一篇是给我记录的那些常见分布式系统设计图解系列的文章做一个汇总,也提供一个访问入口。

如同我在第一篇文中说的那样,自己在学习各种各样分布式系统的过程中,做了一些笔记,也有自己的理解,把它们放到一起,用一张图选择最主要的部分来阐释,从我的角度来说,是能够帮助理解和记忆的。事实上,遇到的很多各种各样的分布式系统,绝大多数都逃不出那最常见的十几种,也就是说,逃不出这些 “套路” 和 “玩法”。这就是把它们整理成一个系列的初衷。

我的想法是,这些文章大致分为两个部分,第一部分是偏重应用的分布式系统,第二部分是偏重基础设施的分布式系统。每一部分的列表是可能继续增长的,我会把它们维护在这里。

[……]阅读全文

常见分布式应用系统设计图解(八):文件同步分享系统

文件同步分享系统包括 Dropbox、Google Drive,也包括国内的各种网盘,比如百度网盘。总的来说,这里讨论的这个系统包含这样几个基本功能:

  • 文件变更检测;
  • 文件增量上传和下载;
  • 文件分享和同步。
  • 总体来说,上半部分是文件变化的检测和上传。上传分为两条路线,一条是控制流,一条是数据流。
  • 客户端方面,包含这样几个关键组件和步骤:
    • 有一个 Watcher 用来监控操作系统的文件变化,无论是 Linux 还是 Windows 都可以在文件系统上挂载回调,当文件系统发生变化的时候通知它。
    • 有一个 Chunker 帮助给需要传输的数据分块,也负责将收到的 chunks 写入成为文件。对它来说它只负责听从 I
[……]阅读全文

常见分布式应用系统设计图解(七):爬虫搜索系统

互联网搜索引擎都有爬虫系统,无论是 Google 还是百度。当然这里我们讨论的只是一个极其简单的版本。

对于爬到的资源,我们这里其实讨论的只是文本而已,还有图片、音频、视频这些媒体,如果我们也需要存下来,那就需要专门的媒体服务。对于媒体文件的存放,在之前的文中已经讨论过,这里就不再覆盖了。

  • 上半部分是爬取的过程,Page Fetcher 根据 URL 队列里面的事件来去实际的页面中爬取内容。不同的网站可以使用不同的 queue,配合从不同 queue 中 poll 的策略,这样可以合理分配资源,避免对某一个网站投入了太多的资源。爬虫需要解析 robot.txt,也要限制爬取的进程/线程数,保证不
[……]阅读全文

常见分布式应用系统设计图解(六):流媒体系统

流媒体系统,主要是视频流媒体系统。比如 YouTube,比如 Netflix,比如爱奇艺,还有优酷。再一个许多大型的社交平台上,几乎是一定要内嵌流媒体服务的,以支持用户上传视频类型的内容。

这类系统我们需要考虑的不只有单纯视频文件的存储和传输,还有文件的编码、解码,和视频截图(比如用作 thumbnail)的生成等等基本功能。

  • 视频文件上传、编码、截图这个过程可以说非常消耗资源,因此视频流媒体系统的处理往往和简单的图片分享系统不一样,它的处理要求异步进行。而异步系统就一定要有队列。
  • 图中上半部分,用户向 Web Server 发起一个视频上传的请求,实际视频上传通过 Uploading
[……]阅读全文

常见分布式应用系统设计图解(五):Proximity 系统

今天是介绍 Proximity 系统,我不知道怎么翻译恰当,就保留英文原文。虽说词义上说的只是 “相似度”,但多数说的是 “地理” 上的相似度。因此,这一类系统多为基于地理上的邻近程度来提供服务的,核心功能就是要找到某人、物或地点地理位置附近的其它人、物或地点。比如像打车系统 Uber、滴滴的叫车功能,比如像大众点评、Yelp 或者百度地图、Google Map 中寻找附近餐馆的功能,或者是 “ 附近的人” 之类基于地理信息的 app 上的小功能。

从读写的角度看,基本上这类功能都要存储位置信息,基于位置的 “寻找” 是很核心的需求,因此读往往比较重。但是写的话差异就比较大了,像有一些应用,比如打车系统,需要司机和

[……]阅读全文

常见分布式应用系统设计图解(四):输入建议系统

输入建议系统,指的就是 “typeahead”,比如 Google 搜索,输入一个单词的前几个字母,后面最常用的几个搜索词会被联想出来。有时,它也需要具备一定程度的字符拼写错误自动更正能力。

比如上面这张截图,我输入了 “goog”,在输入框的下方列出了最常见的几个以 goog 开头的搜索短语。

  • 这个功能可以说不是搜索系统的核心功能,而且要求响应一定要非常迅速,考虑到无法避免的网络延迟,我们希望服务端的处理越快越好。响应数据不用非常准确,但是延迟响应肯定是一个糟糕的结果。所以我们希望服务端的处理的数据尽量都在内存中,几乎不需要怎么读取磁盘,整个过程也要保持简洁。
  • 用户侧的浏览器方
[……]阅读全文

系统设计中的快速估算技巧

拿到一堆数据,去做架构也好,设计也好,可行性分析也好,工程上需要的是严谨。但是也有很多场景,比如即时的问题争辩和讨论,我们往往需要的是快速、直接的估算,这样的数据显然不需要非常精确,甚至可以说它一定会非常粗略,我们的目标往往只停留在 “量级” 的级别,但是我们依然可以对方案有一个具体的、量化的认知,这比像 “海量”、“高吞吐”、“低延迟” 这类感性的、描述性的表述还是要清晰和有力得多。

举个经典的例子,已知 Twitter 2020 年大约有 2000 亿(200 billion)的推文(tweets)发推服务的吞吐量(TPS, transaction per second)是多少,网络带宽要占用

[……]阅读全文

常见分布式应用系统设计图解(三):Top K 系统

“ Top K 系统 ” 是非常常见的一种子系统,基本上,就是从全量巨大的统计数据中,筛选出数值最大的 K 个来并按序展示。这样的筛选可以是全时间内的,也可以是最近某一段时间内的;可以是全分类的,也可以是某个特定分类的。

具体来说,像 Twitter 的 Trending Topic,微博热搜,视频网站的点击排行,下载排行(可以是日榜、月榜、总榜)等等。这样的系统,在统计数据非常大(heavy hitters)的时候,其中的挑战性在于两个:

  1. 无法简单地在单台机器的内存中进行目标 id -> count 计数的简单映射,因为数据量太大,内存放不下。
  2. 无法用实时的方式高效地显示出动态变化的 Top
[……]阅读全文

常见分布式应用系统设计图解(二):Feed 流系统

今天记录 Feed 流系统的设计学习笔记,Feed 流常见系统包括 Twitter、微博、Instagram 和抖音等等,它们的特点是,每个用户都是内容创作者,每个用户也都是内容消费者,每个用户看到的内容都是不同的,它取决于用户所关注的用户列表,再结合时间线(有时还包括优先级)将这些用户的最新 feed 聚合,并以流的方式展示出来。

  • Feed 流系统中,有两种常见的模式,一种是 push,一种是 pull。基本上,对于用户的 “被关注用户”(粉丝)可能远大于 “关注用户” 的系统,比如 Twitter,pull model 是必选,push 是可选;反之,特别是对于一些用户关系要求必须双向的,比如朋友圈,往往不
[……]阅读全文

常见分布式应用系统设计图解(一):即时消息系统

在自己学习各种各样软件系统,特别是分布式系统的过程中,我做了一些笔记,有许多常见的、经典的系统,是非常值得学习和总结的。它们数量不算多,但具有典型意义,可能这样的系统也就十几个。

我在回顾这些笔记的时候发现,有时候一张简单的图,包含最核心的几个设计,就可以很大程度地帮助理解和记忆。所以我想把这些笔记和图解的结合通过文章的形式发出来,预计每篇文章都很短,基本上一张图,加上一点说明性的文字。

Disclaimer:这些都来自我自己的阅读和理解,肯定有着相当的改变和简化,因此它并不代表任何系统实际的样子。

今天是第一篇,即时消息系统,但是基本上好多即时通讯软件都属于这一类,比如微信

[……]阅读全文
back to top