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

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

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

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

[……]阅读全文

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

文件同步分享系统包括 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:这些都来自我自己的阅读和理解,肯定有着相当的改变和简化,因此它并不代表任何系统实际的样子。

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

[……]阅读全文

几个系统设计问题的解决思路

曾经写过一些系统设计方面的思考(比如这个这个),但是最近准备面试,又接触了更多系统设计方面的问题。这里我想简单记录一些典型系统设计问题的思路。通过学习常见的系统,在心中形成一些问题解决的套路,以在思考和分析新问题的时候提供一些既定思路。很抱歉时间关系写得很简略,主要是提示一些思路和方向。

设计 Tweeter
两种常见模型的 trade off:

  • Pull on demand: merge x timelines
  • Push on change: async, read once to get them

缓存的设计,cache through

设计 Web crawl[……]阅读全文

三次性能优化经历

performance

最近在做一些性能优化工作,回想起工作这些年来,参与过的三次集中性能优化,每次都得折腾少则一个月,多则半年。这些内容既是不同视角、不同思路的比较,也是挺有趣的工作经历。

Portal 的性能优化

这已经是大概五年前了,搞了接近半年的 Portal 性能优化,后来某些内容总结在这篇文章里面。既然是 Portal,性能优化上就有它的特点。比如说:

Portal 的性能优化需要从前端和后端两个角度去思考问题,先考虑客户端和服务端之间的交互模型,然后再在客户端和服务端单独考虑分而治之。这个其实和设计的思路是一样的,交互问题需要首先考虑,定义好交互的报文形式(比如某 JSON 的具体形式)以后,包括用户触发什么行为引

[……]阅读全文

系统设计的典型分层和涉及的知识点

作为系统设计学习的一部分,不久前在梳理面试中典型的系统设计问题,发现大部分都可谓有套路可寻。我把思路梳理了一下,简单整理到下面这张图表里面:

System Design Layers

对于其中的内容,稍微补充几句:

  • 系统设计需要经验的积累,但也确确实实有章可循。问的问题考察的类型很集中,比如同步、异步,消息 push 和 pull,根据实际问题设计存储的数据结构,对于 scalability、availability 的认识等等。最喜欢被问到的问题,我在 《系统设计典型问题的思考》这里列了几个。
  • pull on demand 和 push on change 是消息系统里两种极其典型的消息传播方式,基本上设计 twitte

[……]阅读全文

读写模型整理笔记

读模型

1、主键读

最常见的读模型,说是主键,其实也包括其它索引键,或者联合主键。

常见实现:hash,时间复杂度可以接近 O(1);B 树或变种:时间复杂度接近 O(log(n))。

关于 B 树和变种:

B 树(B-树):本质上是二叉查找树的升级版,变成了平衡的 N 叉查找树,这个 N 的范围根据磁盘一次读取的块大小来调整,这样复杂度 log n 的底数就从 2 变成一个更大的数,减少了树的高度。除此以外,还有一些额外的优化,比如为了插入和删除的性能考虑,通常准备一些预留的空间,只要在当前块或者邻近块中找到空间写入,就避免了开销巨大的所有记录向后偏移的操作。

B 树的阶:

  1. 一棵 m 阶的 B 树最多有 m 棵子树;
  2. 根节点至少有

[……]阅读全文

系统设计典型问题的思考

CAP系统设计方面的问题问题是非常考验经验和思维过程的,而且和常见的算法问题、语言基础问题不同,涉及的面很广,还没有比较一致的判别标准。但无论如何,还是可以归纳一些常见的思路和典型问题的线索。

首先,反复沟通和澄清系统需求。只有把需求澄清清楚了,才可以开始思考并落到纸面上。但是需求的沟通应该是持续和循序渐进的,问题很难从一开始就思考全面。最重要的条目包括:

  • use cases,通常问题只需要 2~3 个 use cases 需要考虑,其他的部分会晚些考虑,或者不考虑。这样就可以简化问题。
  • 用户数量(用户可以是下游系统或者人)、数据数量,澄清这个事实无疑非常重要,对系统设计的决策有重大意义。
  • 请求模型,

