一个纯正程序员的啰嗦
输入建议系统，指的就是 “typeahead”，比如 Google 搜索，输入一个单词的前几个字母，后面最常用的几个搜索词会被联想出来。有时，它也需要具备一定程度的字符拼写错误自动更正能力。
比如上面这张截图，我输入了 “goog”，在输入框的下方列出了最常见的几个以 goog 开头的搜索短语。
[……]阅读全文
拿到一堆数据，去做架构也好，设计也好，可行性分析也好，工程上需要的是严谨。但是也有很多场景，比如即时的问题争辩和讨论，我们往往需要的是快速、直接的估算，这样的数据显然不需要非常精确，甚至可以说它一定会非常粗略，我们的目标往往只停留在 “量级” 的级别，但是我们依然可以对方案有一个具体的、量化的认知，这比像 “海量”、“高吞吐”、“低延迟” 这类感性的、描述性的表述还是要清晰和有力得多。
举个经典的例子，已知 Twitter 2020 年大约有 2000 亿（200 billion）的推文（tweets）发推服务的吞吐量（TPS, transaction per second）是多少，网络带宽要占用
[……]阅读全文
“ Top K 系统 ” 是非常常见的一种子系统，基本上，就是从全量巨大的统计数据中，筛选出数值最大的 K 个来并按序展示。这样的筛选可以是全时间内的，也可以是最近某一段时间内的；可以是全分类的，也可以是某个特定分类的。
具体来说，像 Twitter 的 Trending Topic，微博热搜，视频网站的点击排行，下载排行（可以是日榜、月榜、总榜）等等。这样的系统，在统计数据非常大（heavy hitters）的时候，其中的挑战性在于两个：
[……]阅读全文
今天记录 Feed 流系统的设计学习笔记，Feed 流常见系统包括 Twitter、微博、Instagram 和抖音等等，它们的特点是，每个用户都是内容创作者，每个用户也都是内容消费者，每个用户看到的内容都是不同的，它取决于用户所关注的用户列表，再结合时间线（有时还包括优先级）将这些用户的最新 feed 聚合，并以流的方式展示出来。
[……]阅读全文
在自己学习各种各样软件系统，特别是分布式系统的过程中，我做了一些笔记，有许多常见的、经典的系统，是非常值得学习和总结的。它们数量不算多，但具有典型意义，可能这样的系统也就十几个。
我在回顾这些笔记的时候发现，有时候一张简单的图，包含最核心的几个设计，就可以很大程度地帮助理解和记忆。所以我想把这些笔记和图解的结合通过文章的形式发出来，预计每篇文章都很短，基本上一张图，加上一点说明性的文字。
Disclaimer：这些都来自我自己的阅读和理解，肯定有着相当的改变和简化，因此它并不代表任何系统实际的样子。
今天是第一篇，即时消息系统，但是基本上好多即时通讯软件都属于这一类，比如微信
[……]阅读全文
在 Amazon 的时候，公司内有大量的组来维护不计其数的 service，而 service 之间的通用通讯方式是公司内部的一个框架，协议是自定的，客户端也是内部的；现在到了 Oracle，我看到这个变成了 RESTful，也就是说，协议本身变成了最常见和适用的一种。我看到有太多论述 RESTful 优点的文章了，而实际工作中也确实有所体会，比如接口和报文的可读性好，不需要特制的客户端，上手和调试都比较容易等等。但是，如果看到某个东西被冠以过多正面的评价，就要当心了。我也慢慢地体会到了一些问题。不过，在谈谈我的思考之前，我想先明确一下我对 REST 的认识，而这点，鉴于历史原因，也是我不太愿意花时间争辩的内容。我 [……]阅读全文
最近在做一些性能优化工作，回想起工作这些年来，参与过的三次集中性能优化，每次都得折腾少则一个月，多则半年。这些内容既是不同视角、不同思路的比较，也是挺有趣的工作经历。
Portal 的性能优化
这已经是大概五年前了，搞了接近半年的 Portal 性能优化，后来某些内容总结在这篇文章里面。既然是 Portal，性能优化上就有它的特点。比如说：
Portal 的性能优化需要从前端和后端两个角度去思考问题，先考虑客户端和服务端之间的交互模型，然后再在客户端和服务端单独考虑分而治之。这个其实和设计的思路是一样的，交互问题需要首先考虑，定义好交互的报文形式（比如某 JSON 的具体形式）以后，包括用户触发什么行为引
[……]阅读全文
作为系统设计学习的一部分，不久前在梳理面试中典型的系统设计问题，发现大部分都可谓有套路可寻。我把思路梳理了一下，简单整理到下面这张图表里面：
对于其中的内容，稍微补充几句：
[……]阅读全文
系统设计方面的问题问题是非常考验经验和思维过程的，而且和常见的算法问题、语言基础问题不同，涉及的面很广，还没有比较一致的判别标准。但无论如何，还是可以归纳一些常见的思路和典型问题的线索。
首先，反复沟通和澄清系统需求。只有把需求澄清清楚了，才可以开始思考并落到纸面上。但是需求的沟通应该是持续和循序渐进的，问题很难从一开始就思考全面。最重要的条目包括：
[……]阅读全文
最近在 Stack Exchange 上面看到一个帖子，是问程序库设计的指导原则的，“What guidelines should I follow while designing a library?”，有趣的是，很多人都在谈论面向设计，各路 API 设计，还有程序语言设计，唯独搜索 “程序库设计”，无论中文还是英文，Google 还是百度都找不到太多内容。但是我想，没有程序员会否认库设计的重要性吧，我想在这里结合这个帖子谈谈我的想法。
在这个帖子里面，votes 最高的回答，提到了这样几类 tips，我在下面简要叙述一下，其中基础的部分包括：
[……]阅读全文
最近在工作中我需要把数据从公共的 Data Warehouse（数据仓库）导出来，放到属于我们 team 自己账号的云端存储资源中去，然后再在我们的应用中查询这样的资源。需要导出数据是因为直接从 Data Warehouse 查询数据是一个缓慢而且异步的过程，而我们的应用数据查询需要实时性。现在要解决这个问题有一些 AWS 的服务可供我们可以选择，基本上分成了两大类：
第一类是存储和内容分发（Storage & Content Delivery）：
[……]阅读全文
在系统设计阶段考虑全面很难，有许多人倾向于把整个设计分成若干阶段，在迭代中完成整个设计，这本身是非常好的，但是，就如同 “先做出来，以后再优化” 这样的经典谎言一样，本身并无错，只是许多程序员都不习惯于真正的迭代设计和迭代优化。举例来说，有一个日益复杂的类，每个人都修改一点点，一直到最后都没有人愿意去做重构，大家的心态都是一样的：“我只修改了一点点，为什么要我去动那么大的刀，于我没有任何好处”。我不在这里谈论这一问题的解决办法，我倒是想说，在开始阶段考虑清楚问题在多数情况下还是很有好处的，设计考虑得越是清楚，在后续阶段代码可以承受越多的变更而不腐朽。
再做系统设计的时候，我们常常会这样说：“一般
[……]阅读全文
有一个 SNS 应用，用户在使用的过程中积累积分，例如登陆+3 点，个人空间每次浏览+1 点，结交每个朋友+5 点等等。同时，很重要的一点是，用户需要看到自己的积分累计有多少，能够根据积分划分用户等级，在自己的空间展示积分。
在用户量比较大的情况下（例如超过三千万），这是一个比较典型的读写都很频繁的问题，而且写入的次数可能和读取的次数差别不大（大多数 SNS 应用中，读次数远超写次数的场景居多，例如用户的状态信息，更新一次以后有成千上万的访问）。
这实际是一个简单，但是典型的功能。试想，给文章投票（例如 “顶” 一下），给微博统计访问次数，给媒体打分……这些都是非常类似的功能。对于这样问题的思考和设计，考虑到
[……]阅读全文
最近在写一个业务上用到的框架，回想起接触过的一些 MVC 框架，尤其是主要贡献在后端表现层上的那些，它们之间有太多的相似，在不断解耦的过程中，层数和模块数也越来越多，需要不断引入层与层之间的映射逻辑将不同层次之间关联起来，我们不妨来查看一下这个过程，能否寻找一些 MVC 框架的共性和启示。
ASP.NET MVC 1 到 MVC 2 模型的进化
注意这里讲的不是 MVC 这个模式，而是 ASP.NET MVC 这个框架。其实这个话题有点老。MVC 1 在桌面程序中应用较多，业务逻辑当然放在 Model 里面，Controller 负责将用户的请求数据传递到 Model 去，之后就放手不管了，让 View 通过观察者模 [……]阅读全文
这篇文章是关于网站性能优化体验的，性能优化是一个复杂的话题，牵涉的东西非常多，我只是按照我的理解列出了性能优化整个过程中需要考虑的种种因素。点到为止，包含的内容以浅显的介绍为主，如果你有见解能告知我那再好不过了。无论如何，希望阅读它的你有所收获。
我眼中的网站性能问题都反映了一个网站的“Availability”（中文叫做可用性，但是这个翻译也不足够达意），以往我的认识是，这个网站如果全部或者部分不可用，那是功能问题，但是如果响应慢、负载差，这才是性能问题；可是后来我逐渐意识到，性能问题涵盖的范围更广，我还没法给出一个准确定义，但是许多非业务逻辑
[……]阅读全文
作为以老版本为模子重做的解耦版本，这个大型互联网应用产品是从 2009 年中开始落地的。而我本人也是该版本的主创人员之一，到今日，团队已经发展到开发测试人数百人的大型互联网产品团队的规模，发布、割接和上线了许许多多个商用版本。
对架构的审视，对选型和设计的反思，不仅仅要在产品初创时期，更要在产品发展的整个过程中进行，团队做同类型产品的能力就是这样在不断总结和自我批评中成熟的。以下为个人观点，难免不对许多人的胃口，不过还是希望这些文字有足够到让人思考的价值。无论如何，对于这样一款产品，从如今的视角来解读它的历史故事，更别有一番风味。
—————–
[……]阅读全文
最近关注了一些缓存框架的特性和实现，包括 OSCache、JCS、Ehcache、Memcached 等等，公司的两个缓存框架，以及一个标准 JSR 107（JCache），发现一些诸多类同的方面。如果你不够熟悉以上，不妨先看看这两篇文章：《OSCache框架源码解析》和《Ehcache详细解读》，再看下面的内容也许会有更多想法。之后再思考，如果要自己去实现一套缓存框架，需要考虑哪些东西？
1、为哪些数据做缓存？
2、缓存框架的核心：
&nb
[……]阅读全文
最近铁道部购票已经成为了热点话题，毛病多得一塌糊涂，如果让你来设计铁道部购票网站，你会怎么做？
这样的网站属于实时性要求较高、并发性要求非常高、容量要求一般的类型，以下是我简单的想法：
1、部署是基于 CDN 的，对于车票查询的环节来说，这是没有问题的。
2、数据库表设计上面，应当有一张车次表，每行代表一趟车，至少有这样的字段：还剩多少张，已被锁定多少张。
3、每次发生订票操作时，先去查询当前是否有余票，有的话锁定一张等待用户操作，如果半小时内无法完成，锁定票放回。
4、查询部分，集群中放置分布式缓存，存放数据的静态页面，但由
[……]阅读全文
观察者模式，指的是定义一种对象间的一对多的关系，当一个对象的状态发生变化的时候，所有依赖于它的对象都将得到通知并更新自己。
现在要说的分歧在这里：
“推” 的方式是指，Subject 维护一份观察者的列表，每当有更新发生，Subject 会把更新消息主动推送到各个 Observer 去。
“拉” 的方式是指，各个 Observer 维护各自所关心的 Subject 列表，自行决定在合适的时间去 Subject 获取相应的更新数据。
“推” 的好处包括：
1、高效。如果没有更新发生，不会有任何更新消息推送的动作，即每次消息推送都发生在确确实实的更新事件之后，都是有意义的。
2、实时。事件发生后的第一时间
[……]阅读全文
