题目

最后一道题的原文在这里。它要求我们实现一个支持 transaction, totally-available, read committed 的分布式 K/V 数据库。

第一个版本的思路

我的思路其实有点偷懒。因为这个挑战的框架提供了一些支持 linearizability 的中心化 KV 数据库（但是不支持 transaction），所以我就基于这个数据库实现了一个 WAL。每一次提交事务就只需要把事务里的所有写操作 append 到这个数据库里就行。对于读操作，我们可以通过 apply WAL 里面所有（可见的）写操作，来获取实际的数据。为了避免每次都 apply 全部的 WAL，每个 node 还会维护一个 snapshot。

这个版本已经可以在 QPS 比较低的情况下通过 part a 了。但是一旦 QPS 变高，最终的 WAL 会变得非常长，导致测试框架出问题。第二个版本解决了这个问题。

第二个版本的思路

既然问题是 WAL 太长，那我们定期把不需要的 WAL 清理掉不久好了。显然，如果一个 WAL entry 包含在所有 node 的 snapshot 中，我们就不再需要这个 entry 了。

为了判断 WAL entry 是否在所有 node 的 snapshot 中，在这个中心化数据库中我们为每一个 node 维护一个 watermark，watermark 之前的 entry 都已经包含在了这个 node 的 snapshot 中。通过计算这些 watermark 里面的最小值，我们可以知道哪些 WAL entry 可以被删除了。

分析

Transaction

为了保证事务的原子性，每个 WAL 的 entry 包含了一个事物所有的写操作。这样，当我们在内存里 apply 一个 WAL entry 的时候，就可以保证这个 entry 里面的所有写操作都会被 apply。这样，我们就可以保证事务的原子性。

Totally Availablility

这个系列的第二个挑战解释了什么是 totally available： 即使出现了网络问题（network partition），服务还是能正常工作。按照我的理解，这里说的网络问题是指 node 之间无法通讯，但是 node 还是可以访问框架提供的 KV 数据库。显然，因为上面描述的思路不需要 node 之间进行通讯，所以它是 totally available 的。

Read Committed

因为只要插入 WAL 我们就认为一个 transaction 已经 commit 了，所以我们只能读到 committed 的修改。

早上听了日谈公园之后，当天就在通勤地铁上把马伯庸的《长安的荔枝》看完了，真是有种酣畅淋漓的感觉（可能映射到了什么吧…）。然后晚上就下单了他的新书《大医 - 破晓篇》，这个周末应该就能看完，可惜下半部分《日出篇》不知道还要都能多久。

中心化交易所如何运作

首先，我们来想象一下，一场交易是如何达成的。比如说，A 想用 100 元价格买一袋大米。他把这个意愿告诉了想要卖大米的人。这个时候，如果有另一个人也愿意把自己的大米用 100 元卖出去，那么交易就可以成立了。为了让交易更加容易达成，我们需要创造一个平台，让想要买卖大米的人把他们能接受的价格广播出去。现实中就有这样的平台，比如咸鱼，淘宝等等。

买卖大米之类的物品，淘宝咸鱼就可以了。但是如果要买卖股票，加密货币这种类型的资产，我们就需要更加高效的方式。这主要是因为两个原因：

1. 同一种资产，在同一个时间点，每一份是同质的。比如都是比特币，对于交易者来说，只要价格一样，A 的和 B 的没有区别。
2. 这种类型的资产价格变化很快，不能再用这种人工的匹配方式。

为了解决这个问题，就有了现在常见的*中心化交易所 (Centralized Exchange or CEX)*。所有想要买卖某种资产的人把自己想要的价格发布到交易所，交易所自动把买卖双方按照价格匹配起来。比如下图在交易平台非常常见。绿色表示买方的出价，红色表示卖房的要价。红绿两遍是不会有重合的，因为一旦有重合，系统就会匹配买方卖方达成交易，从图上移除。

这种将买卖双发匹配起来的系统，也叫做 Market Maker。

如何提高 Liquidity

Liquidity 表示市场的流动性。具体来说，就是匹配买卖双方的难易程度。如果一个市场的 liquidity 很低，交易就很难达成。如果交易一直很难达成，交易者就不愿意来到这个市场交易，liquidity 就会更低。这样就成了一个负反馈。

因此，交易所会努力地提高自己的 liquidity。对于中心化交易所，它们增加 liquidity 的方式，就是依赖于职业交易者或者金融机构。这些人通过给出各种不同报价的方式与市场上的其他交易者交易，通过差价赚取收益，同时也增加了交易所的 liquidity。

Uniswap 如何运作

上面介绍了传统中心化交易所的简单原理，接下来我们来看看 Uniswap 是如何工作的。Uniswap 经历了三个版本。虽然每个版本相对于之前都有一些新特性，但是它的核心思路在 V1 就奠定了。接下来，我们先介绍一下去中性化交易所的基本逻辑，然后再着重介绍 Uniswap 的工作原理。

去中心化交易所的要素

去中心化交易所 (Decentralized Exchange or DEX) 和传统的中心化交易所不同，不存在一个 owner，任何人都可以进入进行交易。我感觉这也是它为什么会收到加密货币狂热者的拥护。然而作为一个交易所，它还是需要保证两部分功能：

1. Market Maker: 由于是去中心化的，我们不再有一个平台来做 market maker。DEX 需要实现某种 *Automated Market Maker (AMM)*。
2. Liquidity: 要让交易顺利进行，DEX 也需要保证有充足的 liquidity。

一般来说，DEX 会通过经济收益（一般是交易费用）来吸引人们将自己持有的资产 deposit 到 DEX 中作为 liquidity pool。AMM 让交易者可以和 liquidity pool 直接并且随时做交易。

Uniswap: x * y = k 模型

$x * y = k$ 模型可以说是 Uniswap 的核心逻辑，从 V1 就开始使用了。之后的版本也都基于这个模型。这个模型的逻辑很简单，就是要保证 liquidity pool 中两种资产的数量乘积是一个常数。我们接下来用 ETH 和 USDT 这两种币之间的交易作为例子。为了理解起来更容易，以下都假设没有交易费用。

首先，需要有人愿意把自己持有的 ETH 和 USDT 按照特定的比例存到 Uniswap 的 liquidity pool 中（这个特定的比例就是 liquidiy pool 中当前 ETH 和 USDT 的比例）。每一个存入资产到 liquidity pool 的人，都可以获得 liquidity token。拥有 token 的数量占总数的比重决定了这个人能获得百分之多少的交易费用。

一旦我们有了这个 liquidity pool，交易者就可以进行交易了。比如说现在 pool 中有 100 个 ETH 和 200K 个 USDT，两者数额的乘积是 20M。我想用把 1 ETH 换成 USDT，那么首先我的这个 ETH 会进入这个 pool 中。此时 pool 里就会有 101 个 ETH，为了满足乘积为常数的条件，USDT 的数额应该约等于 198019.8。那么原本 200K 个 USDT 多出来的那部分（1980.2 USDT）就会成为我买到的 USDT。

可以看到，ETH 和 USDT 的交易价格和 liquidity pool 中两种资产数额的比值有关。
$$Price = \frac{\Delta USDT}{\Delta ETH} = \frac{USDT}{ETH + \Delta ETH}$$

FAQ 1: 交易之后比例不是变了吗

确实，交易之后两种资产的数额比例发生了变化，价格当然也变了。就拿上面的例子来说，交易完之后，ETH 和 USDT 的比值变大了。这个时候如果有人再用 1 个 ETH 买 USDT，获得的 USDT 的数额就会变小。这个问题有个专门的词叫 slippage。

这个价格的“不正确”虽然是个问题，但是在实际交易中几乎不会出现。还是拿上面这个例子来说，在我交易完之后，虽然 ETH 买 USDT 亏了，但是反过来却可以用更少的 USDT 去买 ETH。 因此一定会人来套利，因此价格会一直不断的围绕着市价波动。

另外，如果 liquidity pool 很大，其实小额的交易对价格的影响也很小。

FAQ 2: 如果有人存入或者提取 liquidity，x * y 不就不是常数了吗

是的。$x * y$ 这个不变量在存入和提取 liquidity 的时候不需要保持不变。

FAQ 3: 为什么存入或提取 liquidity 要按照比例存入两种资产

这是因为我们要保证这两种操作不会影响资产的价格。

FAQ 4: 第一次存入 liquidity 怎么决定比例

Uniswap 使用了一种非常巧妙的方式。它不强求第一次存入的比例，只是定义了第一次存入能获得的 liquidity token 是两种资产数额乘积的根号值。这样，如果存入者想要用最少的资金获得最多的 token，就需要按照市价对应的比例存入，我们来简单证明一下。比如说 1 个 ETH 值 400 USDT，那么为了获得 20 个 token，需要存入 $x(ETH) + \frac{400}{x}(USDT)$。把 ETH 代换成 400 USDT 就可以得到，为了获得 20 个 token，需要付出等价于 $400x + \frac{400}{x}$ USDT 的资产。显然当 $x = 1$ 时，这个值最小。也就是说，liquidity provider 会收到利益的驱使，用合适的比例存入。

当然，如果有人非要瞎鸡儿存，也会有套利的人让这个比例恢复正确。

总结

Uniswap 的基本原理大概就是这样。一个简单的公式，再加上一点基本的博弈论，就能构建出一个非常实用的交易所。不过吧，我还是很难理解为什么不使用中心化交易所来兑换。在写这篇博客的时候，Uniswap 的平均 gas 数量大约是 140K，一个 gas 算 90 Gwei 的话，一次 swap 单是 gas fee 就要 0.013 ETH。即使在币圈大跌的今天，也要 30 多美金。这还没有算上千分之三的 fee。如果从自己的钱包转到交易所，兑换之后再转回来，总共费用可能也就几美金。这么对比下来，还是 CEX 真香警告吧？你觉得呢？

递归函数不是很好实现吗

在很多编程语言中，递归函数很好实现。比如大家喜闻乐见的 Java，要用递归的方式实现阶乘可以写成这样：

1
2
3

int fact(int n) {
  return n == 0 ? 1 : n * fact(n - 1);
}

然而，在 lambda 演算中，所有的函数都是匿名函数。因此，我们没有办法在函数fact中调用它自己。当然，我们可以通过对函数本身做一些改动来实现递归。但是这个改动可能并不那么通用，可读性也会受到影响。而 Y 组合子，则提供了一种通用的方法，可以让一个按照某种(容易 follow 的)规则实现的函数递归起来。

再一次发现 Y 组合子

Y 组合子的定义如下：

$$\lambda f.(\lambda x. f \space (x \space x)) (\lambda x. f \space (x \space x))$$

如果你把它 apply 到一个函数 g 上，你会发现 $$ (Y g) = (g \space (Y g)) $$

这也就意味着它实现了递归。只看它的定义，你可能很难理解为什么它可以做到这一点，以及发现它的人脑洞得有多大。我们今天就来一步一步的，再一次发现 Y 组合子。

把自己当作函数的参数

我们不是没法在自己的函数体内引用自己吗？那我们就把自己当作参数传进去。我们还是用阶乘举例子。首先我们用不正规的 lambda 演算定义 $f$：$$ \lambda n. n = 0\space?\space1 : n * (f \space n) $$。之所以说不正规，除了语法之外，主要是因为 $f$ 的函数体内引用了 $f$。

现在，我们给 $f$ 加一个参数的到 $f’$：

$$ f’ = \lambda s. \lambda n. n = 0\space?\space1 : n * ((s \space s) \space n)$$

这样 $ (f’ \space f’) $ 就等价于原本的 $f$ 了。

把实际的逻辑提取出来

现在，我们实现了递归。但是这种方式不够直观。我们在实际递归调用的时候，需要用 $(s \space s)$ 这种略显奇怪的形式。现在我们先做一件事，把实际的逻辑提取出来。

$$ f’ = \lambda s. \lambda n. ((\lambda g. \lambda m. m = 0\space?\space1 : m * (g \space m)) \space (s \space s)) \space n) $$

这个改动的核心在于把实际的逻辑抽出来了。有了上面这种形式，我们再把实际逻辑当作参数（我们姑且用 $fr$ 表示上面新加的 $\lambda g. \lambda m. m = 0\space?\space1 : m * (g \space m)$ ），就可以得到：

