一个纯正程序员的啰嗦
支付（Payment）系统可以很复杂，比如可以和银行打交道，和信用卡系统打交道。如果我们考虑用户在一家电商买东西，在结账的时候，借助电商支持的支付系统（Payment Service Provider）来完成支付行为。
支付系统需要结合商家（包含卖家和买家）一起来看。最典型的一种需求是，卖家在电商网站挂了东西卖，买家挑选了货物，结账并支付，电商依赖于支付系统来完成支付，并通知买家支付成功。
[……]阅读全文
典型的互联网应用的日志系统，从功能需求上看主要包括收集，存储和分析，以及展示这样三个部分，因此整个系统我觉得也可以按此思路大致可以分为三个部分：
非功能需求方面，我觉得可以考虑这样几个要点：
[……]阅读全文
短网址系统可能是最常见的分布式系统设计问题之一了，本身从业务需求上说，读远多过写，而且数据结构确定且简单，数据量小，还易于使用缓存，因此本身难度在分布式系统的问题里面算是比较低的。另外，这个系统本身 “分布式” 的特性也比较弱，而且从组件图的角度来说，没有多少是 “可画的” ，因此之前也就没有介绍它。不过后来我改变想法了，我觉得还是可以总结总结，特别是可以把一些相关的特殊需求考虑进去。
短网址服务就像是 bit.ly 这样的，给一个长长的 URL，它给你吐出一个较短的 URL，往后访问这个 URL 就可以做到 302 重定向到原来那个长 URL 了。
[……]阅读全文
这篇讲的是证券交易系统，这类系统包含的内容很多，但是我们还是把目光放在核心的交易部分，比如说股票交易。在某个可交易时间，如果卖家 A 要以至少 y 的价格卖掉股票 x，卖家 B 愿以至多 y 的价格买入股票 x，那么这个交易就可以发生。
虽说是交易系统，但是它和任何一个支付平台的交易系统有着显著的不同，它的核心是一个竞价匹配的机制，而非货币支付的机制，简单地说，这个机制包含了这样四个步骤：
从非功能的角度看，有这样几条需求是这样的系统尤其要强调的：
[……]阅读全文
这篇是讲数据监控系统的，常见的包括 Datadog 和 Prometheus 等等。一个比较完整的数据监控系统要包括数据采集和数据展示两个部分。在此基础上，还可以具备告警和其它数据处理的功能。
对于监控的数据， 通常包括两类，一类是操作系统层面的数据，比如 CPU、内存、IO 等等；还有一类是应用相关的数据，这些数据就具备明确的业务意义了。
[……]阅读全文
这篇是关于电商平台秒杀系统的。
首先，我觉得 “秒杀” 是一个中国色彩浓重的词，这样的概念在西方电商系统中也有，但只有在中国，本来业务量就已经如此之巨大了，还将其如此发扬开来。因此顶尖的秒杀高并发场景，还真是基本上只有在中国的电商平台系统中，才能见得到。
其次，我觉得对于系统设计的学习，电商秒杀系统这样的极致，即便再精彩，还是应当放在第二位的。扎扎实实地把常规的高并发系统设计做好，才是最重要的。因为无论秒杀系统使用怎样的特殊技巧和手段，高并发分布式系统才是一个秒杀系统工作的根基。
有了以上说明，现在再来谈论电商秒杀系统。电商秒杀系统，它首先是一个电商系统，因此一个大型的电商系统一
[……]阅读全文
这里讲的 “协同编辑”，指的是 “Collaborative Editing”，多个人同时一起编辑同一个文件，比如说 Google Docs，国内的有有道云协作、石墨文档之类的。这样的系统倒不如我们前面提到的那些应用系统那么 “火”，但是，依然具备相当的典型性。
第一印象，这样的一个系统，我们可以简单做出如下归类：
[……]阅读全文
这一篇是给我记录的那些常见分布式系统设计图解系列的文章做一个汇总，也提供一个访问入口。
如同我在第一篇文中说的那样，自己在学习各种各样分布式系统的过程中，做了一些笔记，也有自己的理解，把它们放到一起，用一张图选择最主要的部分来阐释，从我的角度来说，是能够帮助理解和记忆的。事实上，遇到的很多各种各样的分布式系统，绝大多数都逃不出那最常见的十几种，也就是说，逃不出这些 “套路” 和 “玩法”。这就是把它们整理成一个系列的初衷。
我的想法是，这些文章大致分为两个部分，第一部分是偏重应用的分布式系统，第二部分是偏重基础设施的分布式系统。每一部分的列表是可能继续增长的，我会把它们维护在这里。
[……]阅读全文
文件同步分享系统包括 Dropbox、Google Drive，也包括国内的各种网盘，比如百度网盘。总的来说，这里讨论的这个系统包含这样几个基本功能：
[……]阅读全文
互联网搜索引擎都有爬虫系统，无论是 Google 还是百度。当然这里我们讨论的只是一个极其简单的版本。
对于爬到的资源，我们这里其实讨论的只是文本而已，还有图片、音频、视频这些媒体，如果我们也需要存下来，那就需要专门的媒体服务。对于媒体文件的存放，在之前的文中已经讨论过，这里就不再覆盖了。
[……]阅读全文
流媒体系统，主要是视频流媒体系统。比如 YouTube，比如 Netflix，比如爱奇艺，还有优酷。再一个许多大型的社交平台上，几乎是一定要内嵌流媒体服务的，以支持用户上传视频类型的内容。
这类系统我们需要考虑的不只有单纯视频文件的存储和传输，还有文件的编码、解码，和视频截图（比如用作 thumbnail）的生成等等基本功能。
[……]阅读全文
今天是介绍 Proximity 系统，我不知道怎么翻译恰当，就保留英文原文。虽说词义上说的只是 “相似度”，但多数说的是 “地理” 上的相似度。因此，这一类系统多为基于地理上的邻近程度来提供服务的，核心功能就是要找到某人、物或地点地理位置附近的其它人、物或地点。比如像打车系统 Uber、滴滴的叫车功能，比如像大众点评、Yelp 或者百度地图、Google Map 中寻找附近餐馆的功能，或者是 “ 附近的人” 之类基于地理信息的 app 上的小功能。
从读写的角度看，基本上这类功能都要存储位置信息，基于位置的 “寻找” 是很核心的需求，因此读往往比较重。但是写的话差异就比较大了，像有一些应用，比如打车系统，需要司机和
[……]阅读全文
输入建议系统，指的就是 “typeahead”，比如 Google 搜索，输入一个单词的前几个字母，后面最常用的几个搜索词会被联想出来。有时，它也需要具备一定程度的字符拼写错误自动更正能力。
比如上面这张截图，我输入了 “goog”，在输入框的下方列出了最常见的几个以 goog 开头的搜索短语。
[……]阅读全文
“ Top K 系统 ” 是非常常见的一种子系统，基本上，就是从全量巨大的统计数据中，筛选出数值最大的 K 个来并按序展示。这样的筛选可以是全时间内的，也可以是最近某一段时间内的；可以是全分类的，也可以是某个特定分类的。
具体来说，像 Twitter 的 Trending Topic，微博热搜，视频网站的点击排行，下载排行（可以是日榜、月榜、总榜）等等。这样的系统，在统计数据非常大（heavy hitters）的时候，其中的挑战性在于两个：
[……]阅读全文
今天记录 Feed 流系统的设计学习笔记，Feed 流常见系统包括 Twitter、微博、Instagram 和抖音等等，它们的特点是，每个用户都是内容创作者，每个用户也都是内容消费者，每个用户看到的内容都是不同的，它取决于用户所关注的用户列表，再结合时间线（有时还包括优先级）将这些用户的最新 feed 聚合，并以流的方式展示出来。
[……]阅读全文
在自己学习各种各样软件系统，特别是分布式系统的过程中，我做了一些笔记，有许多常见的、经典的系统，是非常值得学习和总结的。它们数量不算多，但具有典型意义，可能这样的系统也就十几个。
我在回顾这些笔记的时候发现，有时候一张简单的图，包含最核心的几个设计，就可以很大程度地帮助理解和记忆。所以我想把这些笔记和图解的结合通过文章的形式发出来，预计每篇文章都很短，基本上一张图，加上一点说明性的文字。
Disclaimer：这些都来自我自己的阅读和理解，肯定有着相当的改变和简化，因此它并不代表任何系统实际的样子。
今天是第一篇，即时消息系统，但是基本上好多即时通讯软件都属于这一类，比如微信
[……]阅读全文
