眼界和边界

极客时间四周年的时候搞了个活动,让作者们都写一点最近的思考,我想了想,就写了一些关于 “眼界” 的。这个话题其实我以前也有写到,但是随着阅历的增加,这个词正变得越来越重要。我写的那几段话是:

“每个人都有自己不同的能力和特质,有的是先天具备的,比如有的人天生就记忆力出色;有的是后天努力的,比如通过坚持不懈的奋斗做成一件大事。可是,有的特质却既非先天可具备,又非后天可努力得到,在我们朴素的教育背景中,它们往往总被忽略。它们的其中一个,就是眼界。在投资领域,大概有这样一句话,把一个问题如果放到十年、二十年的维度上去看,问题就会简单很多。倒不是说要宣扬佛系心态,而是说,要有够大的眼界,能够 ‘忽略’

[……]阅读全文

多吹牛,少写代码

来,说点大逆不道的。

代码是程序员的基础能力,毫无疑问。Linus 说,“Talk is cheap, show me the code.”。软件工程师,归根到底是要做工程的,代码写不好,就谈不上把工程做出来。

可是我觉得,越来越多勤奋的程序员,是写代码写得太多了,而不是太少了。

胡扯!读书百遍,其义自见。书山有路勤为径!代码也是如此,没有足够的积累,怎么能写得好代码?

可是,写代码真的需要那么勤奋地练习,那么大量的积累吗?

我想说一个现象,那就是很多公司每年都会举行调研,一个很常见的问题是,作为程序员,一年工作时间里面,写代码的比重有多少?

有一个很朴素的想

[……]阅读全文

曼联,索尔斯克亚,2020-2021 赛季

好久没有写一点关于曼联的文字了,上次已经是 2019 年年初了,作为一名铁杆曼联球迷,这期间倒是一场比赛都没有落下过。我看比赛已经过了十多年前那样尽量看直播的阶段了,如今虽说一场不落,每一场却只看录播。老实说,对我来说这很舒服,我可以跳过那些没有营养的赛前、中场休息等等环节。

这过去的一年里面,大家的目光和注意力都被疫情打击得面目全非的英超比赛形式给吸引了,譬如反复的延期,疯狂的赛程,以及缺失的场内观众。但是对于很多球队来说,这既是机会,也是挑战。我猜想今年暑期的转会市场,应该不会再有那些疯狂的转会大单了,疫情导致的球会损失将使得大家花钱都更谨小慎微。从长远来看,我决定这其实是好事,资本的力

[……]阅读全文

新写了一个极客时间专栏《技术面试官识人手册》

最近 blog 没怎么更新,是因为忙于写一个新的专栏——《技术面试官识人手册》

你有没有听过这样一句话,“招聘是研发团队日常活动的第一要务”。这么说并不夸张,做好面试,匹配到合适的优秀人才,是组建高效能团队的大前提,这会大大降低后期的管理成本。

通常来说,技术面试的环节更多,难度更大,主导或者参与的过程中,你或多或少会遇见这样的问题:

  • 作为技术组长,手中项目急缺人,如何快速补齐岗位?
  • 招怎样的人好,是能立马干活的,还是有潜力的?
  • 技术面试应该怎样问系统设计问题?
  • 是不是拿算法题让候选人做就好了?如果他恰好做过这个题目怎么办?
  • 如何综合团队视角,评估候选人水平,决定其去留?

这些问

[……]阅读全文

美股市场上学到的道理

我不知道有多少朋友和我一样,业余搞一搞股票,觉得生活很充实。但是作为典型的散户,或多或少都有着韭菜的特质,在股市里面折腾,做出一些成功的决策,然后得意;或者做出一些失败的决策,然后后悔。

事先声明,我持有美股股票好多年了,但是正儿八经 “玩” 美股其实没多久,下面记录的是一些我自己的心得体会,仅此而已。

1. 把最多的时间花在寻找和研究一个好生意上面,而不是花在用技术去分析那些自己不了解的股票上面。

我觉得这是最重要的一条。我觉得,和机构和庄家比,散户们总是在弱者一侧,他们有强大的工具,有灵通的消息,有快速的执行,有理性的规划;而散户呢?这些什么都没有,散户有的优势,可能

[……]阅读全文

常见分布式应用系统设计图解(十三):短网址系统

短网址系统可能是最常见的分布式系统设计问题之一了,本身从业务需求上说,读远多过写,而且数据结构确定且简单,数据量小,还易于使用缓存,因此本身难度在分布式系统的问题里面算是比较低的。另外,这个系统本身 “分布式” 的特性也比较弱,而且从组件图的角度来说,没有多少是 “可画的” ,因此之前也就没有介绍它。不过后来我改变想法了,我觉得还是可以总结总结,特别是可以把一些相关的特殊需求考虑进去。

短网址服务就像是 bit.ly 这样的,给一个长长的 URL,它给你吐出一个较短的 URL,往后访问这个 URL 就可以做到 302 重定向到原来那个长 URL 了。

  • 图中上半部分是写的部分,无论是 API 直接调用还是
[……]阅读全文

常见分布式应用系统设计图解(十二):证券交易系统

这篇讲的是证券交易系统,这类系统包含的内容很多,但是我们还是把目光放在核心的交易部分,比如说股票交易。在某个可交易时间,如果卖家 A 要以至少 y 的价格卖掉股票 x,卖家 B 愿以至多 y 的价格买入股票 x,那么这个交易就可以发生。

虽说是交易系统,但是它和任何一个支付平台的交易系统有着显著的不同,它的核心是一个竞价匹配的机制,而非货币支付的机制,简单地说,这个机制包含了这样四个步骤:

  • 挂单(可以是买单,也可以是卖单)
  • 匹配(或者叫做撮合)
  • 成交
  • 清算

从非功能的角度看,有这样几条需求是这样的系统尤其要强调的:

  • Consistency,从单个交易的角度来说,主要就是事务性,这是交易系统最最基
[……]阅读全文

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

今天这篇是关于实时流处理(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,也要限制爬取的进程/线程数,保证不
[……]阅读全文
back to top