$$ f’’ = \lambda h. \lambda s. \lambda n. ((h \space (s \space s)) \space n) = \lambda h. \lambda s. h \space (s \space s)$$

$$ f’ = (f’’ fr) $$

因为 $(f’ \space f’) = f$，所以我们得到：

$$ ((f’’ \space fr) (f’’ \space fr)) = f $$

此时 $f’’$ 和我们想实现的阶乘已经是独立的了，等式左边只有 $fr$ 和阶乘有关。我们再把 $fr$ 当作参数抽取出来，等式左边就变成了：

$$ \lambda g. ((f’’ g) (f’’ g)) = \lambda g. (\lambda s. g \space (s \space s)) (\lambda s. g \space (s \space s)) = Y $$

有了这个万能的 Y 之后，我们定义阶乘的方式就变成了上面提到的 $fr$，也就是：

$$ \lambda g. \lambda m. m = 0\space?\space1 : m * (g \space m) $$

我相信任何能用 Java 实现阶乘的人，都可以轻松地写出并理解上面的代码。

什么是 Continuation

简单来说，某个位置的 continuation 可以理解成在这个位置要做的运算。比如在 (+ 1 2) 这个例子里，不严谨地说，对于 2 来说，它所处的 continuation 就是把它和 1 相加。如果我们有办法把这个 continuation 抽取并保存下来，我们就可以把它运用(apply)到其他值上来执行相同的运算。

如何获取 Continuation

那么现在问题来了，我们要怎么获得一个位置的 continuation 呢？接下来的这几句话有点绕，我们一句句看。

• Scheme 本身提供了 call/cc 函数。它接受一个函数作为参数。我们姑且叫这个函数为 cc-consumer。cc 是 current continuation 的缩写。
• 这个函数 cc-consumer 就和它的名字一样，也接受一个参数，这个参数就是当前的 continuation，也就是 cc。
• cc 就像上面说的，可以被理解成某个位置接下来要做的运算。这也意味着，cc 也是一个函数，它接受一个参数作为这个位置上的值。它一旦被调用，就会回到它对应的位置，并且把它的参数放在这个位置，然后进行接下来的操作。

说了这么多，其实也很难有个直观的了解。让我们用伪代码来描述一下这些函数和参数的类型。

1
2
3
4
5

T call/cc(ContinuationConsumer cc_consumer);

using ContinuationConsumer = function<T(Continuation)>;

using Continuation = function<void(T)>;

接下来，我们来看一个简单的例子。这个例子使用了 call/cc 来实现最开始我们提到的 add1 这个操作。你可以使用 Chez Scheme 来执行下面的代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

(define add1 #f)

(+
  1
  (call/cc
    (lambda (cc)
            (set! add1 cc)
            0
    )
  )
)

(add1 10) ; => 11
(add1 20) ; => 21

• 在上面代码的第四行，我们通过调用 call/cc 来获取当前的 continuation。
• call/cc 接受一个用户自定义的函数作为参数，并且会把当前的 continuation 传给这个函数作为它的参数。简单来说，call/cc 接受一个回调函数，并把 continuation 传给回调函数。
• 在回调函数中，我们把 continuation 保存到了 add1 这个变量中，之后我们就可以使用它来访问这个 continuation。

在上面代码的最后两行，我们通过 add1 来使用保存下来的 continuation。当我们使用它的时候，程序会把传给它的参数，放到 call/cc 对应的位置上然后继续执行。显然，(add1 10) 就会执行 (+ 1 10) => 11。

为什么需要 Continuation

我们废了半天劲理解了 continuation 是什么（甚至可能没有理解…)，但是问题来了。为什么我们需要它呢？continuation 可以帮我们做很多事，比如提前返回。提前返回听上去好像很普通（比如 Java 里一个 return 就好了），但是 Lisp 其实没有很简单的办法。有了 continuation，我们就可以实现这一点。

1
2
3
4
5
6
7
8
9
10

