Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

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

Posted on 10/04/202009/24/2024 by 四火

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

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

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

[……]阅读全文

Continue reading

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

Posted on 09/25/202009/15/2024 by 四火

【Updated on 9/15/2023】本来只是自己粗浅的总结,但好几位朋友说这套笔记帮助很大,甚至帮他们通过了系统设计面试并找到了工作,那我就打算置顶一段时间,让更多人看到。

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

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

[……]阅读全文

Continue reading

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

Posted on 09/24/202008/14/2022 by 四火

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

  • 文件变更检测;
  • 文件增量上传和下载;
  • 文件分享和同步。

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

[……]阅读全文

Continue reading

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

Posted on 09/21/202008/14/2022 by 四火

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

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

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

[……]阅读全文

Continue reading

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

Posted on 09/19/202009/25/2023 by 四火

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

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

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

[……]阅读全文

Continue reading

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

Posted on 09/15/202008/14/2022 by 四火

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

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

[……]阅读全文

Continue reading

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

Posted on 09/12/202008/14/2022 by 四火

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

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

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

[……]阅读全文

Continue reading

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

Posted on 09/05/202007/04/2022 by 四火

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

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

[……]阅读全文

Continue reading

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

Posted on 09/03/202008/14/2022 by 四火

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

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

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

[……]阅读全文

Continue reading

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

Posted on 09/02/202010/14/2023 by 四火

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

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

[……]阅读全文

Continue reading

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

Posted on 08/30/202010/14/2023 by 四火

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

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

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

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

[……]阅读全文

Continue reading

专精 or 博学,多少人输在了技术选择上?

Posted on 08/15/202010/01/2024 by 四火

上个月在极客时间做了一场直播,聊了聊职业生涯技术选择的话题,直播标题叫做《专精 or 博学,多少人输在了技术选择上?》。我把编辑剪好的视频贴在下面。如果对于我写的极客时间专栏 《全栈工程师修炼指南》感兴趣的话,也欢迎订阅。下面的胶片或视频如果加载比较慢,可以点击 B 站视频链接。

胶片

 

[expand title="胶片"][doc id=6246][/expand]

 

视频

 

[expand title="P1 我是谁"] [/expand]

 

[expand title="P2 第一部分:技术路线的选择"]

[……]阅读全文

Continue reading

图的表示方法

Posted on 08/09/202007/04/2022 by 四火

我觉得去理解数据结构的时候,需要注意到它其实包含两个层面。一个层面是高一级的,从功能、接口的角度去理解,比如说堆,有什么功用,都有怎样的 API;另一个层面是低一级的,从结构和实现的角度去理解,比如堆的实现,可以用数组实现,也可以用单独的节点对象+指针实现。上面一层相同,但是下面一层不同,功能上可能基本一致,但是性能上针对不同的应用场景就可以天差地别。

图就是另外一个典型例子,无向图也好,有向图也好,这是从功能上说的,但它们各自的实现,或者说基于的 “表示方法” 有多种。我记得在学习数据结构早期,基本上没有比较系统地去比较它们,那今天就把这一课补上。

比如上面这个有向图,四个顶点

[……]阅读全文

Continue reading

使用树莓派和 Plex 架设照片和备份服务

Posted on 06/02/202010/08/2024 by 四火

我用手机拍了很多照片,平时都保存在一台 Windows 台式机上,这台机器硬盘空间大,主要干两个事情,一个是我打游戏,一个就是存放多媒体数据(主要是照片,也有很多文档)。有时候我需要它提供照片服务,以方便家人使用各种媒体终端(手机、电视盒子等)阅览,有时候则需要往上面拷贝数据以作备份只用,于是我使用 Plex 折腾了一下,但是由于台式机噪音等等的关系,不适合长期开机,因此当时那个方案还是残缺的。

现在打算彻底解决这个问题。大致总结一下,以下是我的主要的几个需求:

  • 照片服务要能够长期保持在线,私用可以方便地查看照片。开机不能有明显的噪音和功耗问题。
  • 我的照片经常是在 Windows 下进行处理的,

[……]阅读全文

Continue reading

从链表存在环的问题说起

Posted on 05/11/202007/04/2022 by 四火

有这样一个经典的算法题,说是一个单向链表,它内部可能存在环,也可能不存在,用怎样的方法,可以检测出,这个链表是否存在环。下图即是这个形成环的示意,如果单向链表的尾部,指向了链表中的一个节点,而不是指向空,那就构成环了。

接着的一个问题是,怎么检测出这个链表是否有环?

看到这个问题,也许你会觉得,太简单了,但是这个问题只是一个引子。在 《求第 K 个数的问题》一文中,我从简入深,逐步展开,把这 “第 K 个数” 的一系列问题翻了个底朝天。我想关于这个链表成环问题,我也利用类似的思路,看看我是不是也能把这一个问题前前后后讲清楚。

