四火的唠叨

支付（Payment）系统可以很复杂，比如可以和银行打交道，和信用卡系统打交道。如果我们考虑用户在一家电商买东西，在结账的时候，借助电商支持的支付系统（Payment Service Provider）来完成支付行为。

支付系统需要结合商家（包含卖家和买家）一起来看。最典型的一种需求是，卖家在电商网站挂了东西卖，买家挑选了货物，结账并支付，电商依赖于支付系统来完成支付，并通知买家支付成功。

• 图中用两条虚线分隔出了 3 列，最左边是用户，中间是电商系统（比如 Amazon），右边是 Payment Service Provider（PSP，比如 PayPal）。支付操作需要保证幂等性，

[……]阅读全文

Key-value 存储系统大概是分布式存储系统中最常见的一种类型了。从功能需求的角度说，最核心的包括：

• 可以创建一张表和删除一张表，同时对于表的数据可以进行：
• 读，即 get(key) 返回 value
• 写，即 put(key, value)
• 删除，即 delete(key)

当然，也有一些其它的功能需求，比如支持事务性，支持 key 排序查询，range key 或者特定列索引，支持同一 key 下 value 的 version 等等。

从非功能需求的角度说，凡是存储系统，Durability 是最重要的，数据不能丢失；其次是 Availability；再次是 Performance，这样的系统需要考虑 thro

[……]阅读全文

典型的互联网应用的日志系统，从功能需求上看主要包括收集，存储和分析，以及展示这样三个部分，因此整个系统我觉得也可以按此思路大致可以分为三个部分：

1. 日志收集，从宿主机上采集业务应用的日志，发送给远端的日志系统；
2. 日志存储、分析和后期处理；
3. 日志查询和分析数据展示。

非功能需求方面，我觉得可以考虑这样几个要点：

• Durability：这是最重要的，尽可能不要丢失日志，到服务端的日志不要丢，在客户端的日志，也是如此，即便服务端不可用或连接断开，客户端的日志也要保存在本地。
• Availability：其次是可用性，要保证高可用。
• Performance：相较来说，日志系统的 performan

[……]阅读全文

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

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

• 图中上半部分是写的部分，无论是 API 直接调用还是

[……]阅读全文

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

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

• 挂单（可以是买单，也可以是卖单）
• 匹配（或者叫做撮合）
• 成交
• 清算

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

• Consistency，从单个交易的角度来说，主要就是事务性，这是交易系统最最基

[……]阅读全文

这篇是讲数据监控系统的，常见的包括 Datadog 和 Prometheus 等等。一个比较完整的数据监控系统要包括数据采集和数据展示两个部分。在此基础上，还可以具备告警和其它数据处理的功能。

对于监控的数据， 通常包括两类，一类是操作系统层面的数据，比如 CPU、内存、IO 等等；还有一类是应用相关的数据，这些数据就具备明确的业务意义了。

• 大体上，图中虚线表示控制流，而实现表示实际的统计数据流向。
• 用户通过 Web UI 来查看数据、定义规则，这些元信息存储在图中上方的元数据库中。
• Cluster Manager 和不同集群内的 cluster agent 通信，agent 通过心跳的方式和 mana

[……]阅读全文