(define (find lst elem)
  (call/cc (lambda (return)
    (for-each
      (lambda (e)
              (if (eq? elem e)
                  (return 'found)
                  'nil))
      lst)
    (return 'not-found)
    )))

因为 call/cc 的调用在最外层，所以这个位置的 continuation 就是什么也不做，直接返回。而这个 continuation 被传递给参数 return，这样当我们想返回时，调用 return 即可。

更复杂的例子: Generator

上面的例子比较简单，我们来看一个比较复杂的例子，generator。我们想实现一个函数，每次调用它都会依次返回给定 list 中的元素。这样的函数其实也可以通过闭包来实现，但是我们今天试试用 call/cc 来实现它。

第一次尝试

1
2
3
4
5
6
7
8
9
10
11

(define (new-generator lst)
  (define (cc-consumer return)
    (for-each
      (lambda (e)
        (return e))
      lst))
  (define (generator)
    (call/cc cc-consumer))
  generator)

(define generator (new-generator '(1 2 3)))

先别急着说”第一次尝试”就这么复杂。上面大部分的代码其实都是模版代码。

先看第一行，因为我们想要实现一个可以根据指定 list 创建 generator 的函数，所以很自然的，我们定义一个接受 lst 作为参数的 new-generator。这个函数应该返回一个 generator，也是一个函数。所以在 7～9 行，我们定义一个函数，并且返回它。

然后我们再看第8行。显然今天的主角是 call/cc，所以我们这里怎么也得用一下它对吧。我们定义了 cc-consumer 这个函数作为 call/cc 的参数。

最后我们看第一个版本的核心部分，第2～6行。在 cc-consumer 中，我们遍历了传入的 lst，每次都调用 return 返回每个元素。

显然这次尝试是失败的。每次调用 generator 都只会返回列表中的第一个元素。这是因为我们目前只通过 continuation 实现了提前返回的功能。我们还需要实现在上一次返回的位置接着执行下去。

第二次尝试

1
2
3
4
5
6
7
8
9
10
11
12
13

(define (new-generator lst)
 (define (cc-consumer return)
  (for-each
   (lambda (e)
    (call/cc (lambda (resume)             ; new
              (set! cc-consumer resume)   ; new
              (return e))))               ; new
   lst))
 (define (generator)
  (call/cc cc-consumer))
 generator)

(define generator (new-generator '(1 2 3)))

第二次尝试，我们改动了三行。因为我们想让每次调用 generator 都会回到上次返回的地方，因为我们希望能够把上次返回的位置的 continuation 保存下来。因此，我们把原本第一个版本调用 return 的地方，改成了调用 call/cc。然后在第6行，我们把这个位置的 continuation 赋值给 cc-consumer。这样，当我们再次调用 generator 的时候，我们会回到第6行，然后执行下一次循环。

用这个版本，我们的 generator 运行的很好。每次调用都正确的返回了下一个元素。但是这个版本其实有一个严重的 bug。为了暴露出这个 bug，我们现在换一下需求，不再直接返回元素，而是做一些改动。如果是第奇数个元素，就直接返回；否则就返回它的相反数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

(define (new-generator lst)
 (define (cc-consumer return)
  (for-each
   (lambda (e)
    (call/cc (lambda (resume)
              (set! cc-consumer resume)
              (return e))))
   lst))

 (let ((index 0))
  (define (generator)
       (set! index (+ index 1))
       (if (eq? (mod times 2) 0)
           (- 0 (call/cc control-state))
           (call/cc control-state)))
  generator))

上面的版本尝试实现新的需求。它的主要改动在于我们维护一个 index 来判断当前是第几个元素，然后决定是否取反。这个改动的目的主要是要构造出两个不同的 continuation，也就是第14和15行。我们通过多次调用 generator 发现，每次都返回了元素本身，不管它是第几个元素。之所以这样，就是因为 cc-consumer 的参数 return 没有被更新过，永远都是用第一次调用 cc-consumer 时的 continuation，也就是不取反的情况。

最后的版本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

(define (new-generator lst)
 (define (cc-consumer return)
  (for-each
   (lambda (e)
    (set! return                                 ; new
          (call/cc (lambda (resume)
                     (set! cc-consumer resume)
                     (return e))))
    )                                            ; new
   lst))

 (let ((index 0))
  (define (generator)
       (set! index (+ index 1))
       (if (eq? (mod times 2) 0)
           (- 0 (call/cc control-state))
           (call/cc control-state)))
  generator))

为了解决上面发现的问题，我们需要更新 return 的值。

当我们第一次调用 generator 的时候，因为 index 是 1，所以第 17 行会被执行，这是，return 的值会是第 17 行对应的 continuation。当这次调用完成之后，cc-consumer 已经被更新成 resume 了，也就是第6行对应的 continuation。这时 return 还没有更新，我们又回到第 17 行，然后 generator 返回，第一次执行结束。

当我们再一次调用 generator 的时候，我们会触发第16行的 call/cc，而这次的参数是更新后的 cc-consumer，也就是 resume。这次调用会让我们回到第6行。这时，第6行的返回值，也就是第16行的 continuation。它会被赋值给 return。赋值完之后，我们开始第二次循环，这次，我们会返回第二个元素。注意，因为 return 是第16行的 continuation，我们会正确地执行取反的操作。

总结

我个人觉得 continuation 很绕，很难解释地清楚。很多的文章都直接把一个完成的例子抛出来，就算读者理解了这么写能够 work，但是还是不知道为什么要这么写。我把 generator 这个例子拆成了三个阶段，来解释每一部分的代码写成那样的原因，希望能够为你理解 continuation 做一点微小的贡献。

runtime 的初始化

说实话我感觉 dapr 的核心逻辑并不是特别复杂。初始化 runtime 无非就是读取 components 配置，然后根据配置初始化所有的组件。通过阅读 pkg/runtime/runtime.go 的 Run 函数，就可以验证我们的想法。Run 和 initRuntime 的主干如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

func (a *DaprRuntime) Run(opts ...Option) error {
    // 创建 options
    var o runtimeOpts
    for _, opt := range opts {
        opt(&o)
    }

    // 初始化 runtime
    err := a.initRuntime(&o)
}

func (a *DaprRuntime) initRuntime(opts *runtimeOpts) error {
    // 注册支持的各种类型的 component
    a.xxxRegistry.Register(opts.xxx...)

    // 读取 components 配置，加载 components
    // go routine 负责不断地处理 pendingComponents 这个 channel 中的数据
    go a.processComponents()
    // loadComponents 则是读取 opts 中指定的配置文件，将要加载的 component 
    // 写入 pendingComponents
err = a.loadComponents(opts)

    // 启动 http 和 grpc server
    a.startGRPCAPIServer(...)
    a.startHTTPServer(...)

    // 到这里 dapr 自己需要做的初始化工作都已经完成了，
    // 接下来是和实际的应用程序做初始化。

    // 等应用程序 ready，通过不断和 app 建立 tcp 连接实现
    a.blockUntilAppIsReady()

    // 和应用程序建立连接
    a.createAppChannel()

    // 启动 actor
    a.initActors()

    // 开始 subscribing，开始从 binding reading
    a.startSubscribing()
a.startReadingFromBindings()
}

Registry - 工厂集合

Registry 为 component 提供了各种实现类型的注册。每一种 component 的每一个实现，都需要提供工厂方法。daprd 在创建 runtime 的时候，会将所有支持的 component 实现都以参数的形式传入。在上面描述的 initRuntime 方法中，又会把这些传入的实现注册到 registry 中。在我们处理 component 的时候，会根据配置中指定的类型，寻找对应的工厂方法并加以调用。下面，我们用 state store 为例子，看看具体的调用链路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// 在 initRuntime 中被调用，处理 pendingComponents 
// 中待处理的 component 配置。
processComponents() {
    // -> processComponentAndDependents() 
    // -> doProcessOneComponent()
    switch category {
    case stateComponent:
        return a.initState(comp)
    // 其他类型
    }
    return nil
}

initState() {
    // 调用 registry 的 create 方法。
    // 它的实现就是从内存中维护的 map 中获取对应的工厂方法，然后调用它
    store, err := a.stateStoreRegistry.Create(s.Spec.Type, s.Spec.Version) {
       if method, ok := s.stateStores[name]; ok {
return method(), nil
   } 
    }

    // 用 component 配置中的参数初始化
    store.Init(...)
}

Subscribing - 屏蔽消息实现

在 initRuntime 的最后，它调用了 startSubscribing 和 startReadingFromBindings。这两个我个人觉得有点类似。binding 更多的是为了建立和外部（i.e. 不被 dapr 所管理）服务通讯通道，例如读或者写一个外部部署的 Kafka。如果这个 Kafka 已经包含在了 component 配置中，我们则应该使用 subscribing。

startSubscribing 主要做的事情就是遍历所有注册了的 pubsub，对于每一个订阅的 topic，就启动一个 go routine。这个 go routine 会不断地将收到的消息通过 RPC 调用，转发给应用程序。应用程序只需要提供一个回调接口即可。这样设计的一个好处就是，应用程序完全不需要考虑底层的实现到底是 pull 还是 push 模式，dapr 会自动使用对应的模式获取消息进行转发。

总结

runtime 的结构非常简单。它的主要职责就是根据配置来创建各种 component，从而构建完整的运行时环境。

目录结构

Dapr 的代码包含了几个主要的顶层目录：

1. cmd: 包含了几个主要的可执行程序。
2. dapr: 包含了 dapr 使用到的 protobuf 的定义。这些 protobuf 主要是用于 RPC 使用的数据结构定义。
3. pkg: 包含了 dapr 的核心代码。

cmd - 可执行程序

Dapr 包含了若干个可执行程序，它们的代码在 cmd 这个路径下。其中最重要的就是下面 daprd。它就是 dapr 提供的运行时环境，也就是实际的 sidecar。

除此之外，还有以下几个不是特别核心的：

1. placement：用于在“放置” actor，比如在适合的 pod 上运行 actor。
2. injector 和 operator：这是 dapr 在 K8s 环境中部署是使用的。
3. sentry：TLS 的 CA。dapr 的 sidecar 之间的 TLS 通讯会使用到它。

daprd v.s. dapr

在看 dapr 文档的时候，相信大家也都使用了 dapr 这个命令行工具。要注意它和 daprd 是有区别的，并且它的代码在单独的 repo 中。
daprd 是实际的运行时环境。而 dapr 类似一个 devops 工具。在我们执行 dapr run ... 的时候，它会同时执行 daprd 和我们指定的应用程序。

pkg - 核心代码

这个目录包含了 dapr 的核心代码。其中 runtime 是核心中的核心。其他目录则包含了 dapr 的各个组件的代码。

总结

Dapr 的代码结构还是比较清晰的。之后我会从 runtime 开始，研究一下 dapr 大概的实现原理。

Dapr 是什么

Dapr (Distributed Application Runtime) 是一个运行时环境，以 sidecar 的形式和实际的应用程序一起执行。它让开发者可以专注于业务逻辑的开发。而分布式服务的其他常用组件（状态存储，pub/sub）则包含在运行时中，并且可以通过配置文件来一定的个性化。

Dapr 的核心思想

想象一个普通的服务。它为了实现业务逻辑，经常会依赖

1. 数据库
2. 消息队列

有经验的开发人员往往会通过封装的方式，根据核心业务来定义接口以隐藏实际的依赖选择（比如数据库选用了 MySQL，消息队列选用 Kafka）。业务逻辑在进程中调用这些接口，来实际使用这些依赖。

Dapr 进一步地推广了这个思路。Dapr 也对这些常见依赖进行抽象，只不过使用了 RPC 的方式，让不同的语言和进程都可以使用。我这样描述可能不够清晰，但是下面这张图一定能让你明白。

抽象

为了帮助业务开发，Dapr 提供了很多种抽象，包括以下几种：

1. statestore：用于持久化，提供了键值存储的抽象，支持常见的数据库，redis，等等。我不确定 dapr 怎么对复杂的查询进行支持。
2. pub/sub：提供了 publishing 和 subscribing events 的抽象，支持 Kafka，RocketMQ 等等。
3. binding：提供了对外部系统相应的抽象。比如一个 input binding 可以隐藏 subscribe kafka 这一细节，开发者只需要实现一个 API 来处理 input。Dapr 会负责调用这个 API。

服务调用

除了以上一种抽象，在分布式应用这种特定场景下，多个服务之间往往会有互相调用。随着这种互相调用越来越复杂，流量越来越大，我们往往需要服务发现，负载均衡等等。为此 Dapr 要求服务间的互相调用也需要通过 sidecar 提供的 API 执行。sidecar 根据请求数据，将其转发到对应的服务进程。

可观察性

由于服务之间的调用都需要通过 sidecar，所以实现可观察性非常自然，比如分布式 trace，接口调用监控等等。

总结

Dapr 的思想并不复杂，甚至让我觉得非常自然。它看上去似乎确实能够让业务开发简单很多，但是有一点我不太确定。虽然 dapr 对各种底层组件做了抽象，在应用中我们是不是也应该将 dapr 提供的抽象视作实现细节，比如将 dapr 提供的接口和 mysql 一视同仁。否则业务和底层细节就有了耦合。

按照目前我的理解，我感觉我们的业务逻辑还是应该和 dapr 隔离开，不要让 dapr 侵入到我们的代码中。在下一篇博客里（如果有的话），我可以试着用一个具体的例子来说明我的想法。

1. 内核态地址空间结构
2. 物理内存页的分配
3. 虚拟地址映射

这里声明一下，以下的内容都是基于 Linux 2.6 在 80x86 架构上的实现。

内核态地址空间结构

大家都知道，操作系统本身的目的，是为了给上层的应用提供各种资源的抽象。对于内存，操作系统使用了虚拟地址来为各个应用提供了安全易用的使用接口。而内核态地址空间，是一个进程只有在内核态时才可以使用的虚拟地址空间。Linux 把大于等于 0xC0000000 (3GB) 的这一片虚拟地址空间分配给了内核态。这一片空间中的每一部分，不是生来平等的，而是分成了几个部分，每一个部分都用不同的用途。这些部分按照虚拟地址从小到大排序依次是：

1. 3GB ~ 3GB + 896M (high_memory): 这一部分的虚拟地址是直接映射到了 0~896M 这一片物理内存。这个映射是固定不变的（虚拟地址减去 3G 就是物理地址）。这部分包含了 _DMA_（可以用于 direct memory access） 和 _normal_。这之后的部分在 Linux 中被称为 _high memory_。
2. high_memory ~ VMALLOC_START: 这一部分是留空的，用来保证内存访问安全。如果有代码一不小心访问了这部分内存，会被捕捉到。
3. VMALLOC_START ~ VMALLOC_END: 这一部分是 _vmalloc area_，主要用来映射非连续内存。
4. VMALLOC_END ~ PKMAP_BASE: 这一部分也是留空，用来保证访问安全的。
5. PKMAP_BASE ~ FIXADDR_START: 这一部分是用于永久映射的，详细的讨论见下文。
6. FIXADDR_START ~ 4GB: 这一部分是用于固定映射的。固定映射是为了一些指定的用途建立的到物理内存的映射，比如 APIC（高级可编程中断控制器）。

内存分配的一般流程

不管内核怎么为自己分配内存，都依赖于实际的物理内存页的分配。除此之外，内核还需要分配内存来存放这个分配的描述符，以及创建从虚拟地址到新的物理内存的映射。所以，一般的流程如下：

• 为元数据分配内存 (注意，这一步也是一个内存分配的过程)
• 实际的物理内存分配
• 更新分配的元数据
• 分配虚拟地址空间，更新页表

这上面 4 个步骤的顺序，在不同的情况下会有一些不同，并且在某些情况下，只需要某几个步骤。但是大体的思路是这样的。接下来我们来看看其中重要步骤的实现。

物理内存页的分配

内核将物理内存抽象为 _page frame_（页框）。每一个分配获得的 page frame 都对应到了一个页描述符（struct page）。这些页描述符都保存在了 mem_map 这个数组中。

分配物理页框的入口函数是 alloc_pages，它也有一些变种，比如 __get_free_pages。这里要注意的一点是，alloc_pages 返回的物理页框，都是连续的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// gfp 是 get free page 的缩写。
// gfp_mask 是分配内存时需要的一些参数，下面再详细解释
// order: 表示需要 2**order 个 page frame。
page* alloc_pages(unsigned int gfp_mask, unsigned int order) {
  // alloc_pages_node -> __alloc_pages
}

page* alloc_pages(unsigned int gfp_mask) { return alloc_pages(gfp_masks, 0); }

// __get_free_pages 的主要区别是它的返回值是虚拟地址
unsigned long __get_free_pages(unsigned int gfp_mask, unsigned int order) {
  return page_address(alloc_pages(gfp_mask, order));
}

unsigned long __get_free_pages(unsigned int gfp_mask) {
  return __get_free_pages(gfp_mask, 0);
}

接下来我们具体看看 __alloc_pages 的实现。

Zoned Page Frame Allocator

__alloc_pages 的实现被称为 zoned page frame allocator (以下简称 zoned allocator)。它的特点是将物理内存分为若干个 zone，对应的数据结构是 struct zone。它在分配内存的时候，会根据参数（gfpmask）从合适的 zone 中去分配内存。在 Linux 2.6 中，内核将物理内存分为了三部分：DMA，normal 和 high memory。这三个部分恰好就对应了内核态地址空间的分配。DMA 和 normal 对应了 3GB 到 3GB + 876M 这一段的虚拟地址。

当 zoned allocator 找到一个合适的区可以分配内存的时候，它会使用 buddy system 算法，来从这个 zone 所对应的物理内存中挑选出合适的部分。

Buddy System

Buddy system 需要解决的问题是 external fragmentation。回忆一下，上面的 alloc_pages 返回的是连续的物理页框。如果我们在处理内存分配请求的时候过于随意，就会导致有很多零碎的物理页框。这些页框可能分散各处，即使总量很多，也没法满足连续的物理内存的需求。

Buddy system 解决这个问题的方式，就是将连续的物理内存分类。对于每个内存分配请求，我们根据请求的大小寻找合适的分类进行分配。具体来说，Buddy system 将连续内存按照 2 的幂分成若干个列表。比如，第一个列表包含了若干个长度为 1 个页框的连续物理页，第二个则包含了若干长度为 2 个页框的连续物理页。当我们收到一个需要 4 个页框的内存分配请求时，我们从 4 对应的列表开始搜索，一旦找到一个非空列表，就从列表中取一个元素。如果这个列表中的元素对应的物理内存空间比请求的大小大，我们会把这段空间拆分成多个 2 个幂。比如，如果我们使用长度为 16 的列表来满足大小为 4 的请求，我们会把 16 拆成 8 + 4 + 4。出去需要被分配的 4 之外，其他长度为 8 和 4 的物理内存，会插入到对应的列表中，满足之后的内存分配。当我们释放内存的时候，我们也会使用类似的算法，把相邻的物理内存合并。

Buddy system 的入口函数是 [__rmqueue(struct zone *zone, unsigned int order)]，它会从 zone->free_area 这个数组的第 order 个元素开始，需要合适的内存块。

物理内存的分配

上面介绍了部分，是以物理页框为内存分配的单位。然而，在实际的使用中，我们往往不会直接时候一个页框。相反，我们往往是根据我们需要的数据结构，来申请内存。为了处理这种请求，Linux 内核实现了 Slab Allocator。

Slab Allocator 使用了两种抽象：Cache 和 Slab。一个 Cache（struct kmem_cache_t） 用来处理固定大小的内存分配请求，它包含了多个 Slab（struct slab），每个 Slab 对应到了若干个连续的物理页框，是实际的物理内存来源。

Slab Allocator 是基于 zoned allocator 实现的，它的入口函数是 kmem_cache_alloc，简单的伪代码实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// kmem_cache_t 指明的对应的 cache。
// 这里不需要指定大小，因为每个 cache 能分配的大小是固定的。
void* kmem_cache_alloc(kmem_cache_t *cachep, int flags) {
  // 这里的 ac 是 cache 中每个 cpu 对应的本地缓存，目的是为了减少 contention
  // 分配的时候只会从 array_cache 中取第一个空闲的。
  //
  // cache_alloc_refill 做的事情是把 cache 拥有的 slab 中的内存放到 array_cache 中。
  struct array_cache *ac = cachep->array[smp_processor_id()];
  if (ac->avail) {
    return ((void**)(ac + 1)[--ac->avail]);
  } else {
    return cache_alloc_refill(cachep, flags);
  }
}

// 这个方法是为了 cache 分配 slab。
// 它会调用 alloc_pages，也就是 zoned allocator。
int cache_grow(kmem_cache_t * cachep, int flags, int nodeid) {
  // kmem_getpages -> alloc_pages
}

虚拟地址映射

内存分配的另一个重要部分，就是建立虚拟地址的映射。只有有了映射，内核代码才可以访问内存。对于不同的内存，建立映射的方式也不尽相同。具体分为以下几类：

1. 非 high memory 的虚拟地址映射到的物理内存就是 0~896M。这个映射在初始化页表的时候，已经配置好了，不需要再额外配置。
2. 对于 high memory 的虚拟地址部分，它的映射分为三种：
   1. 永久内核映射，它将 PKMAP_BASE ~ FIXADDR_START 的虚拟地址映射到物理内存。它的入口函数是 kmap。
   2. 临时内核映射，它将固定映射中的 FIX_KMAP_BEGIN 到 FIX_KMAP_END 这部分映射到物理内存。它的入口函数是 kmap_atomic。
   3. 非连续内存管理，它将 VMALLOC_START ~ VMALLOC_END 的虚拟地址映射到物理内存。它的入口函数是 map_vm_area。

这三种映射方式有不同的特性，所以会使用在不同的场景。

永久内核映射

永久内核映射之所以被称为永久，是因为，除非有明确的 release，否则这个映射一直存在。由于这部分的虚拟地址空间是有限的，所以建立这种类型的映射可能会 block，也就意味着它不能在中断处理函数中使用。

临时内核映射

临时内核映射的特点是它本身没有修改的保护，需要内核代码编写者自己保证不会有不同的内核控制路径同时使用一个虚拟地址映射到不同的物理内存。这也是为什么它不会阻塞的原因。

非连续内存管理

非连续内存管理比较特殊，它在处理打断内存分配请求的时候，不会分配连续的物理页。Linux 在实现它的时候，将 VMALLOC_START ~ VMALLOC_END 这段虚拟地址分成了若干个非连续内存区（描述符的数据结构是 struct vm_struct）。每一个内存分配都会生成一个 vm_struct，它的入口函数是 vmalloc。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

void* vmalloc(unsigned long size) {
  // 分配一个空闲的 vm area。
  struct vm_struct *area = get_vm_area(size, VM_ALLOC>);

  // 分配页描述符需要的内存
  // kmalloc 底层调用的是 slab allocator
  area->pages = kmalloc(array_size, GFP_KERNEL);

  // 分配若干个物理页
  // 注意这里多次调用 alloc_page，分配的就是多个彼此不连续的物理页
  for (int i = 0; i < area->nr_pages; i ++) {
    area->pages[i] = alloc_page(...);
  }

  // 建立虚拟地址映射
  // 它会更新页表
  map_vm_area(area, area->pages);
  return area->addr;
}

这个函数的实现，恰好就对应了 内存分配的一般流程 的几个步骤。

总结

Linux 内核的内存管理的实现，实际上有明确的分层。最上层是 vmalloc，它依赖于 slab allocator。slab allocator 又依赖于 zoned allocator。而 zoned allocator 又依赖于 buddy system。在物理内存分配之外，虚拟地址的映射又分成了一种形式。从这个角度来看，内核的内存管理似乎就更清晰了。

1. 增加了标签展示
2. 增加了目录展示
3. 增加了评论功能

这篇博客主要记录一下如何实现和一点心得。

主题的原型 Apollo

这个主题的前身是 apollo 主题。我特别喜欢它的简介，以及模仿 Vue 官方网站的样式，所以这个博客最开始的版本就直接使用了这个主题（只有一些非常简单的修改）。

在那个时候，我对 Hexo 也并没有什么了解，只是单纯的照着教程使用而已，没有办法对主题本身做比较明显的改动。

糙快猛地学习 Hexo

最近相对整个 blog 做些读者体验方面的改进。主要的动因是我的同事在搜索 Spanner 的文章的时候搜到了我的博客。一旦有了实实在在的读者，我的整个心态就有点飘了，准备添加一下之前我就觉得缺少的特性：标签和目录。为此，我就迅速地读了一下 Hexo 的文档。

Hexo 的文档说实话有点太简单了，而且样例代码都是基于 ejs 的。因为 apollo 本身是用 jade 实现的，而我又没有用过，所以还是遇到了一些麻烦，不过最后都通过看 Hexo 以及别的主题的代码搞定了。下面就讲讲两个更新的实现方式。

标签展示

展示标签其实挺简单的。Hexo 提供了 list_tags 这个函数，并且提供了一定的自定义空间，所以非常简单。

1
2
3
4
5
6
7

// 因为我只想在文章页展示，所以判断了一下现在的位置是否是 post
if is_post()
    // 在每个 tag 前面加一个 #
    - var transform = function(str) { return '#' + str; }
    - var config = {class: 'post-tag', show_count: false, style: false, separator: ' ', transform: transform}
    .post-tags
        != list_tags(item.tags, config)

这里我遇到的一个问题就是，我不知道 pug 怎么直接在 object 里面使用 lambda，只好把代码拆成了几行。不过这样可读性似乎也好一点。

目录功能

添加目录比较简单，Hexo 也提供了 toc 这个函数。然而，为了达到现在的效果，着实花了我一点时间。当然，对于有前端经验的朋友们来说，应该比较简单，我就不赘述了。这里我主要想说说怎么实现滚动的时候，目录会高亮当前展示的部分对应的目录项。

网上有挺多实现方式的，我挑选了 Bootstrap。Bootstrap 提供了 scrollspy 的功能，虽然有文档，但是文档中有几个属性的名字写错了，也花了我一点时间。下面是实现的几个主要部分：

1
2
3
4
5
6
7
8
9
10
11
12
13

// 为 body 加上以下几个属性。
// data-bs-target 的值必须是目录元素的 id
body.container(data-bs-spy="scroll" data-bs-target="#toc-nav" data-bs-offset=0)
  // ...

// 这是目录的定义。注意它的 class 必须是 navbar。
nav#toc-nav.navbar
  // 这里的 class 必须是 nav。
  != toc(item.content, { list_number: false, class: 'nav' })

// 也别忘了 include bootstrap 的 js 文件。
// 也可以自己 host。
script(src="//cdn.jsdelivr.net/npm/bootstrap@5.0.0-beta1/dist/js/bootstrap.min.js")

中文的支持

如果你的 blog 和我一样，也是使用中文，那么只有上面的代码，是没法实现自动高亮的。这个问题的原因是 toc 是实现在指定链接的时候，会调用 encodeURL。然而，Bootstrap 会假设这个链接和文章中每个段落标题的 id 是相同的。这个 id 是由 hexo-renderer-marked 解析 markdown 生成 html 的时候自动生成的，默认就是这个段落的标题。所以，如果你使用的英文作为标题，encodeURL 之后可能还是一样的，Bootstrap 就能关联起来。

为了解决这个问题，我看了一下 hexo-renderer-marked 的文档，发现它支持自定义每个段落的 id。你需要在 _config.yml 中先启用 anchorAlias：

1
2
3

marked:
  headerIds: true
  anchorAlias: true

然后在 Markdown 中，将原本的 # header 改成 # [header](#header-id)。这样就能解决这个问题了。

评论功能

评论功能的实现就很容易了，apollo 本身就支持。如果使用 disqus 的话，只要先去 disqus 上注册一个网站，然后把注册的网站名写进配置就可以了。

首先，我们先来试试分解这个问题。

1. 数据结构: 我们需要设计一个数据结构来维护所有的任务，它需要支持快速的插入操作，和获取到期任务的操作。
2. 任务执行：我们需要一个高效的手段，在到了指定的时间之后，执行已经到期的任务。

接下来，会尝试从这两个方面来分析 Linux 的实现。Linux 提供了多种执行定时任务的方式，我们这里主要来分析一下 timer_list。

数据结构

在 Linux 代码中，每一个定时任务都对应到一个 timer_list。下面是这个数据结构的定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

struct timer_list {
    // 侵入式的双向链表，Linux 代码中很常见
struct list_head entry;

    // 什么时候到期，单位是 tick。
    // tick 可以理解成 CPU 的时钟周期。到底多久不影响理解。
unsigned long expires;

spinlock_t lock;
unsigned long magic;

    // 到期之后要执行的函数
void (*function)(unsigned long);
    // 函数的参数
unsigned long data;

struct tvec_t_base_s *base;
};

相信这个数据结构的定义，大家并不会觉得有什么惊讶的部分（除了这个名字…）。我们接下来看 Linux 怎么组织这些定时任务。

Linux 使用了 tvec_t_base_s 来维护（每个 CPU 对应的）所有的定时任务。它的定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

struct tvec_t_base_s {
spinlock_t lock;

    // 目前已经处理到的时间点
    // 这个时间点之前应该到期的所有任务都已经处理完了。
unsigned long timer_jiffies;

    // 当前正在执行的任务
struct timer_list *running_timer;

    // 下面的几个字段是这个数据结构的核心。
    // 每个字段可以理解成一个使用链表来解决冲突的哈希表。
    // 哈希表的 key 是定时任务的 expires - current_time 的值。
    // 哈希表的 value 是定时任务本身。
    // 每个字段的 hash 函数不同。

    // 只包含 [0, 256) 个 tick 之后过期的任务
    // hash function: id -> id.
tvec_root_t tv1;

    // 只包含 [256, 64 * 256) 个 tick 之后过期的任务
    // hash function: id -> id / 256
tvec_t tv2;

    // 只包含 [64 * 256, 64 ^ 2 * 256) 个 tick 之后过期的任务
    // hash function: id -> id / 256 / 64
tvec_t tv3;

    // 只包含 [64 ^2 * 256, 64 ^ 3 * 256) 个 tick 之后过期的任务
    // hash function: id -> id / 256 / 64 ^ 2
tvec_t tv4;

    // 包含更未来的任务
tvec_t tv5;
}

这个数据结构，某种程度上来看，和时间轮非常接近。随着时间的前进，当 tv1 中的任务完全处理完的时候，tv2 中的最小 slot 中的所有任务（tick 跨度是 256）会填补到 tv1 中。tv2 中的任务完成了之后，也会从 tv3 中获取任务，以此类推下去。这样的数据结构，可以支持快速的插入和查找的操作。

任务执行

Linux 执行定时任务的策略，某种程度上有点像 cron job。对于每个时钟中断（每个 tick），Linux 定义的中断处理函数都会更新当前时间，同时会触发一个软中断（TIMER_SOFTIRQ）。这个软中断的处理函数会查看 tvec_t_base_s.timer_jiffies 和当前时间的差距，然后处理所有到期的任务。之所以要使用软中断，是因为我们要保证每个硬件中断（这里的时钟中断）的处理函数执行的时间足够短，否则会阻塞其他的中断处理，降低系统的吞吐量。具体的代码的调用路径见下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 时钟中断处理函数
timer_interrupt() {
    do_timer_interrupt() {
        do_timer_interrupt_hook() {
            update_process_times() {
                run_local_timers() {
                    // 触发软中断
                    raise_softirq(TIMER_SOFTIRQ);
                }
            }
        }
    }
}

// 软中断处理函数
run_timer_softirq() {
    // 核心逻辑
    __run_timers();
}

系列文章:

快照隔离在一些分布式系统中的实现 (1) - 什么是快照隔离
快照隔离在一些分布式系统中的实现 (2) - Omid1

Omid1 发表于论文 Omid: Lock-free transactional support for distributed data stores。论文作者在之后的另一篇论文中对它的设计做了一些改进，并将 Omid 原本的设计称为 Omid1。为了方便，接下来我都会用 Omid 来指代 Omid1.

Omid 是什么

根据论文的描述，Omid 是一个用来为已有的数据存储系统支持事务的工具，并且事务是实现是 lock-free 的。这里有几个关键词：

1. 工具
2. 事务
3. Lock Free

用更直白的话说，Omid 是一个外挂/插件。它可以和已有的数据存储服务（例如论文中使用的 HBase）组合，实现事务的支持。基于已有的存储服务是一个很有意思的设计选择。之前也有一些论文使用了相同的思路，比如Precolator就使用了Bigtable。使用已有的系统可以节省很多开发和运维成本。同时这些系统也已经经受了时间的考验，在性能上都没什么问题。

既然这个系列是关于快照隔离，很明显，Omid 支持的事务也选择了支持快照隔离等级。接下来，我们一起来看一看 Omid 是怎么支持快照隔离的。

Omid 的设计思路

在这个系列的第一篇文章里，我们已经介绍了快照隔离的一般实现思路。没有读过也没关系，这里我们再重复一下这个设计思路：

1. 数据存储层会维护每个数据的多个版本。
2. 事务开始前会分配一个开始时间戳 *T_start*。
3. 事务会记录自己修改的所有数据集合。
4. 事务提交之前先会分配一个提交时间戳 *T_commit*。
5. 分配完时间戳之后会检查是否有事务和自己的修改数据集合有交集，并且该事务的提交时间戳在 (T_start, T_commit) 之间。

简而言之，根据这个实现思路，快照隔离的实现往往需要两个东西：

1. 数据多版本
2. 单调递增的(逻辑)时间戳

在 Omid 的设计中，数据多版本是通过 HBase 实现的。而单调递增的时间戳则是通过一个中心化的服务实现的，论文中将它称为 transaction status oracle，以下简称 TSO。这个服务除了分配时间戳之外，还会用来判断事务是否提交。

Omid 的实现简介

其实看到这里，Omid 的大概实现相信已经比较清楚了。我们分别通过 Omid 使用的数据结构，和读写操作的伪代码来了解它的实现原理。

数据结构

为了满足快照隔离的实现，Omid 分别在 HBase 和 TSO 中维护了不同的数据。

HBase 中主要保存了数据的多个版本。对于每一个 key，HBase 本身就会保存这个 key 对应的多个历史版本数据，并且每个版本的数据都有对应的时间戳。

TSO 中则维护了两张表，分别是 Commit 和 Last Commit Timestamp。Commit 表维护了从事务 ID 到它提交时间戳的映射。由于事务开始时间的时间戳是唯一的，Omid 直接使用了开始时间戳作为事务 ID。Last Commit Timestamp 表维护了从每一个 Key 到最近修改它并且提交成功的事务的 *T_commit*。

伪代码

实现的关键部分主要是事务的开始，事务的提交，已经数据的读写。我们分别来看一下这几个操作的逻辑。

事务的开始

客户端会对 TSO 发起一个 RPC 调用，获得一个时间戳。

1
2
3
4
5

// Implemented by TSO
txn_timestamp start() {
  auto t_start = assign_timestamp();
  return t_start;
}

事务的提交

客户端会之前获得的事务开始时间戳 T_start 以及修改的 key 的集合发送给 TSO。TSO 判断事务是否能够提交。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// Implemented by TSO
txn_commit_result commit(txn_timstamp t_start, set keys) {
    for (auto key : keys) {
        if (last_commit(key) > t_start) {
            // 因为提交时间戳一定比 last_commit 大，所以只需要判断 last_commit 是否大于 t_start
            return abort;
        }
    }

    auto t_commit = assign_timestamp();
    for (auto key : keys) {
        last_commit(key) = t_commit
    }
    return commit;
}

数据的读写

数据的写相对比较简单，完全在客户端实现。客户端在 HBase 中将 (key, t_start) 的值设置为对应的 value 即可。注意这个写操作是在事务提交之前做的，这也就意味着 HBase 中存储的值并不一定提交成功，在读取的时候需要通过 TSO 做判断。

数据的读比较复杂，下面是它的伪代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

value read(key key, txn_timstamp t_start) {
    txn_timestamp end = t_start;
    while (true) {
        list<value> values = read_n_values_before(key, 10, end);
        if (values.empty()) {
            return nullptr;
        }

        for (auto value : values) {
            if (in_snapshot(value, t_start)) {
                return value;
            }
        }
        update end to the earliest timestamp of values.
    }
    return nullptr;
}

// 需要访问 TSO
bool in_snapshot(value value, txn_timstamp t_start) {
    // 写下这个 value 的事务的开始时间戳
    txn_timestamp value_start_timestamp = value.txn_start_timestamp();
    txn_timestamp value_commit_timstamp = commit_table(value_start_timstamp);
    return value_commit_timstamp != nullptr // 意味着写这个值的事务提交成功了
        && value_commit_timstamp < t_start; // 意味着写这个值的事务在当前事务之前提交
}

问题和 Omid 的解决方案

上面的实现思路虽然很简单，但是在性能上会有一些问题。

1. HBase 中没有提交的事务写入的数据会额外占据空间，同时老版本的数据也会。
2. commit表会随着运行时间不断增大。
3. last commit表和 key 的数量成正比，TSO 作为单节点无法在内存中存储全部。
4. in_snapshot需要访问 TSO，一个事务会访问很多次，造成 TSO 压力过大。
5. TSO 的稳定性。

为了解决这些问题，Omid 在实现上做了一些优化。我们接下来一一分析。

HBase 中的数据

对于没有提交成功的事务的数据，客户端在收到提交失败的响应之后，可以自行删除刚刚写入的数据。与此同时，Omid 也会定期执行清理工作，通过判断一个 cell 的版本号是否在 commit 表中有对应的数据来决定是否需要清理。

对于老版本的数据，我们只需要保证当前还未执行完的事务能够访问他们需要读取的数据版本即可。TSO 通过维护一个 watermark 来记录所有分配但是还没有提交的事务即可。对于那些很久都没有提交的事务（有可能是 Client 进程挂了），TSO 也可以通过一个 TTL 来忽略，如果对应的 Client 又浪子回头提交事务，TSO 直接拒绝事务即可，不影响正确性。

commit 表的规模控制

和 HBase 数据规模控制的思路类似，commit 表可以在不影响正确性的情况下，丢弃很老的 entry。与此同时，TSO 会维护一个 T_max*。这个 *T_max 是所有丢弃的 entry 中提交时间戳的最大值，同时对事务提交代码做这样的改动：

1
2
3
4
5
6
7
8

// Implemented by TSO
txn_commit_result commit(txn_timstamp t_start, set keys) {
    // t_start 太老了
    if (t_max > t_start) {
        return abort;
    }
    // 和之前一样
}

这样的改动可能会有一些 false positive，但是概率不会太大，我们可以通过修改 commit 表的最大大小来控制这个概率。注意，即使错误的 abort 一个事务，也是不会影响正确性的。

做了这个优化之后，虽然 commit 方法可以正常工作，但是 in_snapshot 方法的正确性会受到影响，因为通过查看表中是否有某个版本来决定事务是否提交会出错。为此，TSO 又维护了一个被 abort 的事务 ID 列表，并对 in_snapshot 方法做如下修改：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 需要访问 TSO
bool in_snapshot(value value, txn_timstamp t_start) {
    txn_timestamp value_start_timestamp = value.txn_start_timestamp();
    txn_timestamp value_commit_timstamp = commit_table(value_start_timstamp);
    if (value_commit_timstamp != nullptr) { // 意味着写这个值的事务提交成功了
        // 意味着写这个值的事务在当前事务之前提交
        return value_commit_timstamp < t_start;
    }

    // 如果 commit 表中没有，可能是因为数据被 recycle 了，需要单独判断
    if (t_max < value_start_timestamp) {
        // t_start > t_max 说明不是因为 recycle 导致找不到
        return false;
    } else if (value_start_timestamp in abort_list) {
        // 在 abort 集合中，说明没有提交成功
        return false;
    }
    return true;
}

为了控制 abort 列表的大小，我们在清空 HBase 中无效数据的时候，也会顺便清理。

last commit 表的规模控制

为了控制 last commit 表的规模，Omid 使用 HBase 的 key 的 hash 值作为自己的 key，通过牺牲精度来换取空间。同时，如果某一个 entry 的时间戳如果小于 *T_max*，我们也可以删除它。

TSO in_snapshot 的调用频率

之所以 in_snapshot 需要访问 TSO 是因为需要访问 commit 表。为了解决这个问题，Omid 利用 commit 表实际上是 append only 的特性，提出了一个巧妙的解决方案，将 commit 表的数据同步给客户端，以减少网络 I/O。而将 commit 表的数据同步给客户端的操作，是在客户端调用 TSO 开始一个事务的时候执行的，注意到 TSO 只需要将返回给客户端的时间戳之前的 commit 表的数据同步到客户端，就可以满足这个事务执行过程中 in_snapshot 的需求了。

TSO 的稳定性

Omid 通过使用 replica 来保证 TSO 的稳定性。当 TSO 挂了的时候，一个 replica 成为新的 TSO 需要恢复

1. commit 表
2. abort 列表
3. T_max
4. last commit 表

对于前三者，Omid 使用 WAL 保证数据的持久化。Replica 在恢复是会重放 WAL 保证数据完整性。
至于 last commit 表，由于只用来检测写冲突，我们可以通过无脑 abort 所有比 replica 上位之后第一个事务还要早的事务，来避免恢复这个表。

系列文章:

快照隔离在一些分布式系统中的实现 (1) - 什么是快照隔离
快照隔离在一些分布式系统中的实现 (2) - Omid1

最近在读一篇描述快照隔离的文章的时候，我发现自己已经差不多忘了之前读的论文里提到的各种分布式系统是怎么实现快照隔离的了。我不得不又重温了一下那些论文，但是这次要写几篇博客来总结一下。

老生常谈的 ACID

ACID 可以说是计算机专业学生的必学概念，同时也是互联网公司面试的常客。讨论快照隔离自然也没法绕开 ACID。ACID 是以下四个概念的缩写。

1. Atomic：原子性。一个事务的所有写操作要么全部完成（i.e. Commit)，要么全部失败（i.e. Abort）。注意这里的原子性和并发编程中的原子性的区别。并发编程中的原子性是指一个过程是“不可分割的”，其他线程无法看到这个过程进行到一半的状态（但是如果机器突然断电了，那么这个过程可能只完成了一部分）。
2. Consistent：一致性。这是一个业务概念，表示数据库的状态永远都是合法的。这个一致性，是通过 ACID 中的其他属性保证的。
3. Isolation：隔离性。若干个并发事务不应该互相影响，它们如果都提交成功，那么数据库的状态应该和他们以某种顺序依次执行后的状态相同，这是狭义上的隔离性，也被称作是 Serializable Isolation。在实际业务中，我们往往不需要这么强的隔离性保证。通过放松隔离性要求，我们往往可以获得更高的并发量，从而获得更高的吞吐量。
4. Durable：持久性。每一个提交成功的事务包含的所有写操作都必须持久化的保存下来，即使数据库进程突然终止。

上面的四个概念中，A，C，D 并没有什么可以变化的地方。而剩下的 I 则有很多变种。在介绍 I 的变种之前，我们需要先讨论这些 I 的变种到底是为什么被发明出来。

并发事务可能带来的问题

如果没有了强隔离性的保证，并发事务可能会带来各种各样的问题。我们用教科书级的例子来描述各种可能出错的情况。假设我们有一张表 Accounts，它的 Schema 长这样：

1
2
3
4
5
6

CREATE TABLE Accounts (
  UserId varchar(255),
  Type varchar(255),
  Balance int,
  PRIMARY KEY (UserId, Type)
)

脏读 Dirty Read

Dirty Read 是指当两个并发事务 Txn1 和 Txn2 执行时，Txn1 读取到了 Txn2 还没有提交的改动，不管 Txn2 之后实际是提交了还是没有提交。考虑这个例子，当用户 1 执行转账任务 (Txn 2) 的同时查询自己的账户余额 (Txn 1)，他会发现自己的余额总数不对。这是因为 Txn 1 读取了一个进行中的事务修改后的值。

脏写 Dirty Write

Dirty Write 是指当两个并发事务 Txn1 和 Txn 2 执行时，一个事务的写操作覆盖了另一个事务的未提交的写操作，导致两个事务都提交之后，数据库的状态不满足一致性。比如下面这里例子，当两个修改文件数据和元数据的事务并发执行后，元数据中的最后修改人，和文件的最新内容不匹配。

写丢失 Lost Update

Lost Update 和 Dirty Write 类似，也是两个并发的写操作造成的 conflict。但是 Lost Update 有些不同，它没有覆盖未提交的写操作。比如下面这个例子，用户 1 的公司同时给用户 1 的账户发了奖金和工资，然而这两个事务由于出现了写丢失，导致用户 1 最终只收到了其中的一笔钱。

不可重复读 Unrepeatable Read / Fuzzy Read / Read Skew

Unrepeatable Read 是指一个事务 Txn1 中读取的数据被另一个并发事务 Txn2 修改了。在 Txn2 提交之后，Txn1 之前读取的数据已经失效，如果再重新读一次就会读到不同的值。然而，Txn1 往往不会重新读一次，而是会读取其他的被 Txn2 修改的数据。这样，Txn1 会同时读到 Txn2 提交前后两个不同版本的部分数据，从而破坏一直性。比如下面这个例子，在用户 1 执行转账的同时，他查询余额总数会得到不正确的结果。注意和 Dirty Read 的区别，Txn1 每次读取的数据都是已提交的数据。

写偏斜 Write Skew

Write Skew 是指两个事务并发读取一个数据集之后，同时修改不相干的两部分数据，造成的数据库不一致的问题。这个描述有些抽象，我们看下图的这个(可能并不自然的)例子。用户 1 同时刷了信用卡和申请贷款触发了两个事务。这两个事务都读取了该用户的余额总额，发现总额足够 100 之后，各自在 credit 和 loan 两个账户下扣除了 100 元。可以看到，Write Skew 归根结底，也是两个并发的写操作造成的 conflict。

如何解决上述问题

上面的这些问题都是用于多个事务的并发执行导致的。为了解决这些问题，我们需要使用适当的隔离等级来约束事务的执行顺序/策略。例如，如果我们用最傻的办法，即全局锁，来实现所有事务都依次执行，我们就达成了 Serializable Isolation，显然上面的这些问题都不会发生。如果我们只需要解决其中的部分问题，我们可以使用更弱的隔离等级。下面会一一介绍几种常见的隔离等级，它们能解决的问题，以及它们的实现思路。注意，不同的数据库系统中，同一个名称的隔离等级表达的含义可能不同，大家使用的时候需要去读一下对应的文档。

Read Committed

Read Committed 解决了 Dirty Read 和 Dirty Write 这两个问题。其中 Dirty Read 这个问题实在太严重了，几乎所有的（如果不是全部的）隔离等级都保证不会读取到未提交的数据。Read Committed 做的事情就和它的名字一样，保证读操作只能读取到提交了的数据。

常见的实现 Read Committed 的方式是通过读写锁。当写一个数据的时候，为数据上写锁（排他锁）。当读取一个数据的时候，为数据上读锁（共享锁）。这样，任何一个事务在读取的一个未提交的事务修改的数据时，会阻塞直到该事务提交。当然，这样简单的实现方式性能并不太理想，尤其是在一个事务需要用户同意时，会长时间的占用一个写锁，从而阻塞其他事务。一个比较简单的优化是，在事务上写锁之前，记录下该数据的当前值。其他的事务可以直接读取记录下的值，避免被写操作阻塞。

Snapshot Isolation

Snapshot Isolation 解决了 Unrepeatable Read 和 Lost Update 的问题。它的思路是在一个事务执行过程中，数据库为它展示一个数据库在某个时间点的快照，这个快照包含了这个时间点之前所有提交的事务的执行结果。这样事务读取到的数据一定是一致的，Unrepeatable Read 的问题也就不存在了。除此之外，为了解决 Lost Update 的问题，每一个事务在提交之前，会检查自己修改的数据是否在提交之前被其他已经提交的事务修改了。如果已经被修改了，当前事务就必须被 Abort。

Snapshot Isolation 的常见实现是使用 MVCC，为同一份数据维护多个版本。当一个事务开始时为它分配一个时间戳 T_start*，这个事务的所有读取操作只会读这个时间戳之前的版本的数据，以此来达到快照的效果。同时，每一个事务会维护它修改的数据集合。在提交之前会分配一个时间戳 *T_commit*，然后判断所有修改集合中的数据是否被提交时间在 *(T_start, T_commit) 区间内的事务修改。如果没有才可以提交。注意这里的时间戳是单调递增的逻辑时间戳。

Serializable

Serializable 解决了所有的问题，因为它在观察者眼中，和所有事务依次执行是等价了。这是最强的隔离等级，所有的事务都互相“隔离”了。

Serializable 有多种实现方式。除了使用全局锁来事实上依次执行之外，实际使用的实现方式往往有：

1. Two-Phase Lock，通过锁的形式保证。除了读写锁之外，还需要对索引范围，甚至整张表上锁。它的实现非常复杂，性能很差，并且非常容易出现死锁。
2. Serializable Snapshot Isolation，和 Snapshot Isolation 类似。但是除了像 Snapshot Isolation 一样检查两个写操作的冲突，还会检查读操作和写操作之间的冲突（维护读取的数据集合，如果集合中有数据在提交前被其他事务修改，也需要 Abort 事务）。

快照隔离

上面已经介绍了快照隔离的大概实现思路，这里再总结一下：

1. 数据存储层会维护每个数据的多个版本。
2. 事务开始前会分配一个开始时间戳 *T_start*。
3. 事务会记录自己修改的所有数据集合。
4. 事务提交之前先会分配一个提交时间戳 *T_commit*。
5. 分配完时间戳之后会检查是否有事务和自己的修改数据集合有交集，并且该事务的提交时间戳在 (T_start, T_commit) 之间。

接口

这篇文章描述的实现思路很简单，它尝试用一个数据结构去描述一个任务执行的上下文，并使用一个队列来维护没有完成的任务。任务以及调度器的接口如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

class TaskHolder {
 private:
  // 实际要执行的任务代码
  void (*_task)(Scheduler* scheduler);

 public:
  TaskHolder(void (*task)(Scheduler* scheduler));
  
  // 实际触发任务执行的代码
  virtual void run(Scheduler* scheduler) { _task(scheduler); }
};

class Scheduler {
 protected:
  // 获取正在执行的任务
  virtual TaskHolder* get_current_task();

  // 设置正在执行的任务
  virtual void set_current_task(TaskHolder* task_holder);

  // 将当前任务移除队列
  virtual void exit_current_task();

 public:
  // 添加任务
  virtual void add_task(void (*task)(Scheduler* scheduler));

  // 任务主动让出 CPU, 由任务代码调用.
  virtual void yield() = 0;
    
  // 调度器开始执行任务
  virtual void run() = 0;
}

只看上面的接口可能有点抽象，下面给出一个实际的使用例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

scheduler::SequentialScheduler scheduler{};
// 添加两个任务
scheduler.add_task([](scheduler::Scheduler *scheduler) {
    for (int i = 0; i < 2; i++) {
        std::cout << "Task 1: " << i << std::endl;
        // 让出 CPU 使用权
        scheduler->yield();
    }
});
scheduler.add_task([](scheduler::Scheduler *scheduler) {
    for (int i = 0; i < 4; i++) {
        std::cout << "Task 2: " << i << std::endl;
        // 让出 CPU 使用权
        scheduler->yield();
    }
});
// 开始执行任务, 当所有任务执行完毕后, run方法返回
scheduler.run();
std::cout << "Finish" << std::endl;

上述代码的输出是:

1
2
3
4
5
6
7

Task 1: 0
Task 2: 0
Task 1: 1
Task 2: 1
Task 2: 2
Task 2: 3
Finish

实现原理

和原文的实现一样，我的实现包含了两个核心部分:

1. 使用setjmp 和 longjmp来实现控制流的转移，保留上下文，即所有寄存器的值。
2. 自行维护每个任务的栈内存，保留栈空间。

setjmp 和 longjmp

setjmp 和 longjmp 提供了类似汇编中 jmp 指令的功能. setjmp可以将当前指令的内存地址存储一个数据结构中（jmp_buf)，而 longjmp 可以返回 jmp_buf 指定的地址继续执行。下面我们看一个例子。

1
2
3
4
5
6
7
8
9
10

jmp_buf target;

auto value = setjmp(target);
if (value) {
    std::cout << "Someone jumps here! With a value " << value << std::endl;
} else {
    std::cout << "Set up a place for jumping" << std::endl;
}

longjmp(target, 100);

上面这段代码会进入一个死循环，在输出一次 Set up a place for jumping 后会不断地输出 Someone jumps here! With a value 100。之所以有这样行为的原因主要是：

1. longjmp 会跳回 setjmp 发生的位置重新执行。
2. setjmp 实际调用会返回 0，如果由 longjmp 调用则会返回 longjmp 的第二个参数值。

手动维护栈内存

大家的知道，在执行代码的过程中，为了保证每个线程才能互不干扰的执行自己的逻辑，它们需要有独立的栈空间，操作系统会保证这一点。在我们现在的实现中，每个任务也需要有独立的栈内存。没有了操作系统的帮助，我们需要自己手动分配内存，并将其指定为栈内存。核心的实现代码如下：

1
2
3
4
5
6

// 分配栈内存
task->_stack_bottom = malloc(stack_size);
// 计算栈顶地址
task->_stack_top = task->_stack_bottom + stack_size;
// 使用汇编将 rsp 寄存器的值设置为我们分配的栈顶地址
asm volatile("mov %[rs], %%rsp \n" : [ rs ] "+r"(task->_stack_top)::)

总结

实现代码见 Github，这里就不再赘述了。

可能的扩展

Github 上给出了 SequentialScheduler 的实现，是一个单线程的版本。我感觉可以比较简单的扩展成可并发的版本。有兴趣的朋友可以试一下。

为什么用纤程这个词

我最开始在纤程和协程中犹豫了一下。

根据我个人的理解，协程之间应该有显式的控制流切换。而在我们的实现中，只有 task 和 Scheduler 之间存在控制流切换，因此我觉得协程不太恰当。

我们的实现，某种程度上似乎很像 event loop。最大的区别在于，我们并不需要一个事件来决定哪一个任务是可调度的。我的实现中，每一个任务都是可以调度的。

如果我们扩展成了可并发的版本，也许使用纤程就比较恰当了。

Vert.x 源码阅读 (1) - Future 和 Promise

Vert.x 源码阅读 (2) - Stream

Vert.x 源码阅读 (3) - EventBus

Vert.x 源码阅读 (4) - Context

这是 Vert.x 项目源码阅读笔记的第四篇，主要记录一下 Vertx 中的核心 Context。Context 贯穿了整个 Vertx 的代码，它主要用来表示一个任务执行时的上下文环境。

一个服务实例往往需要同时处理大量的请求，而这些请求相互独立，拥有不同的上下文。在使用 Servlet 的年代，由于每个线程同时只处理一个请求，我们使用一个简单的 ThreadLocal 变量就可以满足需求。然而，在使用 EventLoop 的时候，由于一个线程会同时处理多个请求，我们需要显式地管理和切换上下文。Context 是 Vertx 中上下文的抽象。

简介

在详细介绍 Context 之前，我们先介绍几个名词：

• Handler 是一个可执行的对象，类似 Runnable。
• 线程，就不多说了。
• Execution 是指 Handler 的一次调用。Handler可以被多次调用。

Context 是

The execution context of a Handler execution.

简单来说，就是 Handler 的一次调用从开始到结束时，它使用的上下文信息。例如，一个 REST 请求执行过程中的 HEADER 信息。

在 Vertx 中，Context 和线程的关系简单来说，可以总结成一下几点

1. 一个线程在不同的时间，会执行不同的 Handler，因此和它相关联的 context (通过 VertxThread::context) 获取会发生变化。即**一个线程会对应到多个 context**。
2. 一个 Context 往往只对应到一个线程，但是并不强制。

Context 的继承关系如下图：

根据上图，我们知道在 Vertx 主要有 EventLoopContext 和 WorkerContext 这两类 Context。这两类 Context，前一类对应到 EventLoop 线程，后一类对应到 Worker 线程。它们两个的区别主要在于，在执行/调度一个任务时（调用一个 Handler 时），到底使用哪一个线程。

Context

Context 是一个接口，它主要包含了一下几类方法：

1. 获取当前执行线程的一些基本信息，例如 isOnWorkerThread。
2. 获取自身属性，例如 isEventLoopContext。
3. 读取或更新上下文信息，例如 get，put。
4. 执行任务，例如 runOnContext ，executeBlocking。

前三类方法都相对比较好理解，我们主要看看 Context 提供的执行和调度任务的方法。

执行和调度任务

Context 主要提供了四种类型的调度方式：

上表描述了各个类型的执行方法使用的线程和上下文，注意 dispatch 和 execute 的语义是一样的，它们的区别在于，

• execute 将任务加入自己对应的线程的执行队列
• dispatch 会判断当前线程是不是自己对应的线程，如果是的话直接执行。否则和 execute 一样。

上面的描述可能比较抽象，下面用伪代码来简单实现这几种方式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

// 通过保存和恢复现场，来实现在执行任务过程中，用自身作为上下文
public void emit(Runnable task) {
  // 获取当前线程使用的 context，并将当前线程关联的 context 设置为自己
  ContextInternal prev = emitBegin();
  try {
    handler.run();
  } catch (Throwable t) {
    reportException(t);
  } finally {
    // 恢复当前线程使用的 context
    emitEnd(prev);
  }
}

// 在自身关联的线程上，执行任务。这个任务被 emit 包裹，保证执行是会使用自身做上下文。
public void execute(Runnable task) {
  getAssociatedThread().execute(() -> emit(task));
}

// 在自身关联的线程上，执行任务。但是任务执行时的上下文没有单独指定。
public void schedule(T argument, Handler<T> task) {
  Thread thread = getAssociatedThread();
  if (thread.isCurrentThread()) {
    task.handle(argument);
  } else {
    thread.execute(() -> task.handle(argument));
  }
}

public void dispatch(T argument, Handler<T> task) {
  schedule(v -> emit(argument, task));
}

执行阻塞代码

在使用 EventLoop 时，我们不应该阻塞事件循环。这是因为事件循环的线程数很少，一旦阻塞了，新的请求都会被阻塞。当我们需要执行阻塞代码是，我们往往会使用另外的线程来执行。Context 提供了 executeBlocking 系列方法，来满足这个需求。它的实现伪代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

@Override
public <T> Future<T> executeBlocking(Handler<Promise<T>> blockingCode, TaskQueue queue) {
  // Worker Pool 就是我们所说的非事件循环线程
  return executeBlocking(this, blockingCode, workerPool, queue);
}

static <T> Future<T> executeBlocking(ContextInternal context, 
                                     Handler<Promise<T>> blockingCode,
                                     WorkerPool workerPool, TaskQueue queue) {
  // 创建一对 Promise 和 Future
  // Promise 会传个 blockingCode. BlockingCode 在完成后应该调用 promise 的 complete 方法
  // 调用者使用 Future 来监听 blockingCode 是否完成
  Promise<T> promise = context.promise();
  Future<T> fut = promise.future();
  
  // 构造一个任务
  Runnable command = () -> {
    // 使用 emit 方法，保证会使用 context 作为上下文
    context.emit(promise, f -> {
      blockingCode.handle(promise);
    });
  };
  
  // 使用 workerPool 和 queue 执行任务
  queue.execute(command, exec);
  return fut;
}

看到上面的代码，我们可以发现，指定的阻塞任务

1. 执行在 Worker 线程上
2. 使用了当前的 (EventLoop) 的 Context

这样实现看似有点奇怪，实际上满足了等效于在事件循环上”执行“阻塞代码的要求。这也是为什么 Context 会提供单独的 isEventLoopContext/isWorkerContext 和 isOnEventLoopThread/isOnWorkerThread方法。

阻塞时长监控

虽然我们允许使用 Context 执行阻塞代码，阻塞的时间仍然不能太久。Vertx 通过 BlockedThreadChecker 来监控线程的阻塞时间。

BlockedThreadChecker 的实现比较简单。它通过一个后台线程，定期的检查每个线程当前执行的任务的开始时间离现在有多久。如果超过了最大时间，就打印一条日志。

Leverage

整本书最核心的观点，就是永远以 Leverage 为导向。Leverage = 产出 / 耗时，也就是单位时间内的产出。提高 Leverage 自然就会让自己更加高效，而方法也很自然，有三种：

1. 提高产出
2. 减少耗时
3. 换一个 Leverage 更高的任务来做

这三个方法从数学层面很容易理解，但是执行起来并不容易。这本书就是围绕了这三个方面来展开的。接下来讲几个比较细节的点。

优化学习

学习的效果，和复利（利滚利）很相似。它是一个指数函数。曲线前期的斜率很小，但是到了后期就会 “火箭发射，轰隆隆隆”。要注意的是，前期的一点点提高，对后期会有巨大的影响。作者也提到了他当时在 Google 花了大量时间阅读内部的代码和文档，看到这，我就痛心疾首，后悔自己在 Google 的时候怎么没有好好利用这么好的学习资源。

任务管理

作者使用 {“重要”，”不重要”} x {“紧急”，”不紧急”} 来区分所有的任务，并强调了重要但不紧急的任务。这种 classify 方式之前就听过很多次了，但是都没有深入了解，看了这本书才明白这么做的意义。我个人性格上的一个缺陷是没法忍受有任务没做完（用我爸的话来说，就是没有大将风度），而这些任务往往大部分都是紧急但不重要的。被这些任务占据了大量时间，导致自己推迟了很多重要但不紧急的，对个人成长有帮助的任务。而这些被推迟的任务实际上 Leverage 更高（见优化学习）。

尽早建立 Feedback Loop

建立 Feedback Loop 本质上也是为了提高 Leverage。通过获取同事，上级的 Feedback，及时修正自己对 Leverage 的判断。这样我们可以一直去选择 Leverage 更高的任务，提高效率。

而由这一点出发，我们可以发现，有更多的执行准则，例如：

1. 尽早做原型，MVP，来获取 Feedback
2. 开发时多做 instrument，多收集 Metric，多加测试
3. 提高迭代速度，尽快上线，A/B 测试
4. 先做风险最大的部分
5. 警惕单人项目，多获取 Code Review（这是我个人的一大问题，开发太快，担心老让人 Review 会拖慢自己的开发进度，但是实际上磨刀不误砍柴工）

帮助周围的人成功

个人事业成功的秘诀是帮助周围的人成功。这一点是我之前没有意识到的，但是读了这本书之后深以为然。一个人的力量终归优先。让周围的人成长，将紧急但不重要的任务分发出去，让自己可以去做 Leverage 更高的事情。你可能觉得这么做是不是有点自私？其实，我们要意识到任务是否”紧急但是不重要”是一个主观标准。例如，对一个 senior 的工程师来说不重要的任务，对于 junior 的工程师也许是重要的，因为他们需要更多的训练来累积经验。

从这一点出发，我们也可以发现更多的原则：

1. 做好新入职员工的 onboard。他们越早适应，就可以有越块的成长（回忆一下学习曲线）。今天自己花几个小时帮助新同事更快熟悉，换来他们日后几年的贡献，孰轻孰重一目了然。
2. 重视 sharing code ownership。这一点虽然有点反直觉，毕竟成为团队内唯一熟悉某个服务的人，这种感觉好像很好。但是仔细想一想，就会发现不分享 ownership 会导致两个问题：
   1. 对公司来说，你是一个单点故障
   2. 对个人来说，因为你是唯一熟悉这个服务的人，所以大量紧急但不重要的 bug fix 需要你来做。你就没时间去做 leverage 更高的事情了。

重视工具和自动化

这也是老生常谈了。开发工具会暂时的花费时间，但是之后可以大大提供效率。我们在实操的时候要注意：

1. 重视工具的推广，用的人多，impact 才越大。而提高使用率，则需要尽早建立 Feedback。
2. 渐进式开发，最开始不要想着一步到位，而是一点一点的优化工作流。这样的好处也是为了尽早获得 Feedback，同时也平衡了和其他任务的冲突。

Vert.x 源码阅读 (1) - Future 和 Promise

Vert.x 源码阅读 (2) - Stream

Vert.x 源码阅读 (3) - EventBus

Vert.x 源码阅读 (4) - Context

这是 Vert.x 项目源码阅读笔记的第三篇，主要记录一下 EventBus 相关的代码。EventBus 是一个轻量级的分布式消息系统，让 Vert.x 的服务中各个组件之间可以以一种低耦合的方式交互。代码在这个目录下，主要包含了 EventBus，MessageConsumer，MessageProducer，以及 DeliveryContext。

消息总线 EventBus

EventBus 提供了两类接口：

1. 通讯相关的接口，例如 send, publish 等等。
2. 创建更加高级的抽象的接口，例如 consumer，producer。

EventBus 只提供的 best-effort 的投递保证，它提供了三种通讯模式：

其中 P2P 和 RR 模式非常类似，区别只在于 RR 会指定一个 replyHandler（实现上会在投递的消息中指定一个 replyAddress，之后详细介绍）。

Message 类

Message 是实际发送的消息，它实际上是对网络请求的封装。它包含了消息的发送地址，接收地址等等，这里不详细介绍了。

MessageConsumer

MessageConsumer （逻辑上很自然地）扩展了 ReadStream<Message<T>>接口，是对消息处理做的抽象。它是线程安全的，但是如果能只在单一线程（也就是之后会讲到的事件循环线程）上被使用的话，性能会更好一点。这是因为它的并发控制使用了 synchronize 关键字，而 JVM 在没有竞争的情况下会退化到使用偏向锁，减少同步开销。

实现

MessageConsumer 本身是一个接口，它的实现是 MessageConsumerImpl。我们这里先看一下它的核心方法之一，doReceive(Message<T> message)。它是新消息进入时的入口方法，核心代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

protected void doReceive(Message<T> message) {
  Handler<Message<T>> theHandler;
  synchronized (this) {
    if (demand == 0L) {
      // 如果没有需求
      // 回忆一下之前提到的 Stream 的背压处理
      if (pending.size() < MaxBuffer) {
        pending.add(message);
      } else {
        // 超过最大缓冲大小的话就丢弃
        discardHandler.handle(message);
      }
    } else {
      if (pending.size() > 0) {
        // 从之前 pending 中最早的消息开始处理
        pending.add(message);
        message = pending.poll();
      }
      // handler 是 mututable 的
      // copy 一下 handler 的引用，在同步块外实际调用 handler
      // 很典型的并发编程模式
      theHandler = handler;
    }
  }
  
  // 将消息发送给 handler.
  deliver(theHandler, message);
}

从这个方法我们看出来 MessageConsumer 的运作原理。

这里还有一个比较有意思的地方是 deliver 方法：

1
2
3
4
5
6
7
8
9
10
11

private void deliver(Handler<Message<T>> theHandler, Message<T> message) {
  // 给 Producer 回血
  String creditsAddress = message.headers().get(CREDIT_ADDRESS_HEADER_NAME);
  if (creditsAddress != null) {
    eventBus.send(creditsAddress, 1);
  }

  // 实际将消息发送给 handler.
  dispatch(theHandler, message, context.duplicate());
  checkNextTick();
}

这个方法的前四行代码发送了 1 这条消息给 creditsAddress，实际上是给 MessageProducer 监听的一个”队列”发送 credit，MessageProducer 收到这个 credit 就会给自己”回一滴血”，表示自己能够多一个可以发消息的额度。

MessageProducer

MessageProducer （在逻辑上很自然地）扩展了 WriteStream<T> 接口，是对消息发送做的抽象。

实现

MessageProducerImpl 是 MessageProducer 的实现。它有两个核心方法，分别是 write 和 doReceiveCredit。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

@Override
public void write(T data, Handler<AsyncResult<Void>> handler) {
  Promise<Void> promise = createPromise();
  promise.future().setHandler(handler);
  write(data, promise);
}

private void write(T data, Promise<Void> handler) {
  MessageImpl msg = createMessage();
  OutboundDeliveryContext<T> sendCtx = createContext();
  
  // 只有在 P2P 和 RR 模式下，send 才是 true。
  // 这也很合理。在 Pub-Sub 模式下，Producer 不会管下游"死活"，下游甚至都可能没有任何接受者。
  // 而在 P2P 和 RR 模式下，我们要考虑下游，实现背压。
  if (send) {
    synchronized (this) {
      // credits 有点类似令牌桶
      if (credits > 0) {
        credits--;
      } else {
        // 没有额度就先 pending。
        // 回忆一下 WriteStream 和 ReadStream 的流量控制机制。
        // WriteStream::writeQueueFull 的实现就是判断 credits == 0
        pending.add(sendCtx);
        return;
      }
    }
  }
  bus.sendOrPubInternal(msg, options, null, handler);
}

//============================================

private synchronized void doReceiveCredit(int credit) {
  // 回复发送额度
  credits += credit;
  while (credits > 0) {
    // 看看有没有 pending 的内容可以发的。
  }
  // 看看是不是从超负荷恢复过来了
  // 是的话，要调用 drainHandler
  checkDrained();
}
   

最开始我比较困惑的一点是，通过网络来恢复额度，总感觉不是很稳，要是网络挂了，就没法回血来允许接着发消息。但是仔细想想，要是网络挂了，发消息也没有意义了。

DeliveryContext

DeliveryContext 封装了一个要发送的消息，同时提供了一些控制方法。它最核心的方法就是 next()。一个 DeliveryContext 会包含多个 interceptor，而 next 会遍历这些 interceptor，一个个调用，直到全部调用完之后，再实际发送。这个类似于责任链模式，在很多框架中都使用了，例如 Spring Boot，Netty。

Vert.x 源码阅读 (1) - Future 和 Promise

Vert.x 源码阅读 (2) - Stream

Vert.x 源码阅读 (3) - EventBus

Vert.x 源码阅读 (4) - Context

这是 Vert.x 项目源码阅读笔记的第二篇，主要记录一下 Stream 这个抽象。Stream 是 Vertx 中消息传递使用的底层抽象。主要代码在这个目录下。其中两个接口比较重要，分别是 ReadStream 和 WriteStream。这两个接口都扩展了 StreamBase 这个接口。从名字就能看出来，这两个接口分别对应了读取和写入，我们可以不严谨地类比到 C++ 里的 std::cin 和 std::cout。

ReadStream

响应式

ReadStream 提供的接口是响应式的。使用者可以设置数据的回调方法，一旦有数据过来，回调就会被调用。这个和 Reactive 编程方式提供的抽象有点相似。

读取模式

ReadStream 提供了两种读取模式，它们分别是:

1. Flowing
2. Fetching

这两种模式可以类比为 Push 和 Pull 模式。ReadStream 通过 pause， resume，还有 fetch 三个方法来切换读取模式。pause 方法会进入 Fetching 模式，而 resume 方法会进入 Flowing 模式。fetch 方法则是用来在 Fetch 模式下指定需要读取多少元素。

下面是简化后的 ReadStream 接口的一个实现 MessageConsumerImpl 的代码。主要省略了边界条件处理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public interface MessageConsumer<T> extends ReadStream<T> {
}

public class MessageConsumerImpl<T> implements MessageConsumer<T> {
  // 这个字段用来表示想要读取多少元素。如果是 Long.MAX_VALUE，则表示正处在 Flowing 模式下。
  private long demand = Long.MAX_VALUE;
  
  public synchronized MessageConsumer<T> pause() {
    demand = 0L;
    return this;
  }
  
  @Override
  public MessageConsumer<T> resume() {
    return fetch(Long.MAX_VALUE);
  }

  @Override
  public synchronized MessageConsumer<T> fetch(long amount) {
    demand += amount;
    if (demand > 0L) {
      // 异步 consume 数据
    }
    return this;
  }
}

WriteStream

WriteStream 提供了异步的写入数据的接口，这个接口比较自然，所以不做太多讨论。下面我们主要看看它提供的流量控制的接口。

流量控制 Flow Control

WriteStream 提供的和流量控制的相关接口主要有三个

1. setWriteQueueMaxSize(int maxSize) 设置了最大的 Write Queue 的大小。
2. boolean writeQueueFull() 返回当前是否 Write Queue 已写满。
3. drainHandler(Handler<Void> handler) 用来指定当 Write Queue 从 Full 的状态恢复的时候，应该执行什么逻辑。

有了这三个方法，我们就能在一定程度上保证流量控制了。下面是一个简单的例子，假设我们想从一个 ReadStream 读取数据，然后写到 WriteStream 中。为了避免 WriteStream 的下游承受的住，我们可以这么写：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// 我们想把数据从 readStream 读出来，然后转移到 writeStream 中。
ReadStream<T> readStream = ...;
WriteStream<T> writeStream = ...;

readStream.handler(data -> {
  if (writeStream.writeQueueFull()) {
    // 发现 Queue 写满了，就暂停一下
    readStream.pause();
    // 在 Queue 恢复了之后，自动 resume
    writeStream.drainHandler(any -> {
      readStream.resume();
    });
  } else {
    writeStream.write(data);
  }
})

Vert.x 提供了 Pump 和 Pipe 两个接口，它们的实现和上面的代码类似。

Vert.x 源码阅读 (1) - Future 和 Promise

Vert.x 源码阅读 (2) - Stream

Vert.x 源码阅读 (3) - EventBus

Vert.x 源码阅读 (4) - Context

这是 Vert.x 项目源码阅读笔记的第一篇, 主要讲一下最基础的 Future 和 Promise 的概念。Future 和 Promise 实际上是异步编程中非常基础的两个抽象，大部分程序员想必都非常熟悉，我这里主要是整理为主。

Vert.x 中的 Future 和 Promise

AsyncResult 接口

Vert.x 中的 Future 扩展了 AsyncResult。AsyncResult 有点像一个 Monad，它包装了一个结果，或者是一个错误。注意 AsyncResult 这个接口并不包含结果还没有准备就绪的状态，这个状态是由 Future 暴露出来的。

Future 接口

Future 逻辑上表达了一个异步计算的结果。它扩展了 AsyncResult 接口，主要提供了两类方法：

1. 判断是否已经完成：isComplete。
2. 注册回调方法，例如 onComplete。

等待结果的一方直接面对的，应该是一个 Future 对象。这个对象对于结果使用方来说，是只读的。使用方可以不断的 poll 它直到计算完成，结果 ready。同时使用也可用基于这个 Future 创建一个新的 Future 对象。

Promise 接口

Promise 有点难解释，我觉得我们可以把它理解成 Future 的可写的另一端。实际完成异步计算的结果提供方，在干完活之后，将结果写入这个 Promise。Promise 会负责通知自己对应的 Future 结果已经准备就绪了。

Golang 中的 Channel

我感觉 Golang 中的 channel 是一个有点相似的概念。Future 和 Promise 是 channel 的两端。这也意味着，我们可以用 Future 和 Promise 来做线程间同步，虽然我们不应该怎么做，而应该根据你的情况使用更加适合的，专门用于同步的抽象。

一般的使用场景

在一般情况下，Promise 和 Future 的使用往往符合这样的模式。我们假设存在 A 和 B 两个实体，A 需要 B 执行一个任务，然后将结果告诉自己。为了达到这个目的，一般会经过一下几个步骤：

1. A 触发整个流程，往往是通过调用 B 提供的某个接口，这个接口一般都返回一个 Future 对象。
2. B 的接口中创建了一对 Promise 和 Future。Future 会被返回给 A。
3. A 获得返回的 Future 之后一般会在这个 Future 上注册回调函数，表示收到结果之后要做什么。
4. B 在结果计算出来之后调用 Promise::complete 方法，而这个 complete 方法会调用 A 在 Future 上注册的函数。

样例

为了加深理解，这里给出几段代码，用来品品这两个抽象的使用方式。为了方便理解，这里去掉了和 context 相关的代码。

Future 的 map 方法

1
2
3
4
5
6
7
8
9
10
11

public Future<O> map(Function<I, O> transformer) {
  Promise<O> ret = Promise.promise();
  this.setHandler(asyncResult -> {
    if (asyncResult.succeed()) {
      ret.complete(transformer.apply(asyncResult.result()));
    } else {
      ret.fail(asyncResult.cause())
    }
  });
  return ret.future();
}

通过 map 的代码，我们可以清楚地发现，Promise 和 Future 非常类似于一个 channel。我们总是留住一根管子的一端，把另一端交给下游。自己干完活就对着管子吼一声。

CompositeFuture 的实现

这里为了方便理解做了一点简化，实际上 CompositeFuture 是一个接口，真正的实现在 CompositeFutureImpl 中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class CompositeFuture implements Future<CompositeFuture> {
  // 自己包含的子 Future 的数量
  private int count;
  // 用来表示自己所有子 Future 完成的 Promise
  private Promise promise = Promise.promise();
  
  public static CompositFuture all(List<Future<?>> futures) {
    CompositFutureImpl composit = new CompositFutureImpl(futures);

    for (Future<?> future : futures) {
      future.setHandler(result -> {
        if (result.succeed()) {
          composit.count ++;
        }
        if (count == composit.len) {
          composit.succeed();
        }
      })
    }
  }
}

CompositFuture 的实现思路也很简单，就是在每一个子 Future 上注册一个回调来通知自己一个子 Future 已经完成。如果所有的子 Future 都完成了，就可以把自己标记成完成。

OPED 是 (我自己发起的) One Paper Each Day 挑战, 即每天(偶尔)读一篇 Paper, 领域不限.

这是 OPED 挑战的第十一篇, 论文为 Millions of Tiny Databases

今天介绍的这一篇论文是 AWS 发表的. 它描述了 AWS 为了保证 EBS (大概可以翻译成云盘?) 正确地做 replication 和 fail over 而实现的一个兼顾 C 和 A 的系统.

名字的由来

Physalia 中文名叫僧帽水母。

虽然僧帽水母像水母，但其实是一个包含水螅体及水母体的群落。

今天介绍的 Physalia 这个系统，某种意义上来说和 Physalia 这个生物有点相似.

另外, Physalia, 又被称为 Man-Of-War. 虽然我知道没有什么关系，但我还是不由自主地联想到了人民战争的汪洋大海，以及集中力量办大事的优越性。

要解决的问题

熟悉 AWS 的朋友想必都知道，EBS 为 EC2 提供了块设备 (block device)，EC2 可以像挂载普通硬盘一样挂载它。然而，EBS 在实现上并不是一个真的本地硬盘，而是通过网络访问的。为了不让使用者操心这些，同时也是为了保证高可用，EBS 会做 Replication 和自动的 Fail Over，保证一个 EBS 节点挂了或者网络分区了，EC2 仍然可以不受影响。

为了做到这一点，我们就需要有一种强一致的方式，获取一个 EBS 到底有哪些备份，以及到底哪一个备份是当前的 Primary。这个问题在分布式场景中很常见，我们往往是通过某个实现了共识算法的组件来解决这个问题，例如使用 etcd，zookeeper等等。然而这种系统的一个问题是，如果出现了网络分区，分区中较小的一块中的所有节点，都无法工作了（i.e. 这是一个 CP 系统）。

Physalia 的目的，就是实现一个配置服务，在保证强一致的情况下，尽可能保证高可用。

核心思路

核心概念

为了解决上面提出的问题，Physalia 提出了两个核心概念:

1. Blast Radius: 一个 Failure 波及的用户数量。像 zookeeper 这种服务，Blast Radius 就相对比较大。
2. Correlation of Failure: 我们经常听到两地三中心这种说法，它的意思是在两个空间上分割的地点部署三个数据中心。这样做的目的是为了提高数据中心出现问题这种事件的独立性。

思路

Physalia 解决问题的核心思路就是

利用对网络拓扑的理解，构造更细粒度的 Paxos Group，每一个 Group 只负责处理一小部分节点，从而减少 Blast Radius

具体做法

Physalia 将一个配置服务中的所有节点（Colony），分成若干个 Cell。每一个 Cell 包含了 7 个 Node。每一个 Cell 构成了一个 Paxos Group，并且 Cell 之间都完全独立，不互相依赖。每一个 Cell 都只负责一小部分 EBS 的配置，保证了如果一个 Cell 中的网络不通，或者节点挂了，只会有一小部分 EBS 收到影响，从而减小了 Blast Radius。

Cell 和 EBS 的分配

上面的思路已经比较明确了，需要注意的一点是怎么来决定哪一个 Cell 负责保存哪一个 EBS 的配置信息。这里就需要 Physalia 对网络拓扑有了解，保证每一个 Cell 和 EBS 的距离不会很远，否则”路上”任一一段网络出了问题，就会波及更多的节点，做不到减小 Blast Radius。

Reconfiguration

除了 EBS 和负责它的 Cell 之间的距离不能太大之外，Cell 和使用它的客户（EC2）也不能太远。因此 Physalia 中包含了一个 control-plane 不断的优化 Cell 的放置，优化网络距离。由于每一个 Cell 中保存的数据（只保存了它负责的少量的 EBS 的配置数据）很小，数据迁移的开销也很小。

总结

我感觉 Physalia 的思路就和我标题了说的一样，分散力量办大事。它将一个大问题拆解成了独立的小问题，然后再独立地解决这些小问题。它的思路很有意思，但是这样做的代价就是让整个系统变得更加复杂。尤其是在引入了 Cell 的动态分配之后，整个系统的可预测性似乎也受到了影响，要是出了什么问题，感觉很难查错。