判断单向链表是否成环

在进一步思考怎样判断这个成环

[……]阅读全文

Continue reading

哎,写代码的时间真的越来越少了……

Posted on 04/26/202007/04/2022 by 四火

还记得在读书的时候,就对程序员有种坐在电脑前疯狂敲代码的刻板印象。工作以后,逐渐理解了软件工程师的工作到底是怎么样的,可是写代码,作为软件工程师最重要的本职工作,还是占据了相当比重的时间。在面试别人的时候,也经常被问到这样的问题——“平均你每天有多少时间花在写代码上?”,这个问题看似简单,却能反映出一个问题,软件工程师,能否有足够的时间专注在最本职工作——写代码上。毫无疑问,我完全理解这样的问题,并且,我也一直以来想保持着自己一个 “纯粹” 程序员的身份。我觉得我的职业通道也是一条纯粹的技术人的道路,因而写代码,是一个如同每天吃饭喝水一样的基本操作。

可是,随着职业生涯的进展,特别是近半年来 [……]阅读全文

Continue reading

那些做了一半的项目

Posted on 04/12/202007/04/2022 by 四火

最近有一个项目做了一半不做了,准确地说是由于某些原因,项目需要别的团队来接手了,于是我想随便聊聊这个话题。我猜想,“项目做一半撒手”,这应该是一个很常见的现象,因为这样的事情无论大厂小厂,在软件的世界里不断上演。具体来说,有这样几种典型的情况:

  • 业务变动、组织调整,工作重心变了,项目做了一半直接砍掉,或者无限期停工。这大概是最常见的一种情形。
  • 由于前期的调研、设计的严重问题,或是市场等变化过于剧烈,项目做不下去了,静悄悄地黄了。
  • 项目还做,但是转交给某个其它的团队,这是我这一次遇到的情形。项目还存在,只不过所属关系已经发生变更。

文档和隐性成本

无论哪一种,有一点 [……]阅读全文

Continue reading

写在在家办公四周之时

Posted on 03/28/202007/04/2022 by 四火

几年前我曾经写过一点对于 “在家办公” 的思考,后来又写了一点,但是从来都没有想到过,长期的在家办公如今已经不是一个可选项,而是一个必选项了。

应该说,我从来都不是一个频繁在家办公的支持者,我是说,在家办公这样的互联网公司特有的 “福利” 当然是好的,但是 “频繁” 在家办公对于团队、项目,甚至个人职业成长等等各方面来说,都不是一件好事。我记得在刚加入亚马逊的时候,我听说亚马逊给了一位工程师这样一个 offer——允许一个月之内四分之三的时间远程办公。当时我觉得这件事情还是挺不可思议的,因为像曾经的 37signals 这样的小公司当然容易做到,但是长期和频繁地在家办公却不是大型互联网公司能玩得转的。

[……]阅读全文

Continue reading

技术面试中,什么样的问题才是好问题?

Posted on 02/11/202007/04/2022 by 四火

其实很久以前就想谈一谈这个话题了,但是最近才有了足够的动机。因为从最近参加的很多 debrief 来看,我认为身边大多数的软件工程师面试中,在通过技术问题来考察候选人这方面,很多都做得不够好。比方说,我看到对于一些经验丰富的软件工程师候选人的面试,一些面试官依然是草率地扔出一道算法题让做了事,并且认为能不能够比较清晰完整地将代码写出来,是工程师级别裁定的最重要的标准。而这样的做法我认为是非常不妥的。

首先,我要明确的是,这个问题,指的是技术面试中俗称的 “主要问题”,具体来说,就是面试官会拿出一个问题和候选人讨论,并通过由此开始双方的互相沟通和问题发散来达到考察的目的,因此,这个 “问题

[……]阅读全文

Continue reading

Blog 被黑记录

Posted on 01/25/202007/04/2022 by 四火

最近这个 blog 被黑了,如果你恰巧那一天访问,你会看到所有数据都丢失了,网站打开的页面,是一个初始配置数据库连接的页面。我记得几个月前,这个 blog 曾经遭受过 XML-RPC 攻击,我当时把问题的分析和处理记录在了这里。这一次,可不只是网站拒绝服务这样的问题了,而是整个网站的数据库都被干掉了。

被黑记录

问题出现的时候,网站访问不了了,我登上 MySQL 数据库查看了一下,发现所有数据都删掉了,只留下了一个 WARNING 的表:

上面说的也很清楚,让我往指定地址打 0.08 个比特币,他们就可以把数据还给我,要不然 10 天以后就会把数据库里的数据公开。在 Bitcoin Abuse Database 上,我找到

[……]阅读全文

Continue reading
  • Previous
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • …
  • 23
  • Next

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 编程范型 英语 西雅图 设计 评审 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Big Data and Machine Learning (5)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme