一个纯正程序员的啰嗦
今天聊一下时间的话题。在分布式系统中，“时间” 是一个挺有趣，但是很难处理的东西。我把自己的理解简单整理下来。
首先，单一节点的物理时钟是不可靠的。
物理时钟本身就有偏差，可是除此之外，可以引起节点物理时钟不准确的原因太多了，比如 clock jump。考虑到 NTP 协议，它基于 UDP 通信，可以从权威的时钟源获取信息，进行自动的时间同步，这就可能会发生 clock jump，它就是说，时钟始终会不断进行同步，而同步回来的时间，是有可能不等于当前时间的，那么系统就会设置当前时间到这个新同步回来的时间。即便没有这个原因，考虑到数据从网络传输的延迟，处理数据的延迟等等，物
[……]阅读全文
就像 Martin Fowler 说的那样，“分布式调用的第一原则就是不要分布式”，谈分布式锁也要先说，不要使用分布式锁。原因很简单，分布式系统是软件系统中复杂的一种形式，而分布式锁是分布式系统中复杂的一种形式，没有必要的复杂性就不要引入。
有的逻辑是没有副作用的（纯函数代码），那就可以无锁执行；有的数据经过合理的 sharding 之后，可以使用单线程（单节点）执行，那就单线程执行。
比如一种常见的模式就是使用 queue（比如 Kafka），任务全部放到队列中，然后根据 sharding 的逻辑，不同的 consumer 来处理不同的任务，互相之间不会干扰冲突。
还有
[……]阅读全文
【Updated on 9/15/2023】本来只是自己粗浅的总结，但好几位朋友说这套笔记帮助很大，甚至帮他们通过了系统设计面试并找到了工作，那我就打算置顶一段时间，让更多人看到。
这一篇是给我记录的那些常见分布式系统设计图解系列的文章做一个汇总，也提供一个访问入口。
如同我在第一篇文中说的那样，自己在学习各种各样分布式系统的过程中，做了一些笔记，也有自己的理解，把它们放到一起，用一张图选择最主要的部分来阐释，从我的角度来说，是能够帮助理解和记忆的。事实上，遇到的很多各种各样的分布式系统，绝大多数都逃不出那最常见的十几种，也就是说，逃不出这些 “套路” 和 “玩法”。这就是把它们整理成一
[……]阅读全文
拿到一堆数据，去做架构也好，设计也好，可行性分析也好，工程上需要的是严谨。但是也有很多场景，比如即时的问题争辩和讨论，我们往往需要的是快速、直接的估算，这样的数据显然不需要非常精确，甚至可以说它一定会非常粗略，我们的目标往往只停留在 “量级” 的级别，但是我们依然可以对方案有一个具体的、量化的认知，这比像 “海量”、“高吞吐”、“低延迟” 这类感性的、描述性的表述还是要清晰和有力得多。
举个经典的例子，已知 Twitter 2020 年大约有 2000 亿（200 billion）的推文（tweets）发推服务的吞吐量（TPS, transaction per second）是多少，网络带宽要占用
[……]阅读全文
有这样一个经典的算法题，说是一个单向链表，它内部可能存在环，也可能不存在，用怎样的方法，可以检测出，这个链表是否存在环。下图即是这个形成环的示意，如果单向链表的尾部，指向了链表中的一个节点，而不是指向空，那就构成环了。
接着的一个问题是，怎么检测出这个链表是否有环？
看到这个问题，也许你会觉得，太简单了，但是这个问题只是一个引子。在 《求第 K 个数的问题》一文中，我从简入深，逐步展开，把这 “第 K 个数” 的一系列问题翻了个底朝天。我想关于这个链表成环问题，我也利用类似的思路，看看我是不是也能把这一个问题前前后后讲清楚。
在进一步思考怎样判断这个成环
[……]阅读全文
其实很久以前就想谈一谈这个话题了，但是最近才有了足够的动机。因为从最近参加的很多 debrief 来看，我认为身边大多数的软件工程师面试中，在通过技术问题来考察候选人这方面，很多都做得不够好。比方说，我看到对于一些经验丰富的软件工程师候选人的面试，一些面试官依然是草率地扔出一道算法题让做了事，并且认为能不能够比较清晰完整地将代码写出来，是工程师级别裁定的最重要的标准。而这样的做法我认为是非常不妥的。
首先，我要明确的是，这个问题，指的是技术面试中俗称的 “主要问题”，具体来说，就是面试官会拿出一个问题和候选人讨论，并通过由此开始双方的互相沟通和问题发散来达到考察的目的，因此，这个 “问题
[……]阅读全文
一个分布式系统，经常需要面对同一份数据在不同时间的更改，这个更改可能来自不同节点间数据的同步，也可能来自系统对于客户端写请求的处理，那么这样的更改就可能出现冲突问题。而基于事件发生顺序的冲突问题的解决，是很多分布式系统，在一致性方面，都必须要仔细考虑和妥善处理的问题。我曾经阅读过一些互联网上的材料，但是没有发现哪个能比较系统且简洁地把这个问题和解决描述清楚的，我觉得我也许能够做得更好，于是有了本文。下面我来通过简单的例子介绍这类问题的产生，以及应对的思路。
我来举一个简单例子：
你可以看到，往右的箭头表示在一个分布式系统中，A、B、C 三个节点上，实际时间流逝的时间轴。节点 A[……]阅读全文
作为软件工程师，工作有一些年头了，在不同的公司，也面试过不少人。以前没觉得这事儿多有意思，但是这几年想法改变了，我发现在一家公司，去面试不同的候选人，是一个非常有价值的增长阅历、经验，让自己成长的机会，还有机会见识到各种各样的人的，获知他们不同的思考问题的方式。特别是作为 bartender（在 Oracle，bartender 基本上就是面试的技术负责人，所有团队招人，都必须有一个来自别的团队的 bartender 来保证候选人的水准，具体的面试流程你可以参考一下我写过的这个专栏），这样的机会有很多，虽然会占用一些自己团队和项目的时间，但是和收获比起来，显然是很有价值的。
最近跟一些公司内一
[……]阅读全文
在专栏中的第 36 讲的选修课堂中，我介绍了 Diffie–Hellman 密钥交换这一算法，它可以说是质数在加密技术中的一个应用，并且是通过其中的 “模幂运算” 来实现的。今天，我来介绍质数的另一个应用，RSA 背后的算法。我在互联网上搜索了一下，我发现基本没有能把它背后的实现原理用浅显的中文叙述讲清楚的，但我还是想试一试，看看能不能尽可能避开那些难懂的术语，用尽量形象和易于理解的方式，把 RSA 背后 [……]阅读全文
除了主要内容——工具和实践，这篇文章也对 “谈谈 Ops” 系列做一个汇总，提供一个访问入口。之前几篇，从一个纯粹 dev 狭窄的视角，谈了谈自己对 Ops 的一些认识：
在往下继续以前，如果没有看过前面的文字，不妨移步阅读，因为上面的内容对下面的内容做了一定程度的铺垫。
现在在写的这一篇文字，我准备是最后一篇，主要谈论这样几个事情：一个是工具，另一个是实践。我依然还是从 dev 的视角，而不是从一个专业运维的视角来记叙。
工欲善其事，必先利其器。我在主要且通用的工具 [……]阅读全文
这篇文章算是要和之前写的 《程序员懂业务有多重要？》“唱反调” 了。
从工作开始，我就不断被灌输着一种业务至上的观点，无论在中国的公司，还是美国的公司，衡量一个决定或者一个需求的价值，都是在业务上有多大的帮助，都说 business impact 是什么。我从不怀疑单纯这样做的初衷，但是我质疑单纯这样做的结果。我觉得，即便是一个业务驱动为主的团队，在决策的时候，技术的占比，应当占据显著的地位。因而我说，不要被业务牵着鼻子走。继续把这一点发扬光大，我认为它对团队发展，对个人发展，都是如此。
曾经认为，这样的观点应该是公认的，但是我越来越发现，事实并不是这样。应该说几乎所有程序员都看到了业务上 [……]阅读全文
对于程序员来说，大多数人公司都有技术和管理两条发展路线，通常在同一家公司，管理路线的发展可能性，要相对广阔一些；但是技术路线也有技术路线的好处，比如相对而言更依赖于硬实力，因而工作机会丰富。我相信有不少程序员都和我一样，坚守着技术路线，无论是进还是退，都对管理者的岗位没有什么兴趣。
兴许大家都听到软实力和硬实力的概念。对于一个技术人来说，硬实力大致上可以认为是计算机和软件工程相关的技术能力，1 还是 0，是还是非，会不会算法，懂不懂设计，清清楚楚，明明白白； 而软实力则反过来，听起来挺抽象，挺模糊，比如沟通能力，自我管理能力，但是却扮演者重要的角色，甚至随着职业生涯的发展，它的影响力越来越大 [……]阅读全文
最近才更新到微信的最新版本，早有耳闻公众号变成了微博似的信息流展示信息。之前也没有太在意，这次微信客户端版本更新以后，发现坏了坏了，以往的阅读习惯已经被彻底毁掉了。下面两图都是我手机上的截图，左边是新的信息流模式，右边是信息流界面下点击右上角图标，回到的 “类似以往” 的基于订阅号发布者的模式。
首先我要澄清的是，我认为信息流是绝大多数 SNS 软件都乐意采用的信息传递模式，简洁而且高效，包括我经常使用的那些应用，比如微博，比如知乎，比如 LinkedIn，甚至绝大多数 RSS 软件，因此，它绝不是一个新东西。毫无疑问，基于信息和基于信息发布账号（公众号）的方式比较起来，通常前者更有优势，但是此事
[……]阅读全文
曾经写过一点关于代码评审（code review）的文章，比如这篇和这篇，现在觉得关于它的认识又有了不少更新。软件工程的技术和实践分成两部分，一部分是和书本知识一致的，大约占一半，这部分基本上在大学里就可以学，自学只要方法得当、刻苦努力也可是途径；但是第二部分来自于实际团队、经验，内容通常无法从书本当中获得，而且难说对错，不同的人和不同的经历造就了不同的认识。代码评审就是第二部分颇具槽点，可以大加讨论的典型。
代码评审是展现个性和性格的途径
我本人特别反对一种颇为常见的观点，就是 “一个良好运作的项目，不同的人，应该写出一样的代码”。我非常理解这种观点的初衷，一个良好规范约束的团队中 [……]阅读全文
最近 Blog 遭遇了几个安全问题，折腾了几个钟头，在此记录一下。
最大的问题是 blog 访问时不时地出现 “502 bad gateway”，即便不出现，latency 也能达到接近三十秒。
于是登上 vps 去看原因，top 命令发现 CPU 都用完了。靠，十个 php-fpm 居然都在满功率工作。研究了一下，通常 php-fpm 在没有请求的时候是不应该占用那么多 CPU 资源的，而且 mysql 也高，似乎有人在访问网站，但是去 access log 里面却没找到东西：
top - 02:08:12 up 56 min, 1 user, load average: 10.18, 9.41, 8.68
[……]阅读全文
一道经典的题目。给一堆乱序的数，如果它们从小到大排好，求第 k 个是多少。假设排列的下标从 1 开始，而非 0 开始。
这个问题如此之简单而熟悉，可它却可以是很多现实问题的某一个子问题的抽象。它本身相关的问题其实就不少，而且还可以不断演进，成为不同复杂程度的问题。
关于这个问题的分析和演进，我们不妨从一左一右两条分支——堆排序或者快排，来分别进行。在不断演化问题的时候，会这两个分支之间跳来跳去，为了尽量清晰的考虑，我采用一种新方法——使用 【分支：堆排序】和 【分支：快排】来标注。
Java 中快排用 Arrays.sort 就可以了，如果是堆排序需要用到 PriorityQueue。 用 Array[……]阅读全文
这是前端框架比较和吐槽的第二篇。
Ember.js
Ember.js 的 extend 的写法很类似于 JQuery 或者是 Backbone.js，创建 Application，然后在它下面创建相应的 Model（Object）、Controller、Router、View 和 Template，这些都是非常类似的。但是它更为先进的地方在于，一些重复的样板代码，比如给 template 注入上下文并渲染，如果命名按照 CoC 的原则正确完成的话，都由框架自动完成，这就省去不少体力活。CoC 还体现在 URL mapping 上面，比如”/books/book_id” 配置在 books.index 的 Router 里，Contro
[……]阅读全文
和一些前端框架打过交道，想起来这也是技术选型中经常面对的内容。我把我的经验、思考、感受，甚至是吐槽，记录在这里，有些零散，并且更多的是个人的感悟。而且由于技术所限，可能部分内容不够深入，或者不甚客观。当然，网上有很多分析对比，视角可能更为全面和系统。如果你在技术选型，或者在考虑要学习使用哪一款 MVC／MVP／MVVM 框架的时候，此文能够给你有价值的信息，就更棒了。如果你觉得我哪些部分说得不正确，或者需要补充，也烦请告知。
需要预先说明的是，这篇文章不是教程，因此如果你对其中某一框架知之甚少，可能需要先去简单学习了解以后才能和我产生共鸣，或者产生反驳的冲动。
以下是第一部分，先谈谈 GWT、An
[……]阅读全文
几年前曾经写过一点点对于缓存框架设计的体会，这大半年和工作流系统打交道颇为丰富，因此想总结一点关于工作流系统的设计。
首先，明确工作流（workflow）系统的定义。维基百科上有极其简单的介绍。我记得以前在文章里面说过，作为大公司里面的小 team，为了做一些有趣的东西，从而更好的招人，通常有几个众人皆知的突破口：比如一个更符合业务需求的 storage，再比如一个自定义的工作流系统。在 Amazon 内部，我接触过好多个 workflow，而且大多以 Amazon SWF 为原型（当时学习的时候还写了一点体会，link 1 和 link 2），于是宏观上看，60% 的东西是一样的，大同小异；但是也有很多重
[……]阅读全文
下面这些关于 Spark 的性能调优项，有的是来自官方的，有的是来自别的的工程师，有的则是我自己总结的。
基本概念和原则
首先，要搞清楚 Spark 的几个基本概念和原则，否则系统的性能调优无从谈起：
[……]阅读全文