一个纯正程序员的啰嗦
好久没动笔了。
在 2015 年和 2012 年的时候曾经写过一点对于英语学习的认识，在那以后，我对于它的认知也在不断进化，今天我想稍微再写一点。比较起来，如今我印象最深的一点是，英语对我影响最大的，还并非关于信息的获取，而是在日益熟练的情况下，对于更多独立思考的促成。
首先，什么才可以称之为 “熟练”？
是不是英语考试考高分就是熟练了？是不是掌握一万个词就是熟练了？是不是可以无字幕看美剧就是熟练了？是不是可以流利对话就是熟练了？是不是中文说得好好的，因为号称 “用英文思考” 的关系，隔三差五地蹦出几个英文单词就是熟练了？
我觉得都不是。
顺带地，我想吐槽一下上述最后一种情况。
[……]阅读全文
说起美股市场，和 2020 年相比，2021 年真是动荡的一年，起码对我来说是这样。还记得年初的时候我写了一点心得，现在到了年末，我想接着聊一下。在不断地学习和实践中，我也逐渐形成了自己的一套小小的投资体系，其中最重要的是几条选股和投资的原则，虽说这个过程可以说相当崎岖。
市场上有无数的方式可以赚到钱。我知道美股市场上有两大类人，一类是分析基本面的，一类是看技术指标的。这两类人都能取得成功，但是做法却大相径庭。前者在标的大跌的时候往往会分批加仓，而后者则在跌破一个位置后止损离场。我两种思路都尝试过，但是对我来说，经过实践，明显还是前者更加适合我。因此下面我说的，都是奔着长期投资的思路来的，仅供
[……]阅读全文
水文预警。
有段时间没有更新了，今天打算来写一点，本来想写写一年的回顾的，可想想似乎今年似乎内容并不丰富，印象最深的除了疫情就是旅行了，那就干脆随便聊聊今年的旅行吧。要说到这一点，主要原因还是因为去年疫情憋得太久，去年一整年，加上今年的上半年，直到 5 月中旬，印象中除去短程的、当天来回的郊游以外，只在夏天的时候全家搭帐篷在营地过了一夜。作为一个非常喜欢出去 “跑路” 的人来说，以往每年都要出去三、四趟，去年这一年多真的是太不寻常了。
我理解为了疫情控制的原因要减少非必要的旅行，但我本人还是非常反感一刀切 “杜绝” 人口流动的。所有的出行活动都有风险，但是为了避免冒险天天宅在家里也真不是一个好
[……]阅读全文
极客时间四周年的时候搞了个活动，让作者们都写一点最近的思考，我想了想，就写了一些关于 “眼界” 的。这个话题其实我以前也有写到，但是随着阅历的增加，这个词正变得越来越重要。我写的那几段话是：
“每个人都有自己不同的能力和特质，有的是先天具备的，比如有的人天生就记忆力出色；有的是后天努力的，比如通过坚持不懈的奋斗做成一件大事。可是，有的特质却既非先天可具备，又非后天可努力得到，在我们朴素的教育背景中，它们往往总被忽略。它们的其中一个，就是眼界。在投资领域，大概有这样一句话，把一个问题如果放到十年、二十年的维度上去看，问题就会简单很多。倒不是说要宣扬佛系心态，而是说，要有够大的眼界，能够 ‘忽略’
[……]阅读全文
来，说点大逆不道的。
代码是程序员的基础能力，毫无疑问。Linus 说，“Talk is cheap, show me the code.”。软件工程师，归根到底是要做工程的，代码写不好，就谈不上把工程做出来。
可是我觉得，越来越多勤奋的程序员，是写代码写得太多了，而不是太少了。
胡扯！读书百遍，其义自见。书山有路勤为径！代码也是如此，没有足够的积累，怎么能写得好代码？
可是，写代码真的需要那么勤奋地练习，那么大量的积累吗？
我想说一个现象，那就是很多公司每年都会举行调研，一个很常见的问题是，作为程序员，一年工作时间里面，写代码的比重有多少？
有一个很朴素的想
[……]阅读全文
好久没有写一点关于曼联的文字了，上次已经是 2019 年年初了，作为一名铁杆曼联球迷，这期间倒是一场比赛都没有落下过。我看比赛已经过了十多年前那样尽量看直播的阶段了，如今虽说一场不落，每一场却只看录播。老实说，对我来说这很舒服，我可以跳过那些没有营养的赛前、中场休息等等环节。
这过去的一年里面，大家的目光和注意力都被疫情打击得面目全非的英超比赛形式给吸引了，譬如反复的延期，疯狂的赛程，以及缺失的场内观众。但是对于很多球队来说，这既是机会，也是挑战。我猜想今年暑期的转会市场，应该不会再有那些疯狂的转会大单了，疫情导致的球会损失将使得大家花钱都更谨小慎微。从长远来看，我决定这其实是好事，资本的力
[……]阅读全文
最近 blog 没怎么更新，是因为忙于写一个新的专栏——《技术面试官识人手册》。
你有没有听过这样一句话，“招聘是研发团队日常活动的第一要务”。这么说并不夸张，做好面试，匹配到合适的优秀人才，是组建高效能团队的大前提，这会大大降低后期的管理成本。
通常来说，技术面试的环节更多，难度更大，主导或者参与的过程中，你或多或少会遇见这样的问题：
这些问
[……]阅读全文
我不知道有多少朋友和我一样，业余搞一搞股票，觉得生活很充实。但是作为典型的散户，或多或少都有着韭菜的特质，在股市里面折腾，做出一些成功的决策，然后得意；或者做出一些失败的决策，然后后悔。
事先声明，我持有美股股票好多年了，但是正儿八经 “玩” 美股其实没多久，下面记录的是一些我自己的心得体会，仅此而已。
1. 把最多的时间花在寻找和研究一个好生意上面，而不是花在用技术去分析那些自己不了解的股票上面。
我觉得这是最重要的一条。我觉得，和机构和庄家比，散户们总是在弱者一侧，他们有强大的工具，有灵通的消息，有快速的执行，有理性的规划；而散户呢？这些什么都没有，散户有的优势，可能
[……]阅读全文
短网址系统可能是最常见的分布式系统设计问题之一了，本身从业务需求上说，读远多过写，而且数据结构确定且简单，数据量小，还易于使用缓存，因此本身难度在分布式系统的问题里面算是比较低的。另外，这个系统本身 “分布式” 的特性也比较弱，而且从组件图的角度来说，没有多少是 “可画的” ，因此之前也就没有介绍它。不过后来我改变想法了，我觉得还是可以总结总结，特别是可以把一些相关的特殊需求考虑进去。
短网址服务就像是 bit.ly 这样的，给一个长长的 URL，它给你吐出一个较短的 URL，往后访问这个 URL 就可以做到 302 重定向到原来那个长 URL 了。
[……]阅读全文
这篇讲的是证券交易系统，这类系统包含的内容很多，但是我们还是把目光放在核心的交易部分，比如说股票交易。在某个可交易时间，如果卖家 A 要以至少 y 的价格卖掉股票 x，卖家 B 愿以至多 y 的价格买入股票 x，那么这个交易就可以发生。
虽说是交易系统，但是它和任何一个支付平台的交易系统有着显著的不同，它的核心是一个竞价匹配的机制，而非货币支付的机制，简单地说，这个机制包含了这样四个步骤：
从非功能的角度看，有这样几条需求是这样的系统尤其要强调的：
[……]阅读全文
今天这篇是关于实时流处理（real-time stream processing）的，这一类的系统这几年比较多了，但相对而言并没有之前提到的几类基础设施系统常见。为什么说这类系统如今更为常见呢？因为一般说来，或者说曾经有一个普遍的认知，就是 throughput 和 latency 难以兼得的事实：
可是，越来越多的系统需要大量的数据处理，往往需要上面二者 “鱼和
[……]阅读全文
这篇是讲数据监控系统的，常见的包括 Datadog 和 Prometheus 等等。一个比较完整的数据监控系统要包括数据采集和数据展示两个部分。在此基础上，还可以具备告警和其它数据处理的功能。
对于监控的数据， 通常包括两类，一类是操作系统层面的数据，比如 CPU、内存、IO 等等；还有一类是应用相关的数据，这些数据就具备明确的业务意义了。
[……]阅读全文
这篇是关于电商平台秒杀系统的。
首先，我觉得 “秒杀” 是一个中国色彩浓重的词，这样的概念在西方电商系统中也有，但只有在中国，本来业务量就已经如此之巨大了，还将其如此发扬开来。因此顶尖的秒杀高并发场景，还真是基本上只有在中国的电商平台系统中，才能见得到。
其次，我觉得对于系统设计的学习，电商秒杀系统这样的极致，即便再精彩，还是应当放在第二位的。扎扎实实地把常规的高并发系统设计做好，才是最重要的。因为无论秒杀系统使用怎样的特殊技巧和手段，高并发分布式系统才是一个秒杀系统工作的根基。
有了以上说明，现在再来谈论电商秒杀系统。电商秒杀系统，它首先是一个电商系统，因此一个大型的电商系统一
[……]阅读全文
这里讲的 “协同编辑”，指的是 “Collaborative Editing”，多个人同时一起编辑同一个文件，比如说 Google Docs，国内的有有道云协作、石墨文档之类的。这样的系统倒不如我们前面提到的那些应用系统那么 “火”，但是，依然具备相当的典型性。
第一印象，这样的一个系统，我们可以简单做出如下归类：
[……]阅读全文
其实对于 MR（Map Reduce）系统来说，可能更重要的是分治和分步处理的思想，因为现在的基于 MR 的数据处理框架或者平台，在实现上数据处理往往已经和最经典的对于 MR 的理解（最早应该是来自 Google 的那篇论文）有了不少区别。当然，我还是按照之前的做法，把一个典型的 MR 系统简单图示画出来了，这个图相对比较简单。
[……]阅读全文
这一篇记录分布式的流量控制系统。
首先，关于流量控制系统，从功能性需求上考虑，它涉及到使用怎样的规则去限制流量（基于 IP、用户 ID、地域，等等），以及，流量超出限制以后的策略是怎样的（比如返回 HTTP 429 或者带有 ratelimit 的 HTTP headers，queue，客户端 retry with exponential backoff 等等）。其中一个基本的问题是，流控在客户端做还是服务端做，通常来说，服务端是一定要的。对于存在的形式，有的流控功能可以以一个 lib 依附于 app 执行，有的则可以通过一个 service 来实现。
其次，从非功能性需求上考虑，比方说系统的可靠性，增加 lat
[……]阅读全文
这一篇是记录分布式工作流系统的。我这些年来参与了几个不同的分布式工作流系统的工作（以前从另外的角度写了一些总结放在这里），大部分是基于基础分布式工作流引擎二次开发的，但也有从头开始实现一个的。总的来说，从原理上看可以说它们的实现是大同小异，大致是基于 Amazon 的 SWF 的各种实现变体。
从功能需求上看，一个工作流系统，当然是要完成一个工作流的执行和追踪，因此，它的用户，可以定义工作流的逻辑，启动、停止工作流，并能够查询工作流的当前执行状态。但我觉得有一条需要着重强调——自治（Autonomy）能力。分布式工作流系统通常来说，要比其它常见的分布式基础设施，从用户理解的角度来说，要复杂和困难
[……]阅读全文
这篇的内容是关于分布式消息队列的，无论是在实时系统，还是在非实时系统中，它都有广泛的应用。作为一个消息队列，基本的功能需求相对好描述，简单说有两条：
非功能需求方面，这里面有几个基本的重要特性可以拿来考量，可以说这些基本都是分布式系统所共有的，但其中有几个是异步系统所更为看重的——比如说：
[……]阅读全文
从大致的非功能需求角度来说，作为一般的分布式持久化存储系统，这样三个需求从重要性依次排列：
Durability > Availability > Performance
即最重要的是，数据绝对不能丢失，其次是要一直提供服务，最后才是要保持一定的性能。当然，有了上述基础以后，我们还可以谈论任何分布式存储系统都涉及的重要特性，比如一致性。最后，作为特定的存储系统——“数据库”，我们还常常谈论一些特定的特性，比如权限管理和事务控制等等。
下面拿的是 Bigtable 来举例的，它建立在 GFS 这样的分布式文件系统上面，有一定代表性。
[……]阅读全文
继续分布式系统的设计图解，下半部分是基础设施，此篇是分布式文件系统。这里面典型就是 GFS，对应开源的版本就是 HDFS。
既然谈到分布式文件系统，我觉得需要从需求层面做一个简单的说明：
[……]阅读全文