[……]阅读全文

程序的库设计

think 最近在 Stack Exchange 上面看到一个帖子,是问程序库设计的指导原则的,“What guidelines should I follow while designing a library?”,有趣的是,很多人都在谈论面向设计,各路 API 设计,还有程序语言设计,唯独搜索 “程序库设计”,无论中文还是英文,Google 还是百度都找不到太多内容。但是我想,没有程序员会否认库设计的重要性吧,我想在这里结合这个帖子谈谈我的想法。

在这个帖子里面,votes 最高的回答,提到了这样几类 tips,我在下面简要叙述一下,其中基础的部分包括:

  • Pin Map,明确你期望库主要用来做什么,但不要把它定得

[……]阅读全文

实际技术选型的考虑因素

tech

最近在工作中我需要把数据从公共的 Data Warehouse(数据仓库)导出来,放到属于我们 team 自己账号的云端存储资源中去,然后再在我们的应用中查询这样的资源。需要导出数据是因为直接从 Data Warehouse 查询数据是一个缓慢而且异步的过程,而我们的应用数据查询需要实时性。现在要解决这个问题有一些 AWS 的服务可供我们可以选择,基本上分成了两大类:

第一类是存储和内容分发(Storage & Content Delivery):

  • CloudFront:CloudFront 是用于内容分发给不同地区用户的,它在全球设有数个 “edge”,作为临近网络访问数据的入口。就如同大网站建立

[……]阅读全文

留心那些潜在的系统设计问题

500在系统设计阶段考虑全面很难,有许多人倾向于把整个设计分成若干阶段,在迭代中完成整个设计,这本身是非常好的,但是,就如同 “先做出来,以后再优化” 这样的经典谎言一样,本身并无错,只是许多程序员都不习惯于真正的迭代设计和迭代优化。举例来说,有一个日益复杂的类,每个人都修改一点点,一直到最后都没有人愿意去做重构,大家的心态都是一样的:“我只修改了一点点,为什么要我去动那么大的刀,于我没有任何好处”。我不在这里谈论这一问题的解决办法,我倒是想说,在开始阶段考虑清楚问题在多数情况下还是很有好处的,设计考虑得越是清楚,在后续阶段代码可以承受越多的变更而不腐朽。

再做系统设计的时候,我们常常会这样说:“一般

[……]阅读全文

用户积分功能的设计

image 有一个 SNS 应用,用户在使用的过程中积累积分,例如登陆+3 点,个人空间每次浏览+1 点,结交每个朋友+5 点等等。同时,很重要的一点是,用户需要看到自己的积分累计有多少,能够根据积分划分用户等级,在自己的空间展示积分。

在用户量比较大的情况下(例如超过三千万),这是一个比较典型的读写都很频繁的问题,而且写入的次数可能和读取的次数差别不大(大多数 SNS 应用中,读次数远超写次数的场景居多,例如用户的状态信息,更新一次以后有成千上万的访问)。

这实际是一个简单,但是典型的功能。试想,给文章投票(例如 “顶” 一下),给微博统计访问次数,给媒体打分……这些都是非常类似的功能。对于这样问题的思考和设计,考虑到

[……]阅读全文

MVC 框架的映射和解耦

mvc 最近在写一个业务上用到的框架,回想起接触过的一些 MVC 框架,尤其是主要贡献在后端表现层上的那些,它们之间有太多的相似,在不断解耦的过程中,层数和模块数也越来越多,需要不断引入层与层之间的映射逻辑将不同层次之间关联起来,我们不妨来查看一下这个过程,能否寻找一些 MVC 框架的共性和启示。

ASP.NET MVC 1 到 MVC 2 模型的进化

注意这里讲的不是 MVC 这个模式,而是 ASP.NET MVC 这个框架。其实这个话题有点老。MVC 1 在桌面程序中应用较多,业务逻辑当然放在 Model 里面,Controller 负责将用户的请求数据传递到 Model 去,之后就放手不管了,让 View 通过观察者模 [……]阅读全文